RFC 3769

Requirements for IPv6 Prefix Delegation

📅 published June 2004, from ietf

RFC 3769: Requirements for IPv6 Prefix Delegation 🎀

okay bestie, this one's from June 2004 and it's by S. Miyakawa (NTT Communications Corporation) and R. Droms (Cisco) 💅 it's Informational, which means it's just sharing info with the internet, not a formal standard. it doesn't obsolete or update any other RFCs, so it's a clean slate 🫶

Status of This Memo ✨

this memo gives information to the internet community. it doesn't specify an internet standard of any kind. distribution is unlimited 🌸

copyright (C) The Internet Society (2004).

Abstract 💜

this doc lays out the requirements for how IPv6 address prefixes should get handed out to an IPv6 subscriber's network (or "site") 🧚

1. Introduction 💖

so IPv6 [1] is out there now, and a few ISPs are ready to sell IPv6 access to regular people 🌈 right alongside "always on" connections like ADSL, customers are expected to get a /48 IPv6 unicast address prefix (see RFC 3513 [3] and section 3 of RFC 3177 [2]). that means we need an efficient way to delegate prefixes to each customer's sites. the goal is to automate telling the customer's networking gear which prefixes to use at their site ✨

this doc clarifies the requirements for IPv6 address prefix delegation from the ISP to the site. iykyk 💅

2. Scenario and terminology 🍓

here's a likely setup for a network offering subscription IPv6 service 👑

                                                 /------\
                                                /        \
                                               +          |
                                              / \        /
    +---------------+              +--------+/   \------/
    |ISP Edge Router|Point-to-point|Customer+
    |               +--------------+ Router |  Customer networks
    |     (PE)      |     link     | (CPE)  +
    +---------------+              +--------+\   /------\
                                              \ /        \
                                               +          |
                                                \        /
                                                 \------/

Figure 1: Illustration of ISP-customer network architecture

the terms, no cap:

  • PE: the provider edge device. it's the one plugged into the service provider's network infrastructure, and it's where the link to the customer site ends 🦋
  • CPE: the customer premises equipment. it's the device at the customer site where the link to the ISP ends 🎀

3. Requirements for Prefix Delegation 👑

the whole point of prefix delegation is to hand out and manage prefixes to the CPE automatically 🫶

3.1. Number and Length of Delegated Prefixes 💖

okay so the mechanism should be able to delegate prefixes with lengths from /48 to /64, inclusive ✨ other lengths should be supported too. it should also let a customer get more than one prefix 🌈

3.2. Use of Delegated Prefixes in Customer Network 🧚

the mechanism must not block or get in the way of assigning longer prefixes (made from the delegated ones) to links inside the customer network 🔥 and it's not required to report any of those in-network prefix delegations back to the ISP 💅

3.3. Static and Dynamic Assignment 🌸

the mechanism should allow long-lived static pre-assignment of prefixes. it should also allow automated, possibly short-lived, on-demand, dynamic assignment of prefixes to a customer. both are giving flexibility 🦋

3.4. Policy-based Assignment 💜

the mechanism should be able to use policy when assigning prefixes to a customer. for example, the customer's identity and the type of service they subscribe to might decide which address block the prefix comes from, and how long the prefix is 🍓

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 instance, the CPE should be able to ask for a preferred prefix length 👑

3.6. Security and Authentication 🔥

the mechanism must provide reliable authentication of the identity of the customer getting the prefixes, and it must provide reliable, secure transmission of the delegated prefixes to that customer. this part is SO important 😭

the prefix delegation should also provide reliable authentication of the identity of the service provider's edge router 🫶

3.7. Accounting 💅

the mechanism must let the ISP get accounting information about delegated prefixes from the PE 💖

3.8. Hardware technology Considerations ✨

the mechanism should work on any hardware link technology between the PE and the CPE, and it should be hardware technology independent 🌈 it must work on shared links 🔥

the mechanism should work with all hardware technologies, whether they have an authentication mechanism or not. but ISPs would love to use the hardware technology's authentication mechanism if one exists 💜

4. Security considerations 💀

this part is serious, bestie 😭 section 3.6 covers the security requirements for the prefix delegation mechanism. for point to point links, where you trust that there's no man in the middle, or you trust 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 repeatedly requesting delegated prefixes until the PE runs out of available prefixes 😭

5. Acknowledgments 🫶

the authors want to thank Randy Bush, Thomas Narten, Micheal Py, Pekka Savola, Dave Thaler, and other members of the IPv6 working group and the IESG for their review and constructive comments 🎀 they'd also like to thank the people in the IPv6 operation group of the Internet Association of Japan and the 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.

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

copyright (C) The Internet Society (2004). this document is subject to the rights, licenses and restrictions in BCP 78, and except as stated there, the authors keep all their rights ✨

this document and the info in it 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 USING 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights might be available. it also doesn't claim to have made any independent effort to find such rights 🦋 info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 🌸

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF online 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 needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from