RFC 2767
Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
RFC 2767: Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) 💖
Network Working Group 🌸 this one is from February 2000 and it's labelled Informational ✨, so it's sharing info, not setting a standard. The authors are K. Tsuchiya, H. Higuchi and Y. Atarashi, all from Hitachi 🧚. The title block doesn't list anything it obsoletes or updates, so there's nothing to track there 💅.
Status of This Memo 📋
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🦋.
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract 🌈
Okay so in the super early days of moving from IPv4 to IPv6, it's really hard to have a full set of IPv6 apps 😭. This memo proposes a dual stack host setup using a technique called "Bump-in-the-Stack" from the IP security area 🔐. The big payoff is that these hosts can talk to other IPv6 hosts while still running the IPv4 apps they already have ✨.
1. Introduction 🎀
So RFC1933 [TRANS-MECH] is the one that lays out transition mechanisms for that early stage, like dual stack and tunneling 🫶. Hosts and routers that use those mechanisms have been built too. The problem is there are very few IPv6 [IPV6] apps compared to the huge pile of IPv4 [IPV4] apps 😩. To move the transition along smoothly, it's really important that IPv6 apps catch up to the same level as IPv4. Sadly, that's expected to take a very long time 💀.
This memo proposes a dual stack host setup using a technique called "Bump-in-the-Stack" [BUMP] from the IP security area ✨. The technique drops modules into the host. These modules snoop on data moving between the TCP/IPv4 module and the network card driver modules, and they translate IPv4 into IPv6 and back again 🔁. That makes the host a self-translator 🧚. When it talks to other IPv6 hosts, it hands out pooled IPv4 addresses to those IPv6 hosts internally, but the IPv4 addresses never leave the host 🙈. The assignment happens automatically through DNS protocol, so users don't have to know whether a target host is IPv6 🥹. So they can talk to IPv6 hosts with their existing IPv4 apps, and it honestly looks like they're a dual stack host with apps for both IPv4 and IPv6 👑. That means they can expand the territory of dual stack hosts. Also, they can co-exist with other translators, because their roles are different 🌸.
This memo uses the words defined in [IPV4], [IPV6], and [TRANS-MECH] 📚.
2. Components 🧩
Dual stack hosts defined in RFC1933 [TRANS-MECH] need apps, TCP/IP modules, and addresses for both IPv4 and IPv6 💖. The hosts proposed in this memo have 3 modules in place of IPv6 apps, and they talk to other IPv6 hosts using IPv4 apps 🦋. Those 3 modules are a translator, an extension name resolver, and an address mapper 🍓.
Figure 1 shows what the host looks like with them installed 👀:
+----------------------------------------------------------+
| +----------------------------------------------------+ |
| | IPv4 applications | |
| +----------------------------------------------------+ |
| +----------------------------------------------------+ |
| | TCP/IPv4 | |
| | +-------------------------------------------+ |
| | | +-----------+ +---------+ +------------+ |
| | | | extension | | address | | translator | |
| | | | name | | mapper | +------------+ |
| | | | resolver | | | +------------+ |
| | | | | | | | IPv6 | |
| +--------+ +-----------+ +---------+ +------------+ |
| +----------------------------------------------------+ |
| | Network card drivers | |
| +----------------------------------------------------+ |
+----------------------------------------------------------+
+----------------------------------------------------------+
| Network cards |
+----------------------------------------------------------+
Figure. 1 Structure of the proposed dual stack host2.1 Translator 🔄
It translates IPv4 into IPv6 and back, using the IP conversion mechanism defined in [SIIT] ✨.
When it gets IPv4 packets from IPv4 apps, it converts the IPv4 packet headers into IPv6 packet headers. Then it fragments the IPv6 packets, because IPv6 header length is typically 20 bytes bigger than IPv4's 📦, and sends them out to IPv6 networks. When it gets IPv6 packets from IPv6 networks, it does the same thing in reverse, except there's no need to fragment anything 🫧.
2.2 Extension Name Resolver 🔍
Its job is to return a "proper" answer when an IPv4 app asks for something 💅.
Normally the app sends a query to a name server to resolve 'A' records for the target host name. The resolver snoops that query, then makes its own query to resolve both 'A' and 'AAAA' records for the host name, and sends that to the server 🕵️♀️. If the 'A' record resolves, it hands the 'A' record back to the app as is. In that case, the translator doesn't need to do any IP conversion 🙌. If only the 'AAAA' record is available, the resolver asks the mapper to assign an IPv4 address that matches the IPv6 address. Then it creates an 'A' record for that assigned IPv4 address and returns it to the app 🎀.
NOTE: This action is similar to that of the DNS ALG (Application Layer Gateway) used in [NAT-PT]. See also [NAT-PT]. 👀
2.3 Address mapper 🗺️
It keeps an IPv4 address spool. For example, the spool can be made up of private addresses [PRIVATE] 🏠. It also keeps a table of pairs, each one an IPv4 address matched with an IPv6 address 💜.
When the resolver or the translator asks it to assign an IPv4 address for an IPv6 address, it picks one out of the spool and returns it. It also adds a new entry to the table dynamically ✨. A new registration happens in these 2 cases:
- (1) When the resolver gets only an 'AAAA' record for the target host name, and there's no mapping entry for the IPv6 address.
- (2) When the translator receives an IPv6 packet, and there's no mapping entry for the IPv6 source address.
NOTE: There is only one exception. When initializing the table, it registers a pair of its own IPv4 address and IPv6 address into the table statically. 🧐
3. Action Examples 🎬
This section walks through what the proposed dual stack host does. It's called "dual stack," and it talks to an IPv6 host called "host6" using an IPv4 app 🧚♀️✨.
3.1. Originator behavior 💖
okay so this subsection is the originator side of "dual stack" 💅 and the whole thing gets kicked off by "dual stack" itself 🦋
the app starts by asking its name server for the 'A' records for "host6." 🌸
then the resolver snoops that query 👀 and makes its own second query for both 'A' and 'AAAA' records for the same host name, and sends that one to the server. ✨ only the 'AAAA' record comes back though, so the resolver asks the mapper to assign an IPv4 address that matches the IPv6 address. 🧚
NOTE: When the host is talking to an IPv4 host, the 'A' record is resolved and the resolver just hands it back to the application as is. 🙈 No IP conversion needed in that case. It shows up later.
the mapper picks an IPv4 address out of the spool and sends it back to the resolver. 🍓
the resolver then makes an 'A' record for that assigned IPv4 address and returns it to the application. 💜
NOTE: Check Section 4.3 for how an IPv4 address assigned here can affect other hosts. 👀
next the application sends an IPv4 packet to "host6." 🚀
the IPv4 packet lands at the translator. the translator tries to turn it into an IPv6 packet, but it doesn't know how to translate the IPv4 destination address or the IPv4 source address 😭 so it asks the mapper for mapping entries for both.
the mapper checks its mapping table, finds an entry for each one, and sends back the IPv6 destination address and the IPv6 source address to the translator. ✨
NOTE: The mapper registers its own IPv4 address and IPv6 address into the table ahead of time. See subsection 2.3. 💅
the translator turns the IPv4 packet into an IPv6 packet, fragments the IPv6 packet if it needs to, and sends it out to an IPv6 network. 🌈
the IPv6 packet reaches "host6." then "host6" sends a brand new IPv6 packet back to "dual stack." 🫶
that IPv6 packet reaches the translator in "dual stack." the translator grabs the mapping entries for the IPv6 destination address and the IPv6 source address from the mapper, same way as before. 🔥
then it translates the IPv6 packet into an IPv4 packet and passes it up to the application. 🎀
here's the diagram for all of that, bestie 🦋
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Resolve an IPv4 address for "host6".>> | |
| | | | | | |
|------|------>| Query of 'A' records for "host6". | Name
| | | | | | | Server
| | |---------|-------|-----------|---------|--->|
| | | Query of 'A' records and 'AAAA' for "host6"
| | | | | | | |
| | |<--------|-------|-----------|---------|----|
| | | Reply only with 'AAAA' record. |
| | | | | | |
| | |<<Only 'AAAA' record is resolved.>> |
| | | | | | |
| | |-------->| Request one IPv4 address |
| | | | corresponding to the IPv6 address.
| | | | | | |
| | | |<<Assign one IPv4 address.>> |
| | | | | | |
| | |<--------| Reply with the IPv4 address.
| | | | | | |
| | |<<Create 'A' record for the IPv4 address.>>
| | | | | | |
|<-----|-------| Reply with the 'A' record. | |
| | | | | | |Figure 2 Action of the originator (1/2)
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Send an IPv4 packet to "host6".>>| | |
| | | | | | |
|======|=======|=========|======>| An IPv4 packet. |
| | | | | | |
| | | |<------| Request IPv6 addresses
| | | | | corresponding to the IPv4
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv6|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| | |An IPv6 packet. |===========|========>|
| | | | | | |
| | | | <<Reply an IPv6 packet to
| | | | "dual stack".>> |
| | | | | | |
| | |An IPv6 packet. |<==========|=========|
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | |Figure 2 Action of the originator (2/2)
3.2. Recipient behavior 🌸
this one is the recipient side of "dual stack" 🧚 and this time "host6" is the one that starts the conversation 💅
"host6" looks up the 'AAAA' record for "dual stack" through its name server, then sends an IPv6 packet to that IPv6 address. 🦋
the IPv6 packet lands at the translator in "dual stack." ✨
the translator tries to turn the IPv6 packet into an IPv4 packet, but it doesn't know how to translate the IPv6 destination address or the IPv6 source address 🙈 so it asks the mapper for mapping entries for both.
the mapper checks its table against each of them. it finds a mapping entry for the IPv6 destination address, but there's no entry for the IPv6 source address. 😭 so the mapper picks an IPv4 address out of the spool for that one, then sends back the IPv4 destination address and the IPv4 source address to the translator. 💜
NOTE: The mapper registers its own IPv4 address and IPv6 address into the table ahead of time. See subsection 2.3. 💅
NOTE: Check Section 4.3 for how an IPv4 address assigned here can affect other hosts. 👀
the translator turns the IPv6 packet into an IPv4 packet and passes it up to the application. 🎀
the application sends a brand new IPv4 packet to "host6." 🚀
everything after that is the same as what we covered in subsection 3.1. 🫶
here's the diagram for the whole recipient thing, bestie 🌈
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Receive data from "host6".>> | | |
| | | | | | |
| | |An IPv6 packet. |<==========|=========|
| | | | | | |
| | | |<------| Request IPv4 addresses
| | | | | corresponding to the IPv6
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv4|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | |
<<Reply an IPv4 packet to "host6".>> | |
| | | | | | |
|======|=======|=========|======>| An IPv4 packet. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| | |An IPv6 packet. |===========|========>|
| | | | | | |Figure 3 Action of the recipient
4. Considerations ✨
this section thinks through some of the issues with the proposed dual stack hosts 🧐
4.1. IP conversion 🔥
okay so NAT [NAT] has the same problem here 😭 IP conversion has to translate IP addresses that are embedded inside application layer protocols. FTP [FTP] is the classic example. which means it's really hard to translate every single one of those applications completely 💀
4.2. IPv4 address spool and mapping table 🌸
the spool is made of private addresses [PRIVATE], so there's a pretty big address space to work with 🦋 but here's the catch: if the host talks to a huge number of other IPv6 hosts, and the mapper never frees the entries it registered into the mapping table, the IPv4 addresses in the spool will run out 😱 and then they can't be assigned to IPv6 target hosts anymore.
to fix it, the suggestion is for the mapper to free the oldest entry in the mapping table and reuse that IPv4 address for a new entry. 💜
4.3. Internally assigned IPv4 addresses 🧚
IPv4 addresses that get assigned internally to IPv6 target hosts out of the spool never leave the host 🙌 so they don't negatively affect other hosts. ✨
5. Applicability and Limitations 🦋
this section looks at where the proposed dual stack hosts make sense and where they fall short 💅
5.1. Applicability 🌈
this mechanism can be really useful, especially in the early stage where some applications haven't been moved over to IPv6 yet 🥹 it also helps users who can't upgrade certain applications for some reason, even after everything else has been modified. 🫶 why? because it lets hosts talk to IPv6 hosts using existing IPv4 applications, and they get connectivity for both IPv4 and IPv6 even without any IPv6 applications at all. 🎀
NOTE: It can also work alongside a complete IPv6 stack. 💖 With it, a host can talk to both IPv4 hosts and IPv6 hosts using IPv4 applications, and it can also talk to IPv6 hosts using IPv6 applications through the complete IPv6 stack. 👑
5.2. Limitations 🚧
Okay bestie, the big catch is that this only works for unicast 💌, meaning one sender to one receiver. It's totally invalid for multicast, so multicast needs a different mechanism 🫶.
It lets hosts talk to IPv6 hosts using the IPv4 apps they already have 📱, but it can't handle IPv4 applications that use any IPv4 option, because options can't be translated into IPv6 😭. It's also impossible to translate IPv6 option headers into IPv4, except for fragment headers and routing headers 🙈. So inbound IPv6 traffic that has option headers may get rejected 💀.
Next, IP conversion has to translate IP addresses that are embedded inside application layer protocols, like in FTP [FTP], which is the same problem NAT [NAT] runs into 🌀. That means it's really hard to translate all of those applications completely 💅.
Hosts using this mechanism may not be able to use security above the network layer, since the data itself may carry IP addresses 🔐.
And finally, it can't be combined with secure DNS, because the extension name resolver can't handle that protocol 🙅♀️.
6. Security Considerations 🔐✨
Okay, this part is important, so listen up 👂. We're looking at the security of the proposed dual stack hosts 🖥️.
When hosts talk to IPv4 hosts using IPv4 applications through this mechanism, they get to use security at all layers, just like ordinary IPv4 communication 🛡️. Same vibe when they talk to IPv6 hosts using IPv6 applications over the complete IPv6 stack, they get full layered security, just like ordinary IPv6 🌈.
BUT, and this is a big but 😭, when they talk to IPv6 hosts using IPv4 applications through the mechanism, they can't use security above the network layer. The reason is that if the protocol data that carries IP addresses is encrypted, or if the data is encrypted using IP addresses as keys, the mechanism just can't translate the IPv4 data into IPv6 and back again 💔.
So, bestie, it's highly desirable to upgrade to applications that have been modified for IPv6 if you want security when talking to IPv6 hosts 🔥🫶.
7. References 📚
- [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
- [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
- [NAT] Kjeld B. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
- [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
- [BUMP] D.A. Wagner and S.M. Bellovin, "A Bump in the Stack Encryptor for MS-DOS Systems", The 1996 Symposium on Network and Distributed Systems Security (SNDSS'96) Proceedings.
- [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
8. Acknowledgements 🫶
The authors give a huge shoutout 📣 to the many helpful suggestions from the members of the WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO, at large 🌸.
9. Authors' Addresses 💌
Meet the authors 🎀:
Kazuaki TSUCHIYA
Enterprise Server Division, Hitachi, Ltd.
810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN
Phone: +81-462-32-2121
Fax: +81-462-35-8324
EMail: tsuchi@ebina.hitachi.co.jpHidemitsu HIGUCHI
Enterprise Server Division, Hitachi, Ltd.
810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN
Phone: +81-462-32-2121
Fax: +81-462-35-8324
EMail: h-higuti@ebina.hitachi.co.jpYoshifumi ATARASHI
Enterprise Server Division, Hitachi, Ltd.
810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN
Phone: +81-462-32-2121
Fax: +81-462-35-8324
EMail: atarashi@ebina.hitachi.co.jp10. Full Copyright Statement ⚖️
The legal bit comes verbatim, because it has to stay complete 🙏:
Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society 🌈✨
📦 where this page comes from
- ietf: rfc2767 2000-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms