RFC 6879
IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
RFC 6879: IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods 💅🦋
Okay bestie, here's the title block tea ☕. This one is from the IETF, filed as Informational, so it's published for information and isn't a standards-track spec 🌸. It's dated February 2013 and has ISSN 2070-1721. The authors are S. Jiang and B. Liu from Huawei Technologies Co., Ltd., and B. Carpenter from the University of Auckland. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🧚
Abstract ✨
Okay so this doc looks at the events that make you renumber a network and then walks through the renumbering methods that exist today 🎀. It sorts everything into three buckets: stuff that matters during network design, stuff that matters while you're getting ready to renumber, and stuff that matters during the renumbering operation itself 💖.
Status of This Memo 📜
Real talk, this isn't an Internet Standards Track spec. It's just published for informational purposes 🌷.
This doc is a product of the Internet Engineering Task Force (IETF) 🫶. It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 👀.
Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6879 🔗.
Copyright Notice 🌈
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 📚. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🍓.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Enterprise Network Illustration for Renumbering .................3
3. Enterprise Network Renumbering Scenario Categories ..............5
3.1. Renumbering Caused by External Network Factors .............5
3.2. Renumbering Caused by Internal Network Factors .............5
4. Network Renumbering Considerations and Current Methods ..........6
4.1. Considerations and Current Methods during Network Design ...6
4.2. Considerations and Current Methods for the
Preparation of Renumbering ................................10
4.3. Considerations and Current Methods during
Renumbering Operation .....................................11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................151. Introduction 🌸
Site renumbering is genuinely hard 😭. Network managers often try to dodge future renumbering by numbering their resources out of Provider-Independent (PI) address space. The catch is that using PI space everywhere would make BGP4 scaling problems worse [RFC4116] 💀. And depending on Regional Internet Registry (RIR) policies, PI space isn't always available for enterprises of every size. So it's really desirable to build mechanisms that make IPv6 renumbering easier for enterprises ✨.
This doc is an analysis of IPv6 site renumbering for enterprise networks 🧠. It describes scenarios, including what current capabilities and existing practices look like. The reader is assumed to already know [RFC4192] and [RFC5887] 📖. New technology and method proposals are out of scope, so don't come here looking for those 🙅♀️.
Since IPv4 and IPv6 are logically separate when you're thinking about renumbering, it doesn't matter whether the IPv4 and IPv6 networks or devices overlap. This doc focuses on IPv6 only, and IPv4 is out of scope 🦋. Dual-stack networks and IPv4/IPv6 transition scenarios are out of scope too.
This doc is about enterprise network renumbering, but most of the analysis also applies to ISP network renumbering 💅. Renumbering in home networks is out of scope, though it can still benefit from what's in here 🏠.
First the doc introduces the idea of an enterprise network and a typical network illustration. Then it covers the current renumbering methods, sorted into the three categories: design, preparation for renumbering, and the renumbering operation 🗂️.
2. Enterprise Network Illustration for Renumbering 🏢
An Enterprise Network, as defined in [RFC4057], is a network that has multiple internal links, has one or more router connections to one or more Providers, and is actively managed by a network operations entity 💼.
Figure 1 shows a sample enterprise network architecture for a simple case 👀. These are the entities that get mainly affected by renumbering:
- Gateway (Border router, firewall, web cache, etc.)
- Application server (for internal or external users)
- DNS and DHCP servers
- Routers
- Hosts (desktops, etc.)
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1. Enterprise Network IllustrationAddress reconfiguration gets done by either the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery (ND) for IPv6 🔧. During a renumbering event, DNS records need to be synced, while routing tables, Access Control Lists (ACLs), and IP filtering tables in various devices also need updating 🔄. It's taken for granted that applications will work entirely on DNS names 🙈, but any direct dependencies on IP addresses in application-layer entities must also be updated 💅.
The issue of static addresses has its own dedicated doc, [RFC6866] 📌.
The emerging cloud-based enterprise network architecture might look different from Figure 1 ☁️. But it's out of scope for this doc, since it's far from mature and hasn't been widely deployed yet 🌱.
It's assumed that IPv6 enterprise networks are either IPv6-only or dual-stack, where a logical IPv6 plane is independent from IPv4 🦋. As mentioned above, IPv4/IPv6 coexistence scenarios are out of scope.
This doc focuses on routable unicast addresses. Link-local, multicast, and anycast addresses are also out of scope 🚫.
3. Enterprise Network Renumbering Scenario Categories 🎀
Here we split enterprise network renumbering scenarios into two categories, defined by external and internal network factors 🧩. Each category needs renumbering for different reasons 💫.
3.1. Renumbering Caused by External Network Factors 🌍
These ISP uplink-related events can cause renumbering:
- The enterprise network switches to a new ISP. When this happens, the enterprise stops numbering its resources from the prefix the old ISP allocated, and renumbers them from the prefix the new ISP allocated 🔀.
A "flag day" renumbering event [RFC4192] may be averted if, during a transitional period, the enterprise network can number its resources from either prefix 🙌. One way to make that transitional period happen is for the enterprise to contract service from both ISPs during the transition 🤝.
- The renumbering event can be kicked off by receiving new prefixes from the same uplink 📬. This might happen if the enterprise network is moved to a different location within the network topology of the same ISP, for reasons like commercial, performance, or services considerations 🏬. Or the ISP itself might get renumbered because of topology changes or a migration to a different or additional prefix 🛠️. These ISP renumbering events would, of course, kick off enterprise network renumbering events too 💅.
- The enterprise network adds a new uplink(s) for multihoming purposes 🌐. This might not be a typical renumbering case, because the original addresses won't change 🤷♀️. However, initial numbering may be considered a special renumbering event 🍼. The enterprise network removes uplink(s) or old prefixes 🗑️.
3.2. Renumbering Caused by Internal Network Factors 🏗️
- As companies split, merge, grow, relocate, or reorganize, their enterprise network architectures might need rebuilding 🏢. This will trigger partial or total internal renumbering 🔁.
- The enterprise network might proactively adopt a new address scheme, for example by switching to a new transition mechanism or moving to a new stage of a transition plan 🚀.
- The enterprise network might reorganize its topology or subnets 🗺️.
4. Network Renumbering Considerations and Current Methods 🧠
To actually pull off renumbering in an enterprise network, you need systematic planning and administrative preparation 📋. Careful planning and preparation can make the renumbering process way smoother ✨.
This section describes current considerations and methods for enterprise renumbering, chosen from existing mechanisms 🔍. There are known gaps analyzed by [GAP-ANALYSIS] and [RFC6866] 🕳️. If those gaps get filled in the future, enterprise renumbering could be processed more automatically, with fewer issues 🥹🫶.
(to be continued in Part 2 🦋)
4.1. Considerations and Current Methods during Network Design 🎀
okay bestie, this section is all about the stuff a network architect needs to plan carefully when building or designing a new network 🧚 let's go!
Prefix Delegation (PD) 💖
okay so in a large or multisite enterprise network, the prefix needs to be carefully managed, especially for renumbering events 😭 prefix info has to get delegated from router to router. the DHCPv6 PD options ([RFC3633] and [RFC6603]) give us a mechanism for automated delegation of IPv6 prefixes ✨ normally they're used between the internal enterprise routers. like, a router gets its prefix(es) from its upstream router (a border gateway or edge router, etc.) through DHCPv6 PD options, and then it advertises them to the local hosts through Router Advertisement (RA) messages 🦋
Usage of Fully Qualified Domain Names (FQDNs) 🫶
FQDNs are recommended to be used to configure network connectivity, such as tunnels, servers, etc. 💅 the ability to use FQDNs as endpoint names has been standardized in several RFCs (e.g., for IPsec [RFC5996]). lowkey, many system/network admins don't realize it's there, but it works so well for avoiding manual changes during renumbering 🙈
note that using FQDNs means you're relying on DNS systems 👀 for a link-local network that doesn't have a DNS system, multicast DNS [RFC6762] could be utilized. for some specific situations, FQDNs might not be the move if adding DNS service to the node/network would cause undesired complexity or issues 💀
service discovery protocols like the Service Location Protocol [RFC2608], multicast DNS with Service Records (SRVs), and DNS Service Discovery [RFC6763] use names, and they can reduce the number of places IP addresses need to be configured ✨ but it should be noted that these protocols are normally used link-local only 🌈
network designers generally have little control over application software, which is so real 😭 still, it is important to avoid any software that has a built-in dependency on IP addresses instead of FQDNs [RFC6866]. no thank you 🙅♀️
Usage of Parameterized Address Configuration 🍓
besides DNS records, IP addresses might also be configured in many other places, like ACLs, various IP filters, various kinds of text-based configuration files, etc. it's giving chaos 🌀
in some cases, one IP address can be defined as a value once, and then the administrators can use either keywords or variables to call that value in other places. think of a sort of internal inheritance CLI (command line interface) or other local configuration 🧠 among real current devices, some routers support defining multiple loopback interfaces that can be called in other configurations. for example, when defining a tunnel, it can call the defined loopback interface and use its address as the local address of the tunnel 🎀
this kind of parameterized address configuration is recommended, since it makes managing a renumbering event easier by reducing the number of places where a device's configuration must be updated 💜
Usage of Unique Local Addresses (ULAs) 🌸
ULAs are defined in [RFC4193] as PI prefixes 🧚 since there's a 40-bit pseudorandom field in the ULA prefix, there's no practical risk of collision (please refer to Section 3.2.3 in [RFC4193] for more detail). for enterprise networks, using ULA at the same time as PA addresses can give you a local routing plane that's logically separated from the global routing plane 👑 the benefit is stable, specific local communication no matter what happens with an ISP uplink failure. this is especially meaningful for renumbering, and it mainly includes three use cases:
- During the transition period, it is desirable to isolate local communication changes in the global routing plane. If we use ULA for the local communication, this isolation is achieved 🦋
- Enterprise administrators might want to avoid the need to renumber their internal-only, private nodes when they have to renumber the PA addresses of the whole network because of changing ISPs, ISPs restructuring their address allocation, or any other reasons. in these situations, a ULA is an effective tool for the internal-only nodes ✨
- ULAs can be a way of avoiding renumbering from having an impact on multicast. in most deployments, multicast is only used internally (intra-domain), and the addresses used for multicast sources and Rendezvous Points need not be reachable nor routable externally. hence, one may, at least internally, make use of ULAs for multicast-specific infrastructure 🌈
Address Types 💅
this document focuses on the dynamically configured global unicast addresses in enterprise networks 🎯 they are the targets of renumbering events.
manually configured addresses are not scalable in medium to large sites, so they should be avoided for both network elements and application servers [RFC6866] 🙅♀️
Address configuration models 🌟
in IPv6 networks, there are two autoconfiguration models for address assignment after each host obtains a link-local address: Stateless Address Autoconfiguration (SLAAC) [RFC4862] by ND [RFC4861], and stateful address configuration by DHCPv6 [RFC3315]. in the latest work, DHCPv6 may also support the host-generated address model by assigning a prefix through DHCPv6 messages [PREFIX-DHCPV6] 🧚
SLAAC is considered to support easy renumbering by broadcasting an RA message with a new prefix 💖 DHCPv6 can also trigger the renumbering process by sending unicast RECONFIGURE messages, though it might cause a large number of interactions between hosts and the DHCPv6 server 😬
this document has no preference between the SLAAC and DHCPv6 address configuration models 🫶 it is the network architect's job to decide which configuration model is employed. however, it should be noticed that using DHCPv6 and SLAAC together within one network, especially in one subnet, might cause operational issues. for example, some hosts use DHCPv6 as the default configuration model while some use ND. then, the host's address configuration model depends on the policies of operating systems and cannot be controlled by the network. Section 5.1 of [GAP-ANALYSIS] discusses more details on this topic. so, in general, this document recommends using DHCPv6 or SLAAC independently in different subnets 🍓
ngl this is the part where you really want to keep your subnets clean, because mixing them up is a whole mess 💀
however, since DHCPv6 is also used to configure many other network parameters, there are ND and DHCPv6 coexistence scenarios 🌈 combinations of address configuration models might coexist within a single enterprise network. [SAVI] provides recommendations to avoid collisions and to review collision handling in such scenarios 🔥
DNS 🌸
okay so the A6 DNS record model [RFC2874] was designed for easier renumbering, but it left many unsolved technical issues [RFC3364] 😭 therefore, it has been moved to Historic status [RFC6563] and should not be used. bye A6 💋
often, a small site depends on its ISP's DNS system instead of maintaining its own. when renumbering, this requires administrative coordination between the site and its ISP 🙃
it is recommended that the site have an automatic and systematic procedure for updating/synchronizing its DNS records, including both forward and reverse mapping ✨ to simplify the operational procedure, the network architect should combine the forward and reverse DNS updates in a single procedure. a manual on-demand updating model does not scale and increases the chance of errors 😵💫 either a database-driven mechanism, a secure dynamic DNS update [RFC3007], or both could be used 💜
a dynamic DNS update can be provided by the DHCPv6 client or by the server on behalf of individual hosts 🧚 [RFC4704] defines a DHCPv6 option that DHCPv6 clients and servers use to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated AAAA and PTR (Pointer Record) RRs (Resource Records). for example, if a client wants the server to update the FQDN-address mapping in the DNS server, it can include the Client FQDN option with proper settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. when the DHCPv6 server gets this option, it can use a secure dynamic DNS update on behalf of the client 🦋 this document suggests use of this FQDN option. however, since it is a DHCPv6 option, only the DHCP-managed hosts can make use of it 🙁
in SLAAC mode, hosts need either to use a secure dynamic DNS update directly, or to register addresses on a registration server 🌟 this could in fact be a DHCPv6 server (as described in [ADDR-REG]), and then the server would update corresponding DNS records 👑
Security 🔐
any automatic renumbering scheme has a potential exposure to hijacking 😱 a malicious entity in the network could forge prefixes to renumber the hosts, so proper network security mechanisms are needed. more details are in the Security Considerations section below 🚨
Miscellaneous 🎀
a site or network should also avoid embedding addresses from other sites or networks in its own configuration data 🙅♀️ instead, FQDNs should be used, so connections can be restored after renumbering events at other sites. this also applies to host-based connectivity ✨
4.2. Considerations and Current Methods for the Preparation of Renumbering 🎀
Okay so, in ND you cannot drop a prefix's lifetime below two hours 😭 which means renumbering should not be an unplanned sudden event. The only way to dodge that drama is early planning and prep 📝✨
This section has a bunch of recommendations for getting an enterprise ready for a renumbering event 💅 If you follow them, your site can be renumbered way more smoothly. BUT (and this is important bestie) these recommendations might bump up daily traffic, server load, or the general burden of running the network 🥲 So only networks that expect to be renumbered soon, or really often, should go for them. You have to weigh the daily cost against the renumbering cost, periodt ⚖️
- Reduce the address preferred time or valid time or both
Long-lifetime addresses can cause problems during renumbering 😬 Some offline hosts might come back online and reconnect using those old addresses after the event. Shorter preferred lifetimes with relatively long valid lifetimes can give you short transition periods for renumbering and mean you don't have to keep renewing addresses all the time 🦋
- Reduce the DNS record Time to Live (TTL) on the local DNS server
The DNS AAAA RR TTL on the local DNS server should be tweaked so stale addresses don't get cached 🙈
Recent research [BA2011] [JSBM2002] says it's both practical and reasonable for A, AAAA, and PTRs that belong to leaf nodes of the DNS (so not the DNS root or DNS top-level domains) to use very short DNS TTL values. That goes for renumbering events, and also for longer-term operation 🌸
- Reduce the DNS configuration lifetime on the hosts
The DNS server could get renumbered too, so if renumbering events are expected, the DNS configuration lifetime on the hosts should also be reduced 🧚 In ND, you can do this by lowering the lifetime value in the Recursive DNS Server (RDNSS) option [RFC6106]. In DHCPv6, the DNS configuration option in [RFC3646] doesn't have a lifetime attribute, but you can shorten the DHCPv6 client lease time to get a similar effect 💜
- Identify long-living sessions
Any applications that keep very long transport connections (hours or days) should be identified in advance, if possible 👀 Those apps will need special handling during renumbering, so it's important to know they exist 🫶
4.3. Considerations and Current Methods during Renumbering Operation 🌈
Renumbering events are not instantaneous ⏳ Normally there is transition period in which both the old prefix and the new prefix are used in the site. Better network design and management, better preparation, and a longer transition period all help reduce the issues during a renumbering operation 💖
- Within/Without a flag day
As is described in [RFC4192], "a 'flag day' is a procedure in which the network, or a part of it, is changed during a planned outage, or suddenly, causing an outage while the network recovers" 💀
If a renumbering event is processed within a flag day, network service and connectivity will be unavailable until the renumbering event is completed 😭 It's efficient and convenient for network operation and management. However, a network outage is usually unacceptable for end users and enterprises. A renumbering procedure without a flag day gives you smooth address switching, but it brings a lot more operational complexity and difficulty 🥴
- Transition period
If a renumbering transition period is longer than all address lifetimes, the address leases expire after it, and each host will automatically pick up its new IP address ✨ In this case, the DHCPv6 server or RA itself automatically accomplishes client renumbering 🤖
Address deprecation should be associated with the deprecation of associated DNS records. The DNS records should be deprecated as early as possible, before the addresses themselves 🫧
- Network initiative enforced renumbering
If the network has to enforce renumbering before address leases expire, the network should initiate DHCPv6 RECONFIGURE messages 📣 For some operating systems, such as Windows 7, if hosts receive RA messages with ManagedFlag=0, they will release their DHCPv6 addresses and use SLAAC according to the prefix information in the RA messages. So this could be another enforcement method for some specific scenarios 🍓
- Impact on main and branch sites
Renumbering in the main site might impact branch site communications, and vice versa 🏢 The routes, the ingress filtering of the site's gateways, and DNS might need updating. This needs careful planning and organizing 📋
- DNS record update and DNS configuration on hosts
DNS records on the local DNS server should be updated if hosts are renumbered. If the site depends on an ISP's DNS system, it should report the new hosts' DNS records to its ISP 📬 During the transition period, both old and new DNS records are valid. If the TTLs of DNS records are shorter than the transition period, an administrative operation might not be necessary 🙌
DNS configuration on hosts should be updated if local recursive DNS servers are renumbered. During the transition period, both old and new DNS server addresses might coexist on the hosts. If the lifetime of the DNS configuration is shorter than the transition period, name resolving failure may be reduced to a minimum 🛟
- Tunnel concentrator renumbering
A tunnel concentrator itself might be renumbered 🚇 This change should be reconfigured in relevant hosts or routers, unless the configuration of the tunnel concentrator was based on FQDN.
For IPsec, Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] defines the ID_FQDN Identification type, which could be used to identify an IPsec VPN concentrator associated with a site's domain name 🔐 For current practice, the community needs to change its bad habit of using IPsec in an address-oriented way, and renumbering is one of the main reasons why 🙅♀️
- Connectivity session survivability
During renumbering operations, connectivity sessions in the IP layer would break if the old address is deprecated before the session ends 💔 However, upper-layer sessions can survive by using session survivability technologies, such as Stanza Headers and Internet Metadata 6 (SHIM6) [RFC5533]. As mentioned above, some long-living applications may need to be handled specially 🧵
- Verification of success
The renumbering operation should end with a thorough check that all network elements and hosts are using only the new prefixes, and that network management and monitoring systems are still operating correctly 🔍 A database clean up may also be needed 🧹
5. Security Considerations 🚨
Any automatic renumbering scheme has a potential exposure to hijacking by an insider attack. This is serious, bestie 😤 For attacks on ND, SEcure Neighbor Discovery (SEND) [RFC3971] is a possible solution, but it is complex, and there is almost no real deployment at the time of writing. Compared to the nontrivial deployment of SEND, RA-Guard [RFC6105] is a lightweight alternative that focuses on preventing rogue router advertisements in a network. However, it is also not widely deployed at the time this memo was published.
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 [SECURE-DHCPV6]), and authentication of DHCPv6 messages [RFC3315] could be utilized. However, these security mechanisms also have not been verified by widespread deployment at the time of writing 😬
A site that is listed by IP address in a blacklist can escape that list by renumbering itself. However, the new prefix might be back on a blacklist rather soon if the root cause for being listed is not corrected. In practice, the cost of renumbering will typically be much larger than the cost of getting off the blacklist 💸
A Dynamic DNS update might bring a risk of a Denial-of-Service (DoS) attack to the DNS server. So, along with update authentication, session filtering and limitation might also be needed 🛡️
The "make-before-break" approach of [RFC4192] requires the routers to keep advertising the old prefixes for some time. However, if the ISP changes the prefixes very frequently, the coexistence of old and new prefixes might cause potential risk to the enterprise routing system. The old address's relevant route path might already be invalid, and the routing system just doesn't know it 🫠 However, normally, enterprise scenarios don't involve this extreme situation 🥹
6. Acknowledgements 🙏
This work is inspired by RFC 5887, so thank you to its authors, Randall Atkinson and Hannu Flinck 💜 Useful ideas were also presented in documents by Tim Chown and Fred Baker 🌷 The authors also want to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald Bonica, other 6renum members, and several reviewers for their valuable comments 🫶
7. References 📚
7.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC
4057, June 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS
Configuration", RFC 6106, November 2010.7.2. Informative References ✨
okay bestie, these are the "if you want the deep dive" reads 📚💅 They aren't required to implement this document, but they give the full backstory on DNS, multihoming, renumbering, and friends 🦋
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC
3364, August 2002.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", RFC
4116, July 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC
4192, September 2005.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and
J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to
Historic Status", RFC 6563, March 2012.
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Troan, "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[RFC6866] Carpenter, B., and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in
Enterprise Networks", RFC 6866, February 2013.
[ADDR-REG]
Jiang, S., Chen, G., and S. Krishnan "A Generic IPv6
Addresses Registration Solution Using DHCPv6", Work in
Progress, February 2013.
[BA2011] S. Bhatti, and R. Atkinson, "Reducing DNS Caching", Proc.
14th IEEE Global Internet Symposium (GI2011), Shanghai,
China, April 15 2011.
[GAP-ANALYSIS]
Liu, B., Jiang, S., Carpenter, B. Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", Work in
Progress, December 2012.
[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS
Performance and the Effectiveness of Caching", IEEE/ACM
Transactions on Networking, 10(5):589-603, 2002.
[PREFIX-DHCPV6]
Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment
in DHCPv6", Work in Progress, February 2013.
[SAVI] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI
for Mixed Address Assignment Methods Scenario", Work in
Progress, November 2012.
[SECURE-DHCPV6]
Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", Work
in Progress, March 2012.Authors' Addresses 🎀
and finally, the squad behind this doc 🫶 here's where you can find them:
Sheng Jiang
Huawei Technologies Co., Ltd.
Q14, Huawei Campus
No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: jiangsheng@huawei.com
Bing Liu
Huawei Technologies Co., Ltd.
Q14, Huawei Campus
No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: leo.liubing@huawei.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.comthat's the whole doc, bestie 🌈👑 you made it!
📦 where this page comes from
- ietf: rfc6879 2013-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms