Requirements for IPv6 Prefix Delegation
RFC 3769

Network Working Group S. Miyakawa
Request for Comments: 3769 NTT Communications Corporation
Category: Informational R. Droms
 Cisco
 June 2004
 Requirements for IPv6 Prefix Delegation
Status of this Memo
 This memo provides information for the Internet community. It does
 not specify an Internet standard of any kind. Distribution of this
 memo is unlimited.
Copyright Notice
 Copyright (C) The Internet Society (2004).
Abstract
 This document describes requirements for how IPv6 address prefixes
 should be delegated to an IPv6 subscriber's network (or "site").
1. Introduction
 With the deployment of IPv6 [1], several Internet Service Providers
 are ready to offer IPv6 access to the public. In conjunction with
 widely deployed "always on" media such as ADSL and the expectation
 that customers will be assigned a /48 IPv6 unicast address prefix
 (see RFC 3513 [3] and section 3 of RFC 3177 [2]), an efficient
 mechanism for delegating address prefixes to the customer's 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.
 This document clarifies the requirements for IPv6 address prefix
 delegation from the ISP to the site.
Miyakawa & Droms Informational [Page 1]
RFC 3769 Requirements IPv6 Prefix Delegation June 2004
2. Scenario and terminology
 The following figure illustrates a likely example for the
 organization of a network providing subscription IPv6 service:
 /------\
 / \
 + |
 / \ /
 +---------------+ +--------+/ \------/
 |ISP Edge Router|Point-to-point|Customer+
 | +--------------+ Router | Customer networks
 | (PE) | link | (CPE) +
 +---------------+ +--------+\ /------\
 \ / \
 + |
 \ /
 \------/
 Figure 1: Illustration of ISP-customer network architecture
 Terminology:
 PE: Provider edge device; the device connected to the service
 provider's network infrastructure at which the link to the
 customer site is terminated
 CPE: Customer premises equipment; the device at the customer site at
 which the link to the ISP is terminated
3. Requirements for Prefix Delegation
 The purpose of the prefix delegation mechanism is to delegate and
 manage prefixes to the CPE automatically.
3.1. Number and Length of Delegated Prefixes
 The prefix delegation mechanism should allow for delegation of
 prefixes of lengths between /48 and /64, inclusively. Other lengths
 should also be supported. The mechanism should allow for delegation
 of more than one prefix to the customer.
Miyakawa & Droms Informational [Page 2]
RFC 3769 Requirements IPv6 Prefix Delegation June 2004
3.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. The prefix delegation
 mechanism is not required to report any prefix delegations within the
 customer's network back to the ISP.
3.3. Static and Dynamic Assignment
 The prefix delegation mechanism should allow for long-lived static
 pre-assignment of prefixes and for automated, possibly short-lived,
 on-demand, dynamic assignment of prefixes to a customer.
3.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.
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
 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.
 The prefix delegation should provide for reliable authentication of
 the identity of the service provider's edge router.
3.7. Accounting
 The prefix delegation mechanism must allow for the ISP to obtain
 accounting information about delegated prefixes from the PE.
3.8. Hardware technology Considerations
 The prefix delegation mechanism should work on any hardware link
 technology between the PE and the CPE and should be hardware
 technology independent. The mechanism must work on shared links.
Miyakawa & Droms Informational [Page 3]
RFC 3769 Requirements IPv6 Prefix Delegation June 2004
 The mechanism should work with all hardware technologies with either
 an authentication mechanism or without, but ISPs would like to take
 advantage of the hardware technology's authentication mechanism if it
 exists.
4. Security considerations
 Section 3.6 specifies security requirements for the prefix delegation
 mechanism. For point to point links, where one trusts that there is
 no man in the middle, or one trusts layer two authentication,
 authentication may not be necessary.
 A rogue PE can issue bogus prefixes to a requesting router. This may
 cause denial of service due to unreachability.
 A rogue CPE may be able to mount a denial of service attack by
 repeated requests for delegated prefixes that exhaust the PE's
 available prefixes.
5. Acknowledgments
 The authors would like to express thanks to Randy Bush, Thomas
 Narten, Micheal Py, Pekka Savola, Dave Thaler, as well as other
 members of the IPv6 working group and the IESG for their review and
 constructive comments. The authors would also like to thank the
 people in the IPv6 operation group of the Internet Association of
 Japan and NTT Communications IPv6 project, especially Toshi Yamasaki
 and Yasuhiro Shirasaki for their original discussion and suggestions.
6. Informative References
 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
 Specification", RFC 2460, December 1998.
 [2] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC
 3177, September 2001.
 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
 Addressing Architecture", RFC 3513, April 2003.
Miyakawa & Droms Informational [Page 4]
RFC 3769 Requirements IPv6 Prefix Delegation June 2004
7. Authors' Addresses
 Shin Miyakawa
 NTT Communications Corporation
 Tokyo
 Japan
 Phone: +81-3-6800-3262
 EMail: miyakawa@nttv6.jp
 Ralph Droms
 Cisco
 1414 Massachusetts Avenue
 Boxborough, MA 01719
 USA
 Phone: +1 978.936.1674
 EMail: rdroms@cisco.com
Miyakawa & Droms Informational [Page 5]
RFC 3769 Requirements IPv6 Prefix Delegation June 2004
8. Full Copyright Statement
 Copyright (C) The Internet Society (2004). This document is subject
 to the rights, licenses and restrictions contained in BCP 78, and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights. Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard. Please address the information to the IETF at ietf-
 ipr@ietf.org.
Acknowledgement
 Funding for the RFC Editor function is currently provided by the
 Internet Society.
Miyakawa & Droms Informational [Page 6]