draft-ietf-ipv6-prefix-delegation-requirement-00.txt		draft-ietf-ipv6-prefix-delegation-requirement-01.txt
	Internet Engineering Task Force Shin Miyakawa		Network Working Group S. Miyakawa
	INTERNET-DRAFT NTT Communications		Internet-Draft NTT Communications Corporation
	<draft-ietf-ipv6-prefix-delegation-requirement-00.txt>		Expires: Aug 25, 2003 R. Droms
			Cisco Systems
	Expires: May 1, 2003		Feb 2003
	Nov 1, 2002
	Requirements for IPv6 prefix delegation		Requirements for IPv6 prefix delegation
			draft-ietf-ipv6-prefix-delegation-requirement-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with
	provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering
	Force (IETF), its areas, and its working groups. Note that other groups		Task Force (IETF), its areas, and its working groups. Note that
	may also distribute working documents as Internet-Drafts.		other 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 material		time. It is inappropriate to use Internet-Drafts as reference
	or to cite them other than as ``work in progress.''		material or to cite them other than as "work in progress."
	To view the list Internet-Draft Shadow Directories, see		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
			The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Distribution of this memo is unlimited.		This Internet-Draft will expire on Aug 25, 2003.
	The internet-draft will expire in 6 months. The date of expiration will		Copyright Notice
	be May 1, 2003.
			Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	This document describes requirements about how an IPv6 address prefix		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").
	Motivation		1. Introduction
	With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs		With the deployment of IPv6 [2], several Internet Service Providers
	are ready to offer their services to the public in conjunction with		are ready to offer IPv6 access to the public. In conjunction with
	widely deployed IP subscription method such as ADSL and so on. But,		widely deployed "always on" media as ADSL, and the expectation that
	thinking about following situation of IPv6 commercial service as one		customers will be assigned a /48 IPv6 address prefix, an efficient
	of the most likely examples,		mechanism for delegating address prefixes to the customers sites is
			needed. The delegation mechanism will be intended to automate the
			process of informing the customer's networking equipment of the
			prefixes to be used at the customer's site.
	IPv6 ISP router		This document clarifies the requirements for IPv6 address prefix
	|		delegation from the ISP to the site.
	| point-to-point link
	|
	User's Site router
	|
	----+----- User's Site Network
	though it is needed a standardized way to delegate one or more IPv6		2. Requirements
	address prefix(es) from the IPv6 ISP to the User's site
	automatically, it is not identified clearly yet.
	Originally, it seemed that just RA (Router Avertisement) considered		The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	as good enough to be used for P-P link between ISP and User's site,		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
	but according to the NCCs' recommendations, one site should be		interpreted as described in RFC2119 [1].
	delegated /48 usually.
	So, ISP which now would like to start its own IPv6 commercial service		3. Scenario and terminology
	TODAY, need to have some method other than RA protocol which only can
	handle one signle /64 prefix but something else or enhanced
	- to delegate not just one signle /64 prefix to the user - to satisfy		The following figure illustrates a likely example for the
	all the other (standard) requirements which is needed to realize		organization of a network providing subscription IPv6 service:
	commercial service
	Therefore, this documents clarifies requirements for IPv6 address		/------\
	prefix delegation from the ISP to the site, especially from the		/ \
	(commercial) ISP point of view to boost IPv6 business quick as		+ |
	possible.		/ \ /
			+---------------+ +--------+/ \------/
			|ISP Edge Router|Point-to-point|Customer+
			| +--------------+ Router | Customer networks
			| (PE) | link | (CPE) +
			+---------------+ +--------+\ /------\
			\ / \
			+ |
			\ /
			\------/
	Requirements for prefix delegation management		Illustration of ISP-customer network architecture
	Focusing commercial IPv6 ISP service, there are several kinds of
	category of requirements for the mechanism / protocol to delegate one
	or more IPv6 prefixes from ISP to a site.
	- layer 2 consideration		Terminology:
	The method should work on any layer 2 technologies. In other words,		PE Provider edge device; the device at which the link to the customer
			site is terminated
			CPE Customer provided equipment; the device at the customer site at
			which the link to the ISP is terminated
			4. Requirements for Prefix Delegation
			The purpose of the prefix delegation mechanism is to communicate
			prefixes to the CPE automatically.
			4.1 Number and Length of Delegated Prefixed
			The prefix delegation mechanism SHOULD allow for delegation of
			prefixes of length /48, /64 and other lengths, and SHOULD allow for
			delegation of more than one prefix to the customer.
			4.2 Use of Delegated Prefixes in Customer Network
			The prefix delegation mechanism MUST NOT prohibit or inhibit the
			assignment of longer prefixes, created from the delegated prefixes,
			to links within the customer network. It is not a requirement that
			the prefix delegation mechanism provide for the reporting of prefix
			delegation within the customer network back to the ISP.
			4.3 Automated Assignment
			The prefix delegation mechanism SHOULD allow for long-lived pre-
			assignment of one or more prefix(es) to a customer and for
			automated, possibly short-lived assignment of a prefix to a customer
			on demand.
			4.4 Policy-based Assignment
			The prefix delegation mechanism SHOULD allow for the use of policy in
			assigning prefixes to a customer. For example, the customer's
			identity and type of subscribed service may be used to determine the
			address block from which the customer's prefix is selected, and the
			length of the prefix assigned to the customer.
			4.5 Security and Authentication
			The prefix delegation mechanism MUST provide for reliable
			authentication of the identity of the customer to which the prefixes
			are to be assigned, and MUST provide for reliable, secure
			transmission of the delegated prefixes to the customer.
			4.6 Accounting
			The prefix delegation mechanism MUST allow for the ISP to provide
			accounting information about delegated prefixes.
			4.7 Layer 2 Considerations
			The method SHOULD work on any layer 2 technologies. In other words,
	it should be layer 2 technology independent. Though, at the same		it should be layer 2 technology independent. Though, at the same
	time, it should be noted that now ISP would like to have a solution		time, it should be noted that now ISP would like to have a solution
	for Point-to-Point link which has own authentication mechanism first.		for Point-to-Point link which has own authentication mechanism first.
	PPP link with CHAP authentication is a good example. (Simulated)		PPP link with CHAP authentication is a good example. (Simulated)
	Ethernet and IEEE802.11 (wireless LAN) should be covered in near		Ethernet and IEEE802.11 (wireless LAN) should be covered in near
	future, but they have low priority (just) for now. It should be		future, but they have low priority (just) for now. It should be
	clarified that the method should work with all L2 protocols either		clarified that the method should work with all L2 protocols either
	with authentication mechanism or without, but ISP would like to take		with authentication mechanism or without, but ISP would like to take
	advantage of a L2 protocol's authentication mechanism if it exits.		advantage of a L2 protocol's authentication mechanism if it exits.
	- accounting		5. IANA Considerations
	It should provide accounting capability such as logging about by		There are no IANA considerations in this document.
	whom, when and what prefix(es) is used for the service with proper
	authentication techniques.
	- kinds of prefixes		6. Security considerations
	It should be able to delegate both statically and dynamically		Section 4.5 specifies security requirements for the prefix delegation
	assigned prefix assignment by authenticated identification, depended		mechanism.
	by resources and/or any reasons.
	- negotiation between ISP and site		References
	ISP may deny the service, due to various reasons such as there is no		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	contract or bad financial credit etc. Also ISP should be able to use		Levels", BCP 14, RFC 2119, March 1997.
	one single technique to pass parameters of the prefix such as scope
	(global and/or site), prefix length (/48, /64 or any other length)
	and any other appropriate related information to the site. On the
	other hand, a site should be able to request multiple prefixes to the
	ISP. Also a site should be able to pass parameters of the prefix
	such as scope (global and/or site), prefix length (/48, /64 or any
	other length), number of prefixes and so on to the ISP to negotiate.
	- less impact on ISP equipments		[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
			Specification", RFC 2460, December 1998.
	ISP usualy use some kind of equipment to provide subscription service		Author's Address
	to the users such as access concentrating router, PPP server and so
	on. This may aggregate thousands or more connections toward the
	ISP's backbone. Prefix delegation mechanism must be compatible with
	this situation.
	References Deering, 1998. S. Deering and R. Hinden, "Internet		Shin Miyakawa
	Protocol, Version 6 (IPv6) Specification", RFC2460 (December 1998).		Innovative IP Architecture Center, NTT Communications Corporation
			Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo,
			Japan
			Phone: +81-3-6800-3262
			EMail: miyakawa@nttv6.jp
	History		Ralph Droms
	Jun 2002, first draft was presented as personal submission.		Cisco Systems
	At the IETF-54th at Yokohama, it became a working group draft.		300 Apollo Drive
	Nov 2003, the draft published as -01 draft.		Chelmsford, MA 01886
			Phone: +1-978-497-4733
			EMail: rdroms@cisco.com
	Acknowledgements		Full Copyright Statement
	People in Internet Association of Japan have gave me a lot of good input.
	Team members of NTT Communications IPv6 project, especially Toshi Yamasaki
	and Yasuhiro Shirasaki, gave me quite useful suggestions for this
	document. Chairs of IETF IPv6 working group especially Bob Hinden
	who gave me a good suggestions before I submitted this draft.
	Also communications with other folks in the IPv6 community, such
	as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have
	been quite helpful. Thanks a lot.
	Author's address		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Shin Miyakawa, Ph.D
	Innovative IP Architecture Center, NTT Communications Corporation		This document and translations of it may be copied and furnished to
	Tokyo, Japan		others, and derivative works that comment on or otherwise explain it
	Tel: +81-3-6800-3262		or assist in its implementation may be prepared, copied, published
	Fax: +81-3-5265-2990		and distributed, in whole or in part, without restriction of any
	Email: miyakawa@nttv6.jp		kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/