RFC 6144
Framework for IPv4/IPv6 Translation
🎀 part 1 of 7 bestie, more parts are coming!
RFC 6144: Framework for IPv4/IPv6 Translation 💖
okay so this is RFC 6144, titled Framework for IPv4/IPv6 Translation ✨. It's an Informational document, which means it's published for information and is not an Internet Standards Track spec 🎀. It came out in April 2011 and has the ISSN 2070-1721 🌸.
The authors are F. Baker (Cisco Systems), X. Li (CERNET Center/Tsinghua University), C. Bao (CERNET Center/Tsinghua University), and K. Yin (Cisco Systems) 🫶. Bao and Li are at the CERNET Center/Tsinghua University, and Baker and Yin are at Cisco Systems. This header has no Obsoletes or Updates line, so it doesn't obsolete or update any other RFC 💅.
Abstract
okay so the abstract is basically: this note is a framework for IPv4/IPv6 translation 🦋. It's meant to replace NAT-PT (Network Address Translation - Protocol Translation), which got deprecated by RFC 4966 💀. The bigger goal is helping networks let IPv4 and IPv6 coexist in a somewhat rational way while they move over to IPv6 ✨.
Status of This Memo
this part is the legal-ish bit, but ngl it's important 🙈. This document is not an Internet Standards Track specification. It's published just for information 🌈.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧚.
For info about the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6144 🍓.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were in effect on the publication date. Please read these carefully, because they describe your rights and restrictions for this document 🫶. 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 without warranty as described in the Simplified BSD License ⭐.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7
1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 9
2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 11
2.1. Scenario 1: An IPv6 Network to the IPv4 Internet . . . . . 12
2.2. Scenario 2: The IPv4 Internet to an IPv6 Network . . . . . 13
2.3. Scenario 3: The IPv6 Internet to an IPv4 Network . . . . . 14
2.4. Scenario 4: An IPv4 Network to the IPv6 Internet . . . . . 15
2.5. Scenario 5: An IPv6 Network to an IPv4 Network . . . . . . 16
2.6. Scenario 6: An IPv4 Network to an IPv6 Network . . . . . . 17
2.7. Scenario 7: The IPv6 Internet to the IPv4 Internet . . . . 18
2.8. Scenario 8: The IPv4 Internet to the IPv6 Internet . . . . 19
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Translation Components . . . . . . . . . . . . . . . . . . 19
3.1.1. Address Translation . . . . . . . . . . . . . . . . . 19
3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 21
3.1.3. Maintaining Translation State . . . . . . . . . . . . 21
3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 22
3.1.5. ALGs for Other Applications Layer Protocols . . . . . 22
3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 22
3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 23
3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 24
3.3. Layout of the Related Documents . . . . . . . . . . . . . 26
4. Translation in Operation . . . . . . . . . . . . . . . . . . . 27
5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 291. Introduction ✨
okay so this section is the setup 🎀. It's the same framing as the abstract: a framework for IPv4/IPv6 translation, in the context of replacing NAT-PT (Network Address Translation - Protocol Translation) [RFC2766], which [RFC4966] deprecated. The point is still letting IPv4 and IPv6 coexist in a somewhat rational way while the network moves to an IPv6-only network 💅.
NAT-PT got deprecated to tell everyone that it had operational issues and wasn't a viable medium- or long-term plan for coexistence or transition 😭. It wasn't saying IPv4<->IPv6 translation is bad. The real problem was how NAT-PT did it, and using NAT-PT as a general-purpose fix was the bad part 🙈. This is kind of like how the RIP routing protocol [RFC1923] got deprecated when the Internet switched to Classless Inter-Domain Routing (CIDR): the goal was to nudge operators to actually move off tech with known problems 🦋.
[RFC4213] lays out the IETF's view of the most sensible transition model 🌸. In short, the IETF recommends that network operators (transit providers, service providers, enterprise networks, small and medium businesses, SOHO (Small Office, Home Office) and residential customers, and any other kind of network that might be using IPv4) get an IPv6 prefix, turn on IPv6 routing inside their networks and toward any peer, upstream, or downstream neighbors, enable it on their computers, and use it in normal processing 💜. This should happen while IPv4 stays stable, until a point where any communication could use either protocol equally well ✨. At that point, the economic case for running both gets debatable, and operators can justifiably turn IPv4 off 🧚. This is comparable to [RFC4192], which covers renumbering a network within the same address family without a flag day 🍓. The vibe is: while the old system runs stably, deploy the new one. Use the coexistence period to work out kinks as they show up. Once the new one is also stable, shift production to it. When network and economic conditions allow, remove the old one, since it's no longer necessary 🫶.
Now the question is: what if all that is infeasible because of the time available to deploy or other considerations? 😳 What if the process of moving a network and its components or customers starts too late for contract cycles to bring IPv6 up on important parts, at a point where deploying global IPv4 addresses for new services is uneconomical? How do you keep deploying new services without balkanizing the network? 🥺 This document describes translation as one of the tools networks might use to make coexistence and eventual transition happen 🌈.
1.1. Why Translation? 🦋
okay so besides dual-stack deployment, there are two basic ways to do IPv4/IPv6 interworking: tunneling and translation 💅. People -- and in the [6NET] they did -- build an overlay network that tunnels one protocol over the other 🎀. Lots of proposals go that route, including 6to4 [RFC3056], Teredo [RFC4380], Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and Dual-Stack Lite [DS-LITE] ✨. The upside is that the new protocol can work without messing with the old one, giving connectivity between users of the new protocol 🌸. But tunneling has two downsides:
- Users of the new architecture can't use the services of the underlying infrastructure -- it's just bandwidth, and
- It doesn't let new protocol users talk to old protocol users without dual-stack hosts.
As noted, this work looks at Internet Protocol translation as a transition strategy 🧚. [RFC4864] makes a strong point that people use Network Address Translators for lots of needs, and many of those are also met by routing or protocol mechanisms that keep the end-to-end addressability of the Internet 💖. What it didn't consider is the case where there's an ongoing need to talk to IPv4 systems, but configuring IPv4 routing isn't the operator's most desirable strategy, or it's infeasible because of a shortage of global address space 😭. Translation lets a network's client, whether that's a transit network, an access network, or an edge network, reach the network's services and talk to other users regardless of their protocol usage -- within limits 🫶. Like NAT-PT, IPv4/IPv6 translation under this rubric isn't a long-term support strategy 💀, but it is a medium-term coexistence strategy that can help drive a long-term transition program 🌈.
1.2. Terminology ✨
okay so before we get into the good stuff, we need to agree on what these words mean. this section is the glossary, and it's giving "read this first or you'll be lost" 💅 The following terminology is used in this document and other documents related to it.
IPv4 network: a specific network that has an IPv4-only deployment 🌸 That could be an enterprise's IPv4-only network, an ISP's IPv4-only network, or even an IPv4-only host. The IPv4 Internet is the set of all interconnected IPv4 networks.
IPv6 network: a specific network that has an IPv6-only deployment 🦋 That could be an enterprise's IPv6-only network, an ISP's IPv6-only network, or even an IPv6-only host. The IPv6 Internet is the set of all interconnected IPv6 networks.
DNS46: a DNS translator that translates AAAA record to A record.
DNS64: a DNS translator that translates A record to AAAA record. 🧚
Dual-Stack implementation: in this context, a dual-stack implementation comprises an IPv4/IPv6-enabled end system stack, applications plus routing in the network. It implies that two application instances are capable of communicating using either IPv4 or IPv6 -- they have stacks, they have addresses, and they have any necessary network support including routing. Both stacks, both addresses, all the support. Totally set up 🫶
IPv4-converted addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They have an explicit mapping relationship to IPv4 addresses. Both stateless and stateful translators use IPv4-converted addresses to represent IPv4 addresses. It's giving matching pairs 👯
IPv4-only: in this context, an IPv4-only implementation comprises an IPv4-enabled end system stack, applications directly or indirectly using that IPv4 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv4, but not IPv6 -- they have an IPv4 stack, addresses, and network support including IPv4 routing and potentially IPv4/IPv4 translation, but some element is missing that prevents communication with IPv6 hosts. So close, but something's missing 😭
IPv4-translatable addresses: IPv6 addresses to be assigned to IPv6 nodes for use with stateless translation. They have an explicit mapping relationship to IPv4 addresses. A stateless translator uses the corresponding IPv4 addresses to represent the IPv6 addresses. A stateful translator does not use this kind of addresses, since IPv6 hosts are represented by the IPv4 address pool in the translator via dynamic state. Stateless and stateful are doing two totally different things here, it's so iconic 🎀
IPv6-only: in this context, an IPv6-only implementation comprises an IPv6-enabled end system stack, applications directly or indirectly using that IPv6 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 -- they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts. The IPv4 mirror image of the last one, no cap 🌈
Network-Specific Prefix (NSP): from an IPv6 prefix assigned to a network operator, the operator chooses a longer prefix for use by the operator's translator(s). Hence, a given IPv4 address would have different IPv6 representations in different networks that use different network-specific prefixes. A network-specific prefix is also known as a Local Internet Registry (LIR) prefix. 🍓
State: "State" refers to dynamic information that is stored in a network element. For example, if two systems are communicating using a TCP connection, each stores information about the connection, which is called "connection state". In this context, the term refers to dynamic correlations between IP addresses on either side of a translator, or {IP address, transport protocol, transport port number} tuples on either side of the translator. Of stateful algorithms, there are at least two major flavors depending on the kind of state they maintain:
- Hidden state: the existence of this state is unknown outside the network element that contains it. Secret stash energy 🙈
- Known state: the existence of this state is known by other network elements.
Stateful Translation: a translation algorithm may be said to "require state in a network element" or be "stateful" if the transmission or reception of a packet creates or modifies a data structure in the relevant network element. Every packet can change the notebook 📓
Stateful Translator: a translator that uses stateful translation for either the source or destination address. A stateful translator typically also uses a stateless translation algorithm for the other type of address.
Stateless Translation: a translation algorithm that is not "stateful" is "stateless". It derives its needed information algorithmically from the messages it is translating and from pre-configured information. No notebook needed, just vibes and config 🦋
Stateless Translator: a translator that uses only stateless translation for both destination address and source address.
Well-Known Prefix (WKP): the IPv6 prefix defined in [RFC6052] for use in an algorithmic mapping. ✨
1.3. Translation Objectives 💜
okay this part is about what we actually want translation to DO, bestie. In any translation model, there is a question of objectives. Ideally, one would like to make any system and any application running on it able to "talk with" -- exchange datagrams supporting applications with -- any other system running the same application regardless of whether they have an IPv4 stack and connectivity or IPv6 stack and connectivity. That was the model for NAT-PT, and the things it necessitated led to scaling and operational difficulties [RFC4966]. So yeah, the dream was big, and the bills were bigger 😭
So the question comes back to what different kinds of connectivity can be easily supported, what kinds are harder, and what technologies are needed to at least pick the low-hanging fruit. We observe that applications today fall into two main categories:
Client/Server Application: Per whatis.com, "'Client/server' describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request." In networking, the behavior of the applications is that connections are initiated from client software and systems to server software and systems. Examples include mail handling between an end user and his mail system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name resolution. Clients knock, servers answer 🚪
Peer-to-Peer (P2P) Application: a P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. These in turn fall broadly into two categories:
- Peer-to-peer infrastructure applications: Examples of "infrastructure applications" include SMTP between MTAs, Network News, and SIP. Any MTA might open an SMTP session with any other at any time; any SIP Proxy might similarly connect with any other SIP Proxy. An important characteristic of these applications is that they use ephemeral sessions -- they open sessions when they are needed and close them when they are done. Open when needed, close when done, zero drama 💅
- Peer-to-peer file exchange applications: Examples of these include Limewire, BitTorrent, and UTorrent. These are applications that open some sessions between systems and leave them open for long periods of time, and where ephemeral sessions are important, these applications are able to learn about the reliability of peers from history or by reputation. They use the long-term sessions to map content availability. Short-term sessions are used to exchange content. They tend to prefer to ask for content from peers that they find reliable and available. The reputation game is STRONG 👑
If the goal is the ability to open connections between systems, then one must ask who opens connections. Real question, honestly 🤔
- We need a technology that will enable systems that act as clients to be able to open sessions with other systems that act as servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Ideally, this is stateless; especially in a carrier infrastructure, the preponderance of accesses will be to servers, and this optimizes access to them. However, a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed. Clients want to reach servers, so servers should be easy to reach 🫶
- We also need a technology that will allow peers to connect with each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Again, it would be ideal if this was stateless, but a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed. Peers need love too 🦋
- In some situations, hosts are purely clients. In those situations, we do not need an algorithm to enable connections to those hosts. Clients who only ask and never answer don't need a doorbell 🔔
The complexity arguments bring us in the direction of hidden state: if state must be shared between the application and the translator or between translation components, complexity and deployment issues are greatly magnified. The objective of the translators is to avoid, as much as possible, any software changes in hosts or applications necessary to support translation. Nobody wants to update every app on earth just to make the translator happy 🙃
NAT-PT is an example of a facility with known state -- at least two software components (the data-plane translator and the DNS Application Layer Gateway, which may be implemented in the same or different systems) share and must coordinate translation state. A typical IPv4/IPv4 NAT implements an algorithm with hidden state. Obviously, stateless translation requires less computational overhead than stateful translation, and less memory to maintain the state, because the translation tables and their associated methods and processes exist in a stateful algorithm and don't exist in a stateless one. Stateless is the lighter, cuter option 🧚💖
1.4. Transition Plan ✨
okay so IPv4 and IPv6 literally can't talk on the wire, because the IPv4 design made that impossible 💀. But the designers planned for them to hang out together during a transition period 🦋. The main way they were supposed to coexist was dual-stack. Routers would be dual-stacked so the network could carry both address families, and IPv6-capable hosts could be dual-stack too so they could keep access to IPv4-only partners 🫶. The dream was that the majority of hosts and routers on the Internet would be IPv6-capable long before IPv4 address space allocation was finished. Sadly, it's looking like IPv4 will run out before IPv6 gets really popular 😭.
Curran's "A Transition Plan" [RFC5211] lays out a three-phase glow-up 💅:
- Preparation Phase (current): characterized by pilot use of IPv6, primarily through transition mechanisms defined in [RFC4213], and planning activities.
- Transition Phase (2010 through 2011): characterized by general availability of IPv6 in provider networks, which should be native IPv6. Organizations should provide IPv6 connectivity for their Internet-facing servers, but should still provide IPv4-based services via a separate service name.
- Post-Transition Phase (2012 and beyond): characterized by a preponderance of IPv6-based services and diminishing support for IPv4-based services.
Various timelines have been discussed, but most people will agree with the pattern of these three transition phases, also known as an "S" curve transition pattern 📈.
In each of these phases, the coexistence problem and solution space have a different focus:
- Preparation Phase: Coexistence tools are needed to help early adopters by removing roadblocks to IPv6 deployment, and to make sure nothing is lost by adopting IPv6. In particular, the IPv6 adopter should have unfettered access to the global IPv4 Internet, regardless of whether they have a global IPv4 address (or any IPv4 address or stack at all) 🎀. While it might seem reasonable for the cost and operational burden to be borne by the early adopter, the shared goal of promoting IPv6 adoption would argue against that model. Additionally, current IPv4 users should not be forced to retire or upgrade their equipment, and the burden remains on service providers to carry and route native IPv4. This is known as the early stage of the "S" curve.
- Transition Phase: During the middle stage of the "S" curve, IPv6 adoption can be expected to accelerate, but there will still be a significant portion of the Internet operating IPv4-only or preferring IPv4 🌸. During this phase, the norm shifts from IPv4 to IPv6, and coexistence tools evolve to ensure interoperability between domains that may be restricted to IPv4 or IPv6.
- Post-Transition Phase: This is the last stage of the "S" curve 👑. In this phase, IPv6 is ubiquitous, and the burden of maintaining interoperability shifts to those who choose to maintain IPv4-only systems. While these systems should be allowed to live out their economic life cycles, the IPv4-only legacy users at the edges should bear the cost of coexistence tools. At some point, service provider networks should not be expected to carry and route native IPv4 traffic.
The choice between the terms "transition" and "coexistence" has caused a lot of long philosophical debate 🙈. "Transition" gives the sense that you're going somewhere, while "coexistence" feels more like you're just sitting somewhere. Historically at the IETF, "transition" has been the term of choice [RFC4213] [RFC5211], and the tools for interoperability have been called "transition mechanisms". There is some perception, or conventional wisdom, that adoption of IPv6 is being held back by a lack of tools to help nodes or networks that are constrained (in some way, fully or partially) from full operation in one of the address families 🧚. Plus, it's pretty obvious that transition will involve a period of coexistence. The only real question is how long that will last.
So coexistence is an integral part of the transition plan, not in conflict with it, but there will be a balancing act ⚖️. It starts out as a way for early IPv6 adopters to easily tap into the bigger IPv4 Internet, and ends up as a way for late or never adopters to hang on to IPv4 (at their own expense, with minimal impact or visibility to the Internet). One way to look at solutions is that cost incentives (both monetary cost and the operational overhead for the end user) should encourage IPv6 and discourage IPv4. That way, natural market forces will keep the transition moving, especially as the legacy IPv4-only stuff ages out of use 🍓. The end goal should not be to eliminate IPv4 by fiat, but rather to render it redundant through ubiquitous IPv6 deployment. IPv4 may never go away completely, but rational plans should move the costs of maintaining IPv4 to those who insist on using it after wide adoption of IPv6. Main character energy for IPv6, honestly 💜.
2. Scenarios for IPv4/IPv6 Translation 🦋
It's important to note that the choice of translation solution, and the assumptions about the network where it's used, will affect the consequences. A translator for the general case has a bunch of issues that a translator for a more specific situation may not have at all 🤓.
The point of this document is to focus on translation solutions for all kinds of situations. Every IPv4/IPv6 translation case can be easily described as "interoperation between a set of systems (applications) that only communicate using IPv4 and a set of systems that only communicate using IPv6". But the differences at a detailed level make them super interesting ✨.
Based on the transition plan described in Section 1.4, there are four types of IPv4/IPv6 translation cases:
- a. Interoperation between an IPv6 network and the IPv4 Internet
- b. Interoperation between an IPv4 network and the IPv6 Internet
- c. Interoperation between an IPv6 network and an IPv4 network
- d. Interoperation between the IPv6 Internet and the IPv4 Internet
Each one of the above can be divided into two scenarios, depending on whether the IPv6 side or the IPv4 side initiates communication, so there are a total of eight scenarios 💖:
- Scenario 1: an IPv6 network to the IPv4 Internet
- Scenario 2: the IPv4 Internet to an IPv6 network
- Scenario 3: the IPv6 Internet to an IPv4 network
- Scenario 4: an IPv4 network to the IPv6 Internet
- Scenario 5: an IPv6 network to an IPv4 network
- Scenario 6: an IPv4 network to an IPv6 network
- Scenario 7: the IPv6 Internet to the IPv4 Internet
- Scenario 8: the IPv4 Internet to the IPv6 Internet
We will discuss each scenario in detail in the next section 🫶.
2.1. Scenario 1: An IPv6 Network to the IPv4 Internet 🌈
Due to the lack of IPv4 addresses, or due to other technical or economic constraints, the network is IPv6-only, but the hosts in the network need to communicate with the global IPv4 Internet 🥺.
This is the typical scenario for what people sometimes call "green-field" deployments 🌱. One example is an enterprise network that wants to operate only IPv6 for operational simplicity, but still wants to reach the content on the IPv4 Internet. The green-field enterprise scenario is different from an ISP's network in the sense that there's only one place the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet keeps operating the way it already does. But the hosts in the enterprise network are commercially available devices, personal computers with existing operating systems, and that restriction drives us toward a "one box" type of solution, where IPv6 gets translated into IPv4 to reach the public Internet 📦.
Other cases that have been mentioned include wireless ISP networks and sensor networks. These bear a striking resemblance to this scenario as well, if you think of the ISP network as just a very special kind of enterprise network 🛰️.
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 1: Scenario 1Both stateless and stateful solutions can support Scenario 1 ✅.
2.2. Scenario 2: The IPv4 Internet to an IPv6 Network 💅
When enterprise networks or ISP networks adopt Scenario 1, the IPv6-only users will not only want to access servers on the IPv4 Internet. They'll also want to set up their own servers in the network that are accessible to users on the IPv4 Internet, since the majority of Internet users are still on the IPv4 Internet 👀. So a translation solution for this scenario would be a clear win. Servers could move directly to IPv6 without trudging through a difficult transition period, and they could do it without risking losing connectivity with the IPv4-only Internet 🙌.
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
Figure 2: Scenario 2In general, this scenario is a hard case for translation 😤. Stateful translation such as NAT-PT [RFC2766] can be used in this scenario, but it requires a tightly coupled DNS Application Level Gateway (ALG) in the translator, and this technique was deprecated by the IETF [RFC4966] 💀.
The stateless translation solution in Scenario 1 can also work in Scenario 2, since it can support IPv4-initiated communications with a subset of the IPv6 addresses (IPv4-translatable addresses) in an IPv6 network 🦋✨.
2.3. Scenario 3: The IPv6 Internet to an IPv4 Network 🌐
okay so this one is about a legacy IPv4 network that needs to offer services to IPv6 hosts 💅
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 3: Scenario 3so stateless translation is a no-go here 🙅♀️ bc the IPv4 network has to talk to ALL of the IPv6 Internet, not just a tiny slice, and stateless can only handle a subset of IPv6 addresses. ngl that's a big deal. BUT IPv6-initiated communication can totally be done with stateful translation ✨ a Network Specific Prefix assigned to the translator gives each host its own unique IPv4-converted IPv6 address, whether the legacy network is using public IPv4 addresses or [RFC1918] addresses. it's giving unique identity no matter what 🦋
also there's no need to synthesize AAAA from A records, because static AAAA records can just live in the regular DNS to represent these IPv4-only hosts, as discussed in Section 7.3 of [RFC6147]. iconic 👑
2.4. Scenario 4: An IPv4 Network to the IPv6 Internet 🥺
so the network is IPv4-only, due to technical or economic constraints, and the IPv4-only hosts (applications) might need to reach the global IPv6 Internet 💀
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
Figure 4: Scenario 4real talk, this one is a hard case for translation 😭 stateful translation like NAT-PT [RFC2766] can be used here, but it needs a tightly coupled DNS ALG in the translator, and the IETF deprecated this technique in [RFC4966]. not the vibe 🙈
and remember the transition phase stuff from Section 1.4? this scenario will probably only pop up when we're well past the early stage of the "S" curve, and the IPv4/IPv6 transition has already moved in the right direction 🌈 so in-network translation isn't considered viable for this one, and other techniques should be looked at instead 🫶
2.5. Scenario 5: An IPv6 Network to an IPv4 Network 🎀
in this one, an IPv4 network and an IPv6 network are both inside the same organization 🏢
the IPv4 addresses are either public IPv4 addresses or [RFC1918] addresses. the IPv6 addresses are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193] 🍓
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 5: Scenario 5the translation requirement here is basically the same as Scenario 1, so both the stateful and stateless translation schemes from Section 2.1 apply here too 🧚
2.6. Scenario 6: An IPv4 Network to an IPv6 Network 💜
this is another one where an IPv4 network and an IPv6 network are both inside the same organization 🏢
again, the IPv4 addresses are either public IPv4 addresses or [RFC1918] addresses, and the IPv6 addresses are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193] 🌸
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
Figure 6: Scenario 6the translation requirement here has no big difference from Scenario 2, so the translation scheme from Section 2.2 applies here ✨
2.7. Scenario 7: The IPv6 Internet to the IPv4 Internet 🌍
this one seems like the ideal case for in-network translation technology 🔥 any IPv6-only host or application on the global Internet can start communicating with any IPv4-only host or application on the global Internet. main character energy 👑
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
Figure 7: Scenario 7but ok, the IPv4 Internet and the IPv6 Internet have a HUGE difference in address space size 😭 so there's no viable translation technique that can handle unlimited IPv6 address translation. that's the tea ☕
if we ever end up in this scenario though, good news: the IPv4/IPv6 transition has already passed the early stage of the "S" curve 🦋 so there's no obvious business reason to demand a translation solution as the only transition strategy 💅
2.8. Scenario 8: The IPv4 Internet to the IPv6 Internet 🌷
this one is very similar to Scenario 7, so the analysis and conclusions for Scenario 7 also apply here 🫶
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
Figure 8: Scenario 83. Framework ✨
okay so now we get to the framework 🧩 we already covered the preferred transition model and the options for implementing it (Section 1.1), defined our terms (Section 1.2), looked at the requirements (Section 1.3), thought about the transition model (Section 1.4), and went through the kinds of scenarios the facility would support (Section 2). so now it's time for a framework for IPv4/IPv6 translation. it contains these components:
- Address translation
- IP and ICMP translation
- Maintaining translation state
- DNS64 and DNS46
- ALGs for other application-layer protocols (e.g., FTP)
3.1. Translation Components 💖
3.1.1. Address Translation ✨
okay so bestie, when we translate between IPv6 and IPv4, we have to nail down how one IPv6 address turns into its matching IPv4 address and back again, at least when an algorithm does the mapping 🧮. That covers which IPv6 prefix gets picked and how the rest of the IPv6 address gets derived from an IPv4 address [RFC6052]. The figures below show how the IPv6 addresses get used 💅
------------
H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4-
(IPv4 ------------ translatable address
address) \
--------------
|Stateless XLAT|
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4-
----------- translatable address)Figure 9: IPv6 Address Representation for Stateless Translation 🦋
------------
H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool
(IPv4 ------------
address) \
--------------
|Stateful XLAT |
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address)
-----------Figure 10: IPv6 Address Representation for Stateful Translation 🌸
okay this part is lowkey important 🫶. For both stateless and stateful translation, an algorithmic mapping table is used to translate IPv6 destination addresses (IPv4-converted addresses) into IPv4 destination addresses in the IPv6-to-IPv4 direction, and to translate IPv4 source addresses into IPv6 source addresses (IPv4-converted addresses) in the IPv4-to-IPv6 direction. Translating IPv6 source addresses into IPv4 source addresses in the IPv6-to-IPv4 direction, and translating IPv4 destination addresses into IPv6 destination addresses in the IPv4-to-IPv6 direction, is NOT the same thing for stateless and stateful translation. Watch out for that one 👀
- Stateless translation: the same algorithmic mapping table is used to translate IPv6 source addresses (IPv4-translatable addresses) into IPv4 source addresses in the IPv6-to-IPv4 direction, and to translate IPv4 destination addresses into IPv6 destination addresses (IPv4-translatable addresses) in the IPv4-to-IPv6 direction. Here, blocks of the service provider's IPv4 addresses get mapped into IPv6 and used by physical IPv6 nodes. The original IPv4 form of those blocks of the service provider's IPv4 addresses is used to represent the physical IPv6 nodes in IPv4. Stateless translation supports both IPv6-initiated and IPv4-initiated communications, so it's giving flexibility 🧚
- Stateful translation: the algorithmic mapping table is NOT used to translate source addresses in the IPv6-to-IPv4 direction or destination addresses in the IPv4-to-IPv6 direction. Instead, a state table handles translating IPv6 source addresses into IPv4 source addresses in the IPv6-to-IPv4 direction, and translating IPv4 destination addresses into IPv6 destination addresses in the IPv4-to-IPv6 direction. In this case, blocks of the service provider's IPv4 addresses are kept in the translator as IPv4 address pools and get dynamically bound to specific IPv6 addresses. The original IPv4 form of those blocks is used to represent the IPv6 address in IPv4. But because of that dynamic binding, stateful translation in general only supports IPv6-initiated communication 💀
3.1.2. IP and ICMP Translation 🧃
The IPv4/IPv6 translator is based on the update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in [RFC2765]. The algorithm translates between IPv4 and IPv6 packet headers, including ICMP headers, so it's doing a lot of heavy lifting 💪
The IP and ICMP translation document [RFC6145] talks about header translation for both stateless and stateful modes, but it doesn't cover maintaining state in the stateful mode, which is a whole other vibe 🙈. In the stateless mode, translation is done using a combo of information carried in the address and information configured in the translator. This permits both IPv4->IPv6 and IPv6->IPv4 session establishment ✨. In the stateful mode, translation state gets maintained between IPv4 address/transport port tuples and IPv6 address/transport port tuples, which enables IPv6 systems to open sessions with IPv4 systems 🌈. The operator deploying the network picks the operational mode, and that choice is critical to how the applications using it operate. No pressure lol 😭
3.1.3. Maintaining Translation State 🎀
For the stateful translator, besides IP and ICMP translation, special action must be taken to maintain the translation states. [RFC6146] describes a mechanism for maintaining state, so go check that one out 🔍
3.1.4. DNS64 and DNS46 💜
DNS64 [RFC6147] and possible future DNS46 documents describe the mechanisms a DNS translator is intended to operate with. It's designed to work on the basis of known address translation algorithms defined in [RFC6052] 🧠
There are at least two possible implementations of a DNS64 and DNS46:
- Static records: one could literally populate DNS with corresponding A and AAAA records. This mechanism works for scenarios 2, 3, 5, and 6 🍓
- Dynamic Translation of static records: in more general operation, the preferred behavior is for an A record to be (retrieved and) translated to a AAAA record by the DNS64 if and only if no reachable AAAA record exists, or for a AAAA record to be (retrieved and) translated to an A record by the DNS46 if and only if no reachable A record exists 🔥
3.1.5. ALGs for Other Applications Layer Protocols 🌟
Some applications need special support too, which is so relatable 🙃. FTP is the classic example. FTP's active mode doesn't work well across NATs without extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it generally uses passive mode. The problem is that the designers of FTP wrote different and incompatible passive-mode implementations for IPv4 and IPv6 networks 😤. So either FTP needs fixing, or a translator has to be written for the application. Other applications may be similarly broken 💀
Here's the thing though: a simple operational recommendation works around a lot of these application issues. There should be a server in each domain, or an instance of the server should have an interface in each domain 🫶. For example, an SMTP MTA may get confused by finding an IPv6 address in its HELO when it's connected to using IPv4 (or vice versa). But it would work perfectly well if it had an interface in both the IPv4 and IPv6 domains and was used as an application-layer bridge between them 🌉
3.2. Operation Mode for Specific Scenarios 🦋
Right now, the proposed solutions for IPv6/IPv4 translation are classified into stateless translation and stateful translation 📋
3.2.1. Stateless Translation 🌷
For stateless translation, the translation information is carried in the address itself plus configuration in the translators. This permits both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless translation supports end-to-end address transparency and has better scalability compared with stateful translation [RFC6145] 🚀
The stateless translation mechanisms typically put constraints on what IPv6 addresses can be assigned to IPv6 nodes that want to communicate with IPv4 destinations using an algorithmic mapping. For Scenario 1 ("an IPv6 network to the IPv4 Internet"), that's not a serious drawback, since the address assignment policy can be applied to satisfy this requirement for the IPv6 nodes that need to communicate with the IPv4 Internet 🙌. Stateless translation also supports Scenario 2 ("the IPv4 Internet to an IPv6 network"). That means servers could move directly to IPv6 without trudging through a difficult transition period, and they could do it without risk of losing connectivity with the IPv4-only Internet. Main character energy, honestly 👑
Stateless translation can be used for Scenarios 1, 2, 5, and 6, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv4 Internet to an IPv6 network", "an IPv6 network to an IPv4 network", and "an IPv4 network to an IPv6 network" 💖
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>Figure 11: Stateless Translation for Scenarios 1 and 2 🧚
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>Figure 12: Stateless Translation for Scenarios 5 and 6 ✨
The implementation of the stateless translator needs to refer to [RFC6145] and [RFC6052] 📚
3.2.2. Stateful Translation ✨
okay so stateful translation is giving memory 🧠✨ The translator keeps track of the state between IPv4 address/port pairs and IPv6 address/port pairs, and that's what lets IPv6 systems open sessions with IPv4 systems [RFC6145] [RFC6146] 💖
Stateful translation works for Scenarios 1, 3, and 5, aka "an IPv6 network to the IPv4 Internet", "the IPv6 Internet to an IPv4 network", and "an IPv6 network to an IPv4 network" 🌸
For Scenario 1, any IPv6 addresses in an IPv6 network can use stateful translation 🦋 It typically only supports initiation from the IPv6 side though, so it's not giving bidirectional energy. It also doesn't result in stable IPv6 node addresses that can go in DNS, which can cause problems for protocols and apps that don't handle super dynamic addresses well 😭
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 13: Stateful Translation for Scenario 1Scenario 3 is for servers using IPv4 private addresses [RFC1918] that are being reached from the IPv6 Internet 🧚 This includes servers that for some reason can't be upgraded to IPv6 and don't have public IPv4 addresses, but still need to be reached by IPv6 nodes on the IPv6 Internet 🥹
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 14: Stateful Translation for Scenario 3Stateful translation can also be used for Scenario 5, no cap 🎀
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 15: Stateful Translation for Scenario 5The implementation of the stateful translator needs to refer to [RFC6145], [RFC6146], and [RFC6052] 📚💅
3.3. Layout of the Related Documents
okay so based on everything above, the IPv4/IPv6 translation series is made up of these documents 🌈
- Framework for IPv4/IPv6 Translation (this document).
- Address translation (the choice of IPv6 prefix and the choice of method by which the remainder of the IPv6 address is derived from an IPv4 address, part of the SIIT update) [RFC6052].
- IP and ICMP Translation (header translation and ICMP handling, part of the SIIT update) [RFC6145].
- Table maintenance (stateful translation including session database and mapping table handling) [RFC6146].
- DNS64 (DNS64: A to AAAA mapping and DNSSEC discussion) [RFC6147].
- FTP ALG [FTP64].
- Others (DNS46, Multicast, etc.).
Here's how they all relate to each other 👑
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
Figure 16: Document LayoutIn the document layout, IP/ICMP Translation and DNS64/DNS46 normatively refer to Address Translation. Table Maintenance and IP/ICMP Translation normatively refer to each other 🫶
The FTP ALG and other documents normatively refer to the Address Format, IP/ICMP Translation, and Table Maintenance documents 💜
4. Translation in Operation 🍓
Operationally, there are two ways translation could be used. One is as a permanent solution, which makes transition "the other guy's problem" 🙈 The other is as a temporary solution for a new part of your network while you bring up IPv6 services in the remaining parts of it. We obviously recommend the latter at the present stage 💅 For the IPv4 parts of the network, [RFC4213]'s recommendation holds. Bring IPv6 up in those domains, move production to it, and then take down the now-unnecessary IPv4 service when economics warrant it. This approach to transition entails the least risk 🦋
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\----+----+-+-----+ +----+-/////
|XLAT|-|DNS64|-|FTP |
| |-|DNS46|-|ALG |
/////----+----+ +-----+ +----+-\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
Figure 17: Translation Operational ModelFigure 17 shows that during the coexistence phase, you can expect a mix of hosts, applications, and networks 🌈 Hosts might include IPv6-only gaming devices and handsets, older computer operating systems that are IPv4-only, and modern mainline operating systems that support both. Applications might include ones that are IPv4-only and modern applications that support both IPv4 and IPv6. Networks might include dual-stack devices operating in single-stack networks (whether that stack is IPv4 or IPv6) and fully functional dual-stack networks ✨
5. Unsolved Problems 🔮
The framework doesn't cover every possible scenario, but it may be extended in the future to address them 🧚
6. Security Considerations 🚨
This document is the framework of IPv4/IPv6 translation. The security issues are addressed in individual IPv4/IPv6 translation documents, i.e., [RFC6052], [RFC6145], [RFC6146], [RFC6147], and [FTP64]. Go read those, bestie, they're not optional 😭🔐
7. Acknowledgements 🫶
This is under development by a large group of people. Those who have posted to the list during the discussion include Andrew Sullivan, Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, and Remi Despres 🌸
Ed Jankiewicz described the transition plan 👑
8. References 📖
8.1. Normative References
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.8.2. Informative References 📚✨
Okay bestie, these are the informative refs, so they're here for background and aren't required reading to implement the spec 🤓
- [6NET] 6NET Consortium, "6NET", <http://www.6net.org/>.
- [DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, March 2011.
- [FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
- [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
- [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
- [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
- [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
- [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
- [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
- [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
- [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
- [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
- [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
Authors' Addresses 🫶
Meet the squad who made this happen 💖 Here are their contact details, exactly as they're written in the RFC:
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.comXing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
EMail: xing@cernet.edu.cnCongxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cnKevin Yin
Cisco Systems
No. 2 Jianguomenwai Ave, Chaoyang District
Beijing, 100022
China
Phone: +86-10-8515-5094
EMail: kyin@cisco.com📦 where this page comes from
- ietf: rfc6144 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms