draft-ietf-ipv6-prefix-delegation-requirement-03.txt		draft-ietf-ipv6-prefix-delegation-requirement-04.txt
	Network Working Group S. Miyakawa		Network Working Group S. Miyakawa
	Internet-Draft NTT Communications Corporation		Internet-Draft NTT Communications Corporation
	Expires: February 21, 2004 R. Droms		Expires: August 9, 2004 R. Droms
	Cisco		Cisco
	August 23, 2003		February 9, 2004
	Requirements for IPv6 prefix delegation		Requirements for IPv6 prefix delegation
	draft-ietf-ipv6-prefix-delegation-requirement-03.txt		draft-ietf-ipv6-prefix-delegation-requirement-04.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 21, 2004.		This Internet-Draft will expire on August 9, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document describes requirements for how IPv6 address prefixes		This document describes requirements for how IPv6 address prefixes
	should be delegated to an IPv6 subscriber's network (or "site").		should be delegated to an IPv6 subscriber's network (or "site").
	1. Introduction		1. Introduction
	With the deployment of IPv6 [1], several Internet Service Providers		With the deployment of IPv6 [1], several Internet Service Providers
	are ready to offer IPv6 access to the public. In conjunction with		are ready to offer IPv6 access to the public. In conjunction with
	widely deployed "always on" media such as ADSL and the expectation		widely deployed "always on" media such as ADSL and the expectation
	that customers will be assigned a /48 IPv6 unicast address prefix		that customers will be assigned a /48 IPv6 unicast address prefix
	(see RFC3513 [2] and section 3 of RFC3177 [3]), an efficient		(see RFC3513 [3] and section 3 of RFC3177 [2]), an efficient
	mechanism for delegating address prefixes to the customers sites is		mechanism for delegating address prefixes to the customers sites is
	needed. The delegation mechanism will be intended to automate the		needed. The delegation mechanism will be intended to automate the
	process of informing the customer's networking equipment of the		process of informing the customer's networking equipment of the
	prefixes to be used at the customer's site.		prefixes to be used at the customer's site.
	This document clarifies the requirements for IPv6 address prefix		This document clarifies the requirements for IPv6 address prefix
	delegation from the ISP to the site.		delegation from the ISP to the site.
	2. Scenario and terminology		2. Scenario and terminology
	skipping to change at page 2, line 50		skipping to change at page 2, line 50
	3. Requirements for Prefix Delegation		3. Requirements for Prefix Delegation
	The purpose of the prefix delegation mechanism is to delegate and		The purpose of the prefix delegation mechanism is to delegate and
	manage prefixes to the CPE automatically.		manage prefixes to the CPE automatically.
	3.1 Number and Length of Delegated Prefixes		3.1 Number and Length of Delegated Prefixes
	The prefix delegation mechanism should allow for delegation of		The prefix delegation mechanism should allow for delegation of
	prefixes of lengths between /48 and /64, inclusively. Other lengths		prefixes of lengths between /48 and /64, inclusively. Other lengths
	may be supported. The mechanism should allow for delegation of more		should also be supported. The mechanism should allow for delegation
	than one prefix to the customer.		of more than one prefix to the customer.
	3.2 Use of Delegated Prefixes in Customer Network		3.2 Use of Delegated Prefixes in Customer Network
	The prefix delegation mechanism must not prohibit or inhibit the		The prefix delegation mechanism must not prohibit or inhibit the
	assignment of longer prefixes, created from the delegated prefixes,		assignment of longer prefixes, created from the delegated prefixes,
	to links within the customer network. The prefix delegation mechanism		to links within the customer network. The prefix delegation mechanism
	is not required to report any prefix delegations within the		is not required to report any prefix delegations within the
	customer's network back to the ISP.		customer's network back to the ISP.
	3.3 Static and Dynamic Assignment		3.3 Static and Dynamic Assignment
	skipping to change at page 3, line 28		skipping to change at page 3, line 28
	on-demand dynamic assignment of prefixes to a customer.		on-demand dynamic assignment of prefixes to a customer.
	3.4 Policy-based Assignment		3.4 Policy-based Assignment
	The prefix delegation mechanism should allow for the use of policy in		The prefix delegation mechanism should allow for the use of policy in
	assigning prefixes to a customer. For example, the customer's		assigning prefixes to a customer. For example, the customer's
	identity and type of subscribed service may be used to determine the		identity and type of subscribed service may be used to determine the
	address block from which the customer's prefix is selected, and the		address block from which the customer's prefix is selected, and the
	length of the prefix assigned to the customer.		length of the prefix assigned to the customer.
	3.5 Security and Authentication		3.5 Expression of Requirements or Preferences by the CPE
			The CPE must be able to express requirements or preferences in its
			request to the PE. For example, the CPE should be able to express a
			preference for a prefix length.
			3.6 Security and Authentication
	The prefix delegation mechanism must provide for reliable		The prefix delegation mechanism must provide for reliable
	authentication of the identity of the customer to which the prefixes		authentication of the identity of the customer to which the prefixes
	are to be assigned, and must provide for reliable, secure		are to be assigned, and must provide for reliable, secure
	transmission of the delegated prefixes to the customer.		transmission of the delegated prefixes to the customer.
	3.6 Accounting		The prefix delegation should provide for reliable authentication of
			the identity of the service provider's edge router.
	The prefix delegation mechanism must allow for the ISP to provide		3.7 Accounting
	accounting information about delegated prefixes.
	3.7 Hardware technology Considerations		The prefix delegation mechanism must allow for the ISP to obtain
			accounting information about delegated prefixes from the PE.
	The prefix delegation mechanism should work on any hardware		3.8 Hardware technology Considerations
	technology and should be hardware technology independent. The
	mechanism must work on shared links. The mechanism should work with		The prefix delegation mechanism should work on any hardware link
	all hardware technologies either with an authentication mechanism or		technology between the PE and the CPE and should be hardware
	without, but ISPs would like to take advantage of the hardware		technology independent. The mechanism must work on shared links. The
	technology's authentication mechanism if it exists.		mechanism should work with all hardware technologies either with an
			authentication mechanism or without, but ISPs would like to take
			advantage of the hardware technology's authentication mechanism if it
			exists.
	4. IANA Considerations		4. IANA Considerations
	There are no IANA considerations in this document.		There are no IANA considerations in this document.
	5. Security considerations		5. Security considerations
	Section 3.5 specifies security requirements for the prefix delegation		Section 3.6 specifies security requirements for the prefix delegation
	mechanism. For point to point links, where one trusts that there is		mechanism. For point to point links, where one trusts that there is
	no man in the middle, or one trusts layer two authentication,		no man in the middle, or one trusts layer two authentication,
	authentication may not be necessary.		authentication may not be necessary.
	A rogue delegating router can issue bogus prefixes to a requesting		A rogue PE can issue bogus prefixes to a requesting router. This may
	router. This may cause denial of service due to unreachability.		cause denial of service due to unreachability.
	A rogue requesting router (CPE) may be able to mount a denial of		A rogue CPE may be able to mount a denial of service attack by
	service attack by repeated requests for delegated prefixes that		repeated requests for delegated prefixes that exhaust the PE's
	exhaust the delegating router's available prefixes.		available prefixes.
	6. Acknowledgments		6. Acknowledgments
	The authors would like to express our thanks to Pekka Savola, Dave		The authors would like to express our thanks to Randy Bush, Thomas
	Thaler, Micheal Py and other members of the IPv6 working group for		Narten, Micheal Py, Pekka Savola, Dave Thaler, as well as other
	their review and constructive comnents and to the people in the IPv6		members of the IPv6 working group and the IESG for their review and
	operation group of the Internet Association of Japan and NTT		constructive comnents and to the people in the IPv6 operation group
	Communications IPv6 project, especially Toshi Yamasaki and Yasuhiro		of the Internet Association of Japan and NTT Communications IPv6
	Shirasaki for their original discussion and suggestions.		project, especially Toshi Yamasaki and Yasuhiro Shirasaki for their
			original discussion and suggestions.
	Informative References		Informative References
	[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[2] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC
	Addressing Architecture", RFC 2460, December 1998.
	[3] IAB/IESG, "IAB/IESG Recommendations on IPv6 Address", RFC
	3177, September 2001.		3177, September 2001.
			[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
			Addressing Architecture", RFC 3513, April 2003.
	Authors' Addresses		Authors' Addresses
	Shin Miyakawa		Shin Miyakawa
	NTT Communications Corporation		NTT Communications Corporation
	Tokyo		Tokyo
	Japan		Japan
	Phone: +81-3-6800-3262		Phone: +81-3-6800-3262
	EMail: miyakawa@nttv6.jp		EMail: miyakawa@nttv6.jp
	Ralph Droms		Ralph Droms
	Cisco		Cisco
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: +1 978.936.1674		Phone: +1 978.936.1674
	EMail: rdroms@cisco.com		EMail: rdroms@cisco.com
	Intellectual Property Statement		Intellectual Property Statement
	skipping to change at page 6, line 29		skipping to change at page 6, line 29
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/