RFC 6992
Routing for IPv4-Embedded IPv6 Packets
RFC 6992: Routing for IPv4-Embedded IPv6 Packets 💖 (Part 1 of 4)
Okay bestie, let's get into it 🎀 This is RFC 6992, titled Routing for IPv4-Embedded IPv6 Packets. It's an Informational doc, so it's not a Standards Track thing, and it came out in July 2013. The authors are D. Cheng (Huawei Technologies), M. Boucadair (France Telecom), and A. Retana (Cisco Systems). It's listed under ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates 🦋
Abstract
This doc describes a routing setup where IPv4 packets get carried over an IPv6 network. It uses the methods from RFCs 6145 and 6052, plus a separate OSPFv3 routing table just for IPv4-embedded IPv6 routes in the IPv6 network ✨
Status of This Memo
Real talk, this is not an Internet Standards Track spec. It's published for informational purposes 🧚
This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 👑
You can find out the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6992 💅
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 stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜
Table of Contents
1. Introduction ....................................................2
1.1. The Scenario ...............................................3
1.2. Routing Solution per RFC 5565 ..............................4
1.3. An Alternative Routing Solution with OSPFv3 ................4
1.4. OSPFv3 Routing with a Specific Topology ....................6
2. Requirements Language ...........................................7
3. Provisioning ....................................................7
3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
4. Translation of IP Packets .......................................8
4.1. Address Translation ........................................8
5. Advertising IPv4-Embedded IPv6 Routes ...........................9
5.1. Advertising IPv4-Embedded IPv6 Routes through an
IPv6 Transit Network .......................................9
5.1.1. Routing Metrics .....................................9
5.1.2. Forwarding Address .................................10
5.2. Advertising IPv4 Addresses into Client Networks ...........10
6. Aggregation on IPv4 Addresses and Prefixes .....................10
7. Forwarding .....................................................10
8. Backdoor Connections ...........................................11
9. Prevention of Loops ............................................11
10. MTU Issues ....................................................11
11. Security Considerations .......................................12
12. Operational Considerations ....................................13
13. Acknowledgements ..............................................14
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................141. Introduction ✨
This doc describes a routing setup where IPv4 packets get carried over an IPv6 network, based on [RFC6145] and [RFC6052]. It also uses a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. Important note: this doc does not introduce any new IPv6 transition mechanism 🦋
Here's the terminology we're using:
- An IPv4-embedded IPv6 address is an IPv6 address that contains an embedded 32-bit IPv4 address, built according to the rules in [RFC6052] 🎀
- IPv4-embedded IPv6 packets are packets whose destination addresses are IPv4-embedded IPv6 addresses 💖
- AFBR (Address Family Border Router) [RFC5565] is an edge router that supports both the IPv4 and IPv6 address families, but the backbone network it connects to only supports one of them, either IPv4 or IPv6 🌸
- AFXLBR (Address Family Translation Border Router) is defined in this doc. It's a border router that supports both IPv4 and IPv6 address families. It sits on the boundary between an IPv4-only network and an IPv6-only network, and it can do IP header translation between IPv4 and IPv6 [RFC6145] 👑
1.1. The Scenario
Because public IPv4 addresses are running out, the IETF has been working for a while on investigating and specifying IPv6 transition techniques 😭 During the transition, it's basically certain that IPv4-based and IPv6-based networks will coexist, at least for some time 🍓 One such scenario is interconnecting IPv4-only and IPv6-only networks. It gets especially relevant when an IPv6-only network acts as the interconnection between several segregated IPv4-only networks ✨ In this scenario, IPv4 packets get transported across the IPv6 network between IPv4 networks. To forward an IPv4 packet from a source IPv4 network to a destination IPv4 network, IPv4 reachability information must be exchanged between those IPv4 networks through some mechanism 💅
Running an IPv6-only network generally reduces operational expenditures and optimizes operations compared to an IPv4-IPv6 dual-stack environment. Some proposed solutions let you deliver IPv4 services over an IPv6-only network 🌈 This doc specifies an engineering technique that separates the routing table for IPv4-embedded IPv6 destinations from the routing table used for native IPv6 destinations 🫶
OSPFv3 is designed to support multiple instances. Keeping a separate routing table for IPv4-embedded IPv6 routes would simplify implementation, troubleshooting, and operation. It would also keep the native IPv6 routing table from getting overloaded 🧚 A separate routing table can be generated from a separate routing instance 💜
1.2. Routing Solution per RFC 5565
The scenario above is described in [RFC5565], which is the IPv4-over-IPv6 scenario. The network core is IPv6-only, and the IPv4 networks it interconnects are called IPv4 client networks 👑 The P Routers (Provider Routers) in the core only support IPv6. The AFBRs support IPv4 on interfaces facing the IPv4 client networks, and IPv6 on interfaces facing the core 🔥
The routing solution [RFC5565] defines for this scenario is to run IBGP among the AFBRs, so IPv4 routing information gets exchanged in the core. IPv4 packets are forwarded from one IPv4 client network to the other through a softwire, using tunneling technology such as MPLS, LSP, GRE, L2TPv3, etc. 🦋✨
1.3. An Alternative Routing Solution with OSPFv3 💖
Okay so, this doc proposes a different routing solution for the scenario from Section 1.1 🎀. Picture several segregated IPv4 networks (called IPv4 client networks) all linked together by one IPv6 network 🦋. The IPv6 network and those IPv4 networks may or may not be in the same Autonomous System (AS), which is very much a "depends on your setup" situation ✨.
The border node that sits on the edge of an IPv4 client network and the IPv6 network is called an Address Family Translation Border Router (AFXLBR) 🧚. It's giving multitasker: it speaks both the IPv4 and IPv6 address families, and it can translate an IPv4 packet into an IPv6 packet and back again, following [RFC6145] 💅. Figure 1 shows the whole setup, so go look at it 👀.
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+Figure 1: Segregated IPv4 Networks Interconnected by an IPv6 Network
Since this scenario mostly happens inside a single organization 🏢, an IPv6 prefix can be allocated locally and used by the AFXLBRs to build IPv4-embedded IPv6 addresses [RFC6052] 🌸. The embedded IPv4 address or prefix belongs to an IPv4 client network hooked up to that AFXLBR. Each AFXLBR injects its IPv4-embedded IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and it also installs the IPv4-embedded IPv6 routes that other AFXLBRs advertise 🚀.
Here's the flow. When an AFXLBR gets an IPv4 packet from a locally connected IPv4 client network that's headed for a remote IPv4 client network, it translates the IPv4 header into the matching IPv6 header [RFC6145] 🔄. During that step, the source and destination IPv4 addresses become IPv4-embedded IPv6 addresses [RFC6052]. The new IPv6 packet then gets forwarded to the AFXLBR connected to the destination IPv4 client network 📦. That remote AFXLBR pulls the IPv4 source and destination addresses back out of the IPv4-embedded IPv6 addresses [RFC6052], and translates the received IPv6 header into the right IPv4 header [RFC6145] ✨. Finally, the resulting IPv4 packet is forwarded using the IPv4 routing table on that AFXLBR 🎀.
There are a few situations where this routing solution really shines 🌈. First, some border nodes don't take part in IBGP for route exchange, or IBGP isn't used at all 😭. Second, tunnels aren't deployed in the IPv6 network, or native IPv6 forwarding is the preferred option 🫶. And a big bonus: with this solution, the IPv4 and IPv6 header translation the AFXLBR does in both directions is stateless 💜.
1.4. OSPFv3 Routing with a Specific Topology 🧩
Generally speaking, IPv4-embedded IPv6 packets can be forwarded just like native IPv6 packets when OSPFv3 runs in the IPv6 network 🚦. The catch? That would mean every IPv4-embedded IPv6 route gets flooded across the entire IPv6 network and stored on every single router 😩. That's not great for scaling 📉. Also, since all IPv6 routes live in the same routing table, it'd be a hassle to manage the routing and forwarding resources by traffic category, if that's something you want to do 🙈.
So to make things better, you can build a separate OSPFv3 routing table that's dedicated to the IPv4-embedded IPv6 topology 💅. That table is used only for routing IPv4-embedded IPv6 packets across the IPv6 network 🍓. This topology includes all the participating AFXLBRs plus a set of P Routers that give redundant connectivity with alternate routing paths 🛤️.
To make it happen, a separate OSPFv3 instance is configured in the IPv6 network [RFC5838] 🎀. This instance runs on all the participating AFXLBRs and on the set of P routers that interconnect them. The result is a dedicated IPv4-embedded IPv6 topology maintained on all of these routers, along with its own dedicated IPv4-embedded IPv6 routing table 🌟. That table in the IPv6 network exists purely to forward IPv4-embedded IPv6 packets 💖.
This document explains how to configure this method and walks through the related routing issues 📝. Just so you know, it only covers unicast routing for IPv4-embedded IPv6 packets using OSPFv3 🦋.
2. Requirements Language 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] ✨.
3. Provisioning 🛠️
3.1. Deciding on the IPv4-Embedded IPv6 Topology 🗺️
Before you deploy configurations that use a separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and prefixes, you need to decide which routers and interfaces in the IPv6 network belong in the IPv4-embedded IPv6 topology 🤔.
For this topology, every AFXLBR that connects to an IPv4 client network MUST be a member. An AFXLBR MUST have at least one connection to a P Router in the IPv6 network or to another AFXLBR 🔗.
The IPv4-embedded IPv6 topology is a subtopology of the whole IPv6 network. If you include all routers (AFXLBRs and P routers) and all of their interfaces, the two topologies end up being the same thing 🫠. In general, the more interconnected P Routers you put in this subtopology, the more routing paths there are from one IPv4 client network to another 🛣️. The tradeoff is that more routers in the IPv6 network then have to take part in IPv4-embedded IPv6 routing 😅. Whatever you pick, the IPv4-embedded IPv6 topology MUST be continuous, with no partitions 💜.
3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table 📚
In an IPv6 network, OSPFv3 needs to use the mechanism defined in [RFC5838] to keep a separate IPv6 routing table with routes for IPv4-embedded IPv6 destinations only 🎯.
This document assumes the IPv6 network that interconnects with IPv4 networks is under one administration. Because of that, an OSPFv3 Instance ID (IID) gets allocated locally and used for OSPFv3 operations dedicated to unicast IPv4-embedded IPv6 routing in the IPv6 network 🏷️. This IID is configured on the OSPFv3 router interfaces that take part in the IPv4-embedded IPv6 topology 🌈.
A locally configured OSPFv3 IID is allocated from the range 192 to 255, inclusive, in the "OSPFv3 Instance ID Address Family Values" registry. That range is reserved for "Private Use" [RFC6969] 🔐. This IID must be used to encode the "Instance ID" field in the packet header of OSPFv3 packets belonging to the OSPFv3 instance 💅.
On top of that, the AF-bit in the OSPFv3 Option field MUST be set 🚩.
During Hello packet processing, an adjacency can only be established when the received Hello packet has the same Instance ID as the one configured on the receiving OSPFv3 interface 🤝. This makes sure that only interfaces configured as part of the OSPFv3 unicast IPv4-embedded IPv6 topology get used for IPv4-embedded IPv6 unicast routing 🛡️.
For more details, check out [RFC5838] 📖.
4. Translation of IP Packets 🔁
When IPv4 packets travel across an IPv6 network through the mechanism described above (Section 3.2) 🚇, an IPv4 packet gets translated into an IPv6 packet at the ingress AFXLBR. The IPv6 packet then gets translated back into an IPv4 packet at the egress AFXLBR 🎬. This IP packet header translation is done statelessly, following the rules in [RFC6145]. The details of address translation come in the next subsection 👇.
4.1. Address Translation 🏠
Before any address translation happens, the operator allocates an IPv6 prefix, and that prefix is used to form IPv4-embedded IPv6 addresses 🧁.
The IPv6 prefix can be either the IPv6 well-known prefix (WKP) 64:ff9b::/96, or a network-specific prefix that's unique to the organization. For the second option, the IPv6 prefix length may be 32, 40, 48, 56, or 64 🌺. Either way, this IPv6 prefix is used during the address translation between an IPv4 address and an IPv4-embedded IPv6 address, as described in [RFC6052] 🌷.
When translating from an IPv4 header to an IPv6 header at an ingress AFXLBR, the source and destination IPv4 addresses become the matching source and destination IPv6 addresses, respectively 🪄. When translating from an IPv6 header to an IPv4 header at an egress AFXLBR, the source and destination IPv6 addresses become the matching source and destination IPv4 addresses, respectively 🔙. Address translation is done statelessly 💫.
Now, if you're using the IPv6 WKP, [RFC6052] only allows global IPv4 addresses to be embedded in the IPv6 address 🌍. So an IPv6 address made of a WKP plus a non-global IPv4 address is invalid, and any packets carrying such an address that an AFXLBR receives get dropped 🚫.
If both the IPv4 client networks and the IPv6 transit network belong to the same organization, non-global IPv4 addresses can be used together with a network-specific prefix [RFC6052] 🏢✨.
5. Advertising IPv4-Embedded IPv6 Routes 📣
For IPv4 packets to reach the right destination across an IPv6 network, IPv4 reachability information has to be spread throughout that IPv6 network 🗞️. This job belongs to the AFXLBRs that connect to IPv4 client networks, and they do it using OSPFv3 📡.
In the scenario this document describes, a set of AFXLBRs interconnects multiple IPv4 client networks with an IPv6 network. The IPv4 and IPv6 networks may belong to the same Autonomous System (AS) or to separate ones, and either way, these AFXLBRs behave as AS Boundary Routers (ASBRs) 👑.
5.1. Advertising IPv4-Embedded IPv6 Routes through an IPv6 Transit Network 🚌✨
Okay so, IPv4 addresses and prefixes sitting in an IPv4 client network get turned into IPv4-embedded IPv6 addresses and prefixes 💅. The way that works is you use the IPv6 prefix the operator allocated plus the method in [RFC6052]. Then one or more attached ASBRs advertise those routes into the IPv6 transit network using AS-External-LSAs [RFC5340], so the advertising scope is the entire Autonomous System 🌍.
5.1.1. Routing Metrics 📊
By default, the metric in an AS-External-LSA that carries an IPv4-embedded IPv6 address or prefixes is a Type 1 external metric 🎀. That's comparable to the link state metric, and we're assuming that in most cases OSPFv2 is running in the client IPv4 networks. This metric gets added to the metric of the intra-AS path to the ASBR during the OSPFv3 route calculation.
Through ASBR configuration, the metric can be set to a Type 2 external metric, which is considered much larger than the metric for any intra-AS path 👑. Refer to the OSPFv3 specification [RFC5340] for more details. Either way, an external metric may take the same value as in an IPv4 network (using OSPFv2 or another routing protocol), but it may also be specified based on some routing policy. Those details are beyond the scope of this document, so we're leaving them alone 🫶.
5.1.2. Forwarding Address 🧭
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is used to carry an IPv6 address, that address must also be an IPv4-embedded IPv6 address where the embedded IPv4 address is the destination address in an IPv4 client network. Bestie, here's the twist 😭: since an AFXLBR sits on the border of an IPv4 network and an IPv6 network, it is RECOMMENDED that the "Forwarding Address" field not be used. That way the AFXLBR can make the forwarding decision based on its own IPv4 routing table 🦋.
5.2. Advertising IPv4 Addresses into Client Networks 📣
IPv4-embedded IPv6 routes that were injected into the IPv6 network from one IPv4 client network MAY be advertised into another IPv4 client network, after the associated destination addresses and prefixes are translated back to IPv4 addresses and prefixes, respectively. This is basically the same vibe as normal OSPFv3 operation, where an AS-External-LSA can be advertised in a non-backbone area by default 💖.
An IPv4 client network can limit which advertisements it receives through configuration 🌸.
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT be advertised into any IPv6 client networks that are also connected to the IPv6 transit network 🙅♀️. Not me, not allowed 💀.
6. Aggregation on IPv4 Addresses and Prefixes 🧺
To cut down on the amount of Link State Advertisements (LSAs) getting injected into the IPv6 network, an implementation should provide mechanisms to aggregate IPv4 addresses and prefixes at an AFXLBR before they're advertised as IPv4-embedded IPv6 addresses and prefixes 🍓. In general, the aggregation practice should be based on routing policy, which is beyond the scope of this document.
7. Forwarding 🚀
There are three cases for forwarding IP packets in the scenario described in this document, and they're all kind of iconic 👑:
- On an AFXLBR, if an IPv4 packet is received on an interface connecting to an IPv4 segregated client network with a destination IPv4 address belonging to another IPv4 client network, the header of the packet is translated to the corresponding IPv6 header as described in Section 4. Then the packet is forwarded to the destination AFXLBR that advertised the IPv4-embedded IPv6 address into the IPv6 network 💌.
- On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the embedded destination IPv4 address is in its IPv4 routing table, the header of the packet is translated to the corresponding IPv4 header as described in Section 4. Then the packet is forwarded accordingly 🎯.
- On any router that is within the IPv4-embedded IPv6 topology subset of the IPv6 network, if an IPv4-embedded IPv6 packet is received and a route is found in the IPv4-embedded IPv6 routing table, the packet is forwarded to the IPv6 next hop. It's handled just like a normal IPv6 packet, without any translation 🧚.
The classification of an IPv4-embedded IPv6 packet is done according to the IPv6 prefix of the destination address. That prefix is either the WKP (i.e., 64:ff9b::/96) or locally allocated as defined in [RFC6052] 🔍.
8. Backdoor Connections 🚪
In some deployments, IPv4 client networks are interconnected across the IPv6 network but are also directly connected to each other. Those direct connections, sometimes called "backdoor" connections, can definitely be used to transport IPv4 packets between IPv4 client networks 🤫. In general, backdoor connections are preferred over the IPv6 network, since no address family translation is required ✨.
9. Prevention of Loops 🔁
If an LSA sent from an AFXLBR into a client network could then be received by another AFXLBR, routing loops could happen. Yikes 😬. To prevent loops, an AFXLBR MUST set the DN bit [RFC4576] in any LSA that it sends to a client network. The AFXLBR MUST also ignore any LSA received from a client network that already has the DN bit set 🛑.
10. MTU Issues 📏
In the IPv6 network, there are no new MTU issues introduced by this document, so that's a relief 🥹. If a separate OSPFv3 instance (per [RFC5838]) is used for IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is the same as that of the default OSPFv3 instance.
However, the MTU in the IPv6 network may be different than that of IPv4 client networks. Since an IPv6 router will never fragment a packet, the packet size of any IPv4-embedded IPv6 packet entering the IPv6 network must be equal to or less than the MTU of the IPv6 network 🧱. To make that happen, it is recommended that AFXLBRs perform IPv6 path discovery among themselves. The resulting MTU, after taking into account the difference between the IPv4 header length and the IPv6 header length, must be "propagated" into IPv4 client networks. For example, it can be included in the OSPFv2 Database Description packet 💜.
The details of passing the proper MTU into IPv4 client networks are beyond the scope of this document.
11. Security Considerations 🔐
Okay, this section is serious, bestie, so pay attention 😤🚨. There are several security aspects that require attention in the deployment practices described in this document.
In the OSPFv3 transit network, the security considerations for OSPFv3 are handled as usual. In particular, the authentication mechanisms described in [RFC6506] can be deployed 🛡️.
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 routing, the same Security Association (SA) [RFC4552] MUST be used by the embedded IPv4 address instance as other instances utilizing the same link, as specified in [RFC5838] 🔑.
Security considerations documented in [RFC6052] must also be thought through and properly implemented, including the following:
- The IPv6 prefix that is used to carry an embedded IPv4 address (refer to Section 4.1) must be configured by the authorized operator on all participating AFXLBRs in a secure manner. This is to help prevent a malicious attack resulting in network disruption, denial of service, and possible information disclosure 🚫💥.
- Effective mechanisms (such as reverse path checking) must be implemented in the IPv6 transit network (including AFXLBRs) to prevent spoofing of embedded IPv4 addresses. Those addresses otherwise might be used as source addresses of malicious packets 🕵️♀️.
- If firewalls are used in IPv4 and/or IPv6 networks, the configuration of the routers must be consistent, so that there are no holes in IPv4 address filtering 🧱.
The details of security handling are beyond the scope of this document.
12. Operational Considerations 🛠️
This document puts together some mechanisms based on existing technologies developed by the IETF as an integrated solution for transporting IPv4 packets over an IPv6 network using a separate OSPFv3 routing table 🧩. There are several aspects of these mechanisms that require attention for deployment and operation.
The tunnel-based solution documented in [RFC5565] and the solution proposed in this document are both used for transporting IPv4 packets over an IPv6 network, but they use different mechanisms. The two methods aren't related to each other, and they can coexist in the same network if deployed that way, without any conflict 🤝.
If one approach is going to be deployed, the operator decides which approach to use. Each approach has its own characteristics and requirements 📋. For example, the tunnel-based solution requires a mesh of inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as IBGP to exchange routes between AFBRs [RFC5565]. The approach in this document requires AFXLBRs that are capable of performing IPv4-IPv6 packet header translation per [RFC6145] 🎀.
To deploy the solution as documented here, some configurations are required. First, an IPv6 prefix must be chosen that is used to form all the IPv4-embedded IPv6 addresses and prefixes advertised by AFXLBRs in the IPv6 network. Refer to Section 4.1 for details. The IPv4-embedded IPv6 routing table is created by using a separate OSPFv3 instance in the IPv6 network. As described in Section 3.2, this configuration is accomplished according to the mechanism described in [RFC5838] ⚙️.
Note that this document does not change any behavior of OSPFv3, so the existing or common practice should apply in the context of scalability. For example, the number of routes advertised by OSPFv3 is one key concern 📈. With the solution described in this document, IPv4-embedded IPv6 addresses and prefixes will be injected by AFXLBRs into some part of the IPv6 network (see Section 3.1 for details), and a separate routing table will be used for IPv4-embedded IPv6 routing. Care must be taken during network design so that 1) aggregations are performed on IPv4 addresses and prefixes before being advertised in the IPv6 network, as described in Section 6, and 2) estimates are made of the number of IPv4-embedded IPv6 routes that would be disseminated in the IPv6 network and of the size of the separate OSPFv3 routing table 🧮.
13. Acknowledgements 💌
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand, and Brian Carpenter for their comments 🫶🌈.
14. References 📚
14.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
- [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
- [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
- [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
- [RFC6969] Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry Update", RFC 6969, July 2013.
14.2. Informative References ✨
Okay, bestie, here's the "further reading" shelf 📚💖 These aren't required to implement the spec, but they're the other RFCs it leans on, so they're worth a peek:
- [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. 🔐
- [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 🌐
- [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 🦋
- [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012. 🎀
Authors' Addresses 💅
Meet the brains behind it! These are the people who wrote it, with their contact details kept exactly as they were 🫶
Dean Cheng 🌸
Dean Cheng
Huawei Technologies
2330 Central Expressway
Santa Clara, California 95050
USA
EMail: dean.cheng@huawei.comMohamed Boucadair 🧚
Mohamed Boucadair
France Telecom
Rennes, 35000
France
EMail: mohamed.boucadair@orange.comAlvaro Retana 👑
Alvaro Retana
Cisco Systems
7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709
USA
EMail: aretana@cisco.comAnd that's a wrap on RFC 6992, periodt! 🌈✨
📦 where this page comes from
- ietf: rfc6992 2013-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms