RFC 6535
Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
Part 1 of 5 🎀
Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) 💖
Okay bestie, the title block first 💅 This one is an IETF doc (Internet Engineering Task Force) and it's a Standards Track document, so it's the real deal ✨. It was written by B. Huang, H. Deng (both from China Mobile) and T. Savolainen (from Nokia). It's dated February 2012, ISSN is 2070-1721, and it obsoletes RFC 2767 and RFC 3338 🙈 (we'll get to why in Section 7). The title block doesn't list anything it updates.
Abstract
okay so BIH is a host-based IPv4 to IPv6 protocol translation mechanism 🦋 It lets a group of IPv4-only apps that work through NATs talk to IPv6-only peers. The host running those apps can be on an IPv6-only network or a dual-stack one, and it doesn't matter which. BIH hides the IPv6 stuff and makes the IPv4-only apps think they're chatting with IPv4 peers, using IPv4 addresses that it synthesizes locally 💜 This document obsoletes RFC 2767 and RFC 3338 ✨.
Status of This Memo
This is an Internet Standards Track document. ✨
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc6535 🌸
Copyright Notice
Copyright (c) 2012 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 in effect on the date this document was published. Please read these carefully, because they spell out 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 🫶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅
Table of Contents ✨
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Acknowledgment of Previous Work ............................5
2. Components of the Bump-in-the-Host ..............................6
2.1. Function Mapper ............................................8
2.2. Protocol Translator ........................................8
2.3. Extension Name Resolver ....................................8
2.3.1. Special Exclusion Sets for A and AAAA Records .......9
2.3.2. DNSSEC Support .....................................10
2.3.3. Reverse DNS Lookup .................................10
2.3.4. DNS Caches and Synthetic IPv4 Addresses ............10
2.4. Address Mapper ............................................11
3. Behavior and Network Examples ..................................11
4. Considerations .................................................15
4.1. Socket API Conversion .....................................15
4.2. Socket Bindings ...........................................15
4.3. ICMP Message Handling .....................................15
4.4. IPv4 Address Pool and Mapping Table .......................15
4.5. Multi-Interface ...........................................17
4.6. Multicast .................................................17
5. Application-Level Gateway Requirements Considerations ..........17
6. Security Considerations ........................................17
6.1. Implications on End-to-End Security .......................18
6.2. Filtering .................................................18
6.3. Attacks on BIH ............................................18
6.4. DNS Considerations ........................................19
7. Changes since RFC 2767 and RFC 3338 ............................19
8. Acknowledgments ................................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................21
Appendix A. API List Intercepted by BIH ...........................231. Introduction ✨
This doc describes Bump-in-the-Host (BIH), which is a successor to and a combo of two older techniques: Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-API (BIA) [RFC3338] 🦋 Together they let IPv4-only legacy apps talk to IPv6-only servers by synthesizing IPv4 addresses from AAAA records. Section 7 explains why RFC 2767 and RFC 3338 are being made obsolete.
The supported class of apps includes the ones that use DNS for IP address resolution and that don't embed IP address literals in their application-protocol payloads. That covers legacy client-server apps that use DNS, don't care which IP address family the destination uses, and can do NAT traversal. The synthetic IPv4 addresses that apps see come from the private address pool of [RFC1918], so that possible NAT traversal techniques will get kicked off 💜
The IETF recommends dual stack or tunneling for IPv6 transition, and it specifically recommends against deployments that use double protocol translation. Using BIH together with a NAT64 is NOT RECOMMENDED [RFC6180] 🙈
BIH has two main implementation options: a protocol translator between the IPv4 and IPv6 stacks of a host, or an API translator between the IPv4 socket API module and the TCP/IP module. Basically, IPv4 gets translated into IPv6 either at the socket API layer or at the IP layer, and the socket API layer is the recommended one 👑
When BIH is implemented at the socket API layer, the translator intercepts IPv4 socket API function calls and invokes the matching IPv6 socket API function calls to talk to IPv6 hosts 💅
When BIH is implemented at the network layer, the IPv4 packets get intercepted and converted to IPv6 using the IP conversion mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. The protocol translation has the same benefits and drawbacks as SIIT ✨
The location of BIH refers to where the protocol translation function lives. Where the IPv4 address and DNS A record synthesis function lives is orthogonal to that, so it may or may not happen at the same location 🌈
BIH can be used whenever an IPv4-only app needs to talk to an IPv6-only server, no matter which address families the access network supports. So the access network can be IPv6-only or dual-stack capable 🫶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yes, these are the official BCP 14 words, so they're the only ones with that special meaning 🧚
This document uses terms defined in [RFC2460] and [RFC4213] 📚
1.1. Terminology
DNS synthesis
The process of creating an A record containing a synthetic IPv4 address. ✨
Real IPv4 address
An IPv4 address of a remote node that a host has learned, for example, from a DNS response to an A query. 💜
Real IPv6 address
An IPv6 address of a remote node that a host has learned, for example, from a DNS response to a AAAA query. 🦋
Synthetic IPv4 address
An IPv4 address that only has meaning inside a host, and that is used to provide an IPv4 representation of a remote node's real IPv6 address 🧚
1.2. Acknowledgment of Previous Work
This document is a direct derivative of [RFC2767], "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)" by Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI, and of [RFC3338], "Dual Stack Hosts Using "Bump-in-the-API" (BIA)" by Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark. Those two docs do a similar job: they give IPv4-only apps on dual-stack hosts a way to run over IPv6 🌸 Section 7 covers what changed since then 💖
2. Components of the Bump-in-the-Host ✨
Okay so, let's talk about the anatomy of BIH 💅 Figure 1 shows a host where BIH lives at the socket API layer, which is called the "Bump-in-the-API" 🦋
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv4 applications | |
| | | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | Socket API (IPv4, IPv6) | |
| +------------------------------------------+ |
| +-[ API translator]------------------------+ |
| | +-----------+ +---------+ +------------+ | |
| | | Ext. Name | | Address | | Function | | |
| | | Resolver | | Mapper | | Mapper | | |
| | +-----------+ +---------+ +------------+ | |
| +------------------------------------------+ |
| +--------------------+ +-------------------+ |
| | | | | |
| | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | |
| | | | | |
| +--------------------+ +-------------------+ |
+----------------------------------------------+
Figure 1: Architecture of a dual-stack host using protocol
translation at the socket layerFigure 2 is the other flavour: BIH lives at the network layer, which is the "Bump-in-the-Stack" 🧚
+------------------------------------------------------------+
| +------------------------------------------+ |
| | IPv4 applications | |
| | Host's main DNS resolver | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | TCP/UDP | |
| +------------------------------------------+ |
| +------------------------------------------+ +---------+ |
| | IPv4 | | | |
| +------------------------------------------+ | Address | |
| +------------------+ +---------------------+ | Mapper | |
| | Protocol | | Extension Name | | | |
| | Translator | | Resolver | | | |
| +------------------+ +---------------------+ | | |
| +------------------------------------------+ | | |
| | IPv4 / IPv6 | | | |
| +------------------------------------------+ +---------+ |
+------------------------------------------------------------+
Figure 2: Architecture of a dual-stack host using protocol
translation at the network layerDual-stack hosts, as defined in [RFC4213], need applications, TCP/IP modules, and addresses for both IPv4 and IPv6. The hosts proposed in this document get an API or network-layer translator so that legacy IPv4 applications can still talk to IPv6-only peers. The BIH architecture is made of an Extension Name Resolver, an address mapper, and, depending on the implementation, either a function mapper or a protocol translator. Also, the Extension Name Resolver's placement is orthogonal to where protocol translation happens 🎀 For example, the Extension Name Resolver may live in the socket API while protocol translation takes place at the network layer.
Choosing between the socket API and network-layer architectures is a case-by-case thing 🌸 The socket API alternative is the recommended one, but it's not always possible to pick it. For example, the operating system might not allow changes to API implementations, while still letting you add virtual network interfaces and related software modules. On the flip side, it might not be possible to put protocol translators inside the operating system, but it could be easy to modify the implementation behind the API that applications see. The architecture choice also depends on who is building the BIH implementation. An application framework provider, an operating system provider, and a device vendor may all pick different approaches because they're in different positions 💜
2.1. Function Mapper
The function mapper translates an IPv4 socket API function into an IPv6 socket API function. It's giving interception vibes 🙈
When it detects IPv4 socket API function calls from IPv4 applications, the function mapper MUST intercept those calls and invoke the IPv6 socket API functions that correspond to the IPv4 ones.
The function mapper MUST NOT perform function mapping when the application is starting communications to the address range used by local synthesis and the address mapping table has no entry matching that address. Not me doing the wrong mapping 🙅♀️
See Appendix A for an informational list of the functions that would be appropriate for the function mapper to intercept ✨
2.2. Protocol Translator
The protocol translator converts IPv4 into IPv6, and IPv6 back into IPv4, using the IP conversion mechanism defined in SIIT [RFC6145]. To avoid unnecessary fragmentation, the host's IPv4 module SHOULD be configured with a small enough MTU, set to MTU of the IPv6 enabled link - 20 bytes 🦋
Protocol translation can't happen for IPv4 packets sent to the IPv4 address range used by local synthesis when no mapping table entry exists for them. In that case, the implementation SHOULD attempt to route such packets via IPv4 interfaces instead 🧚
2.3. Extension Name Resolver
The Extension Name Resolver (ENR) returns an answer in response to the IPv4 application's name resolution request. This is the main character of the name lookup 👑
In the socket API-layer implementation, when an IPv4 application tries a forward lookup through the resolver library (for example, gethostbyname()), BIH intercepts that call and instead calls the IPv6 equivalents (for example, getaddrinfo()), which resolve both A and AAAA records. This alternative doesn't care which name resolution protocol is used, so it works with things like "hosts-file", NetBIOS, mDNS, and anything else the underlying operating system uses 🌈
In the network-layer implementation, the ENR intercepts the A query and creates an additional AAAA query with similar content. The ENR then collects the replies to both the A and AAAA queries and, depending on the results, either returns an A reply unmodified or synthesizes a new A reply. If no reply for the A query arrives within the ENR-implementation-specific timeout, and a positive AAAA response has been received, the ENR MAY choose to proceed as if only a AAAA record were available for the destination. 🫶
The network-layer alternative can only catch name resolution requests that turn into actual DNS queries, so it's more limited than the socket API-layer alternative. Hence, the socket API-layer alternative is RECOMMENDED. Honestly, it's the move 💅
In either implementation, if a DNS A record reply contains non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresses. Real addresses that aren't excluded win, no cap 🔥
The ENR asks the address mapper to assign a synthetic IPv4 address for each received IPv6 address when any of these happen: the A record query got a negative response, all the received real IPv4 addresses were excluded, or the A query timed out. The timeout value is implementation specific, and it may be short so the user experience feels good ✨
In the socket API-layer implementation, the ENR simply makes the API (for example, gethostbyname) return the synthetic IPv4 address. In the network-layer implementation, the ENR synthesizes an A record for the assigned synthetic IPv4 address and delivers it up the stack. If the response contains a CNAME or a DNAME record, the CNAME or DNAME chain is followed until the first terminating A or AAAA record is reached 🎀
The behaviour the ENR shows for each combination of query and network response is laid out in Figure 3:
Application | Network | ENR behavior
query | response |
---------------+-----------------------+----------------------------
IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es)
IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es)
IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es)
Figure 3: ENR Behavior Illustration2.3.1. Special Exclusion Sets for A and AAAA Records
An ENR implementation SHOULD, by default, exclude certain real IPv4 and IPv6 addresses that show up on received A and AAAA records. The addresses excluded by default MAY include addresses like the ones that shouldn't appear in the DNS or on the wire (see Section 5.1.4 of [RFC6147] and [RFC5735]). Extra addresses MAY be excluded based on configurable local policies. Basically, the ENR is a bouncer, and it has a guest list 🧚
2.3.2. DNSSEC Support
When the ENR is implemented at the network layer, A record synthesis can cause similar issues to the ones described in section 3 of [RFC6147]. While BIH is running, the host's main resolver SHOULD NOT validate A records, because the synthetic A records created by the ENR would fail validation 💀 While BIH is not running, a host's resolver can use DNS Security (DNSSEC) the same way any other resolver can. The ENR MAY support DNSSEC, in which case the (stub) resolver on a host can be configured to trust the validations done by the ENR located at the network layer. In some cases, the host's validating stub resolver can implement the ENR by itself.
When the ENR is implemented at the socket API level, there are no DNSSEC issues, because the ENR itself uses socket APIs for DNS resolution. This approach is RECOMMENDED. No notes, this is the iconic option 👑
2.3.3. Reverse DNS Lookup
When an application requests a reverse lookup (a PTR query) for an IPv4 address, the ENR MUST check whether the queried IPv4 address can be found in the address mapper's mapping table and whether it is a synthetic IPv4 address. If an entry is found and the queried IPv4 address is synthetic, the ENR MUST initiate a corresponding reverse lookup for the real IPv6 address. If the application requested a reverse lookup for an address that isn't part of the synthetic IPv4 address pool (for example, a global address), the request MUST be passed on unmodified. Leave the non-synthetic ones alone, periodt 💖
For example, when an application requests a reverse lookup for a synthetic IPv4 address, the ENR needs to intercept that query. The ENR asks the address mapper for the real IPv6 address that corresponds to the synthetic IPv4 address. The ENR shall perform a reverse lookup procedure for the destination's IPv6 address and return the name it gets back as the response to the application that made the IPv4 query 🦋
2.3.4. DNS Caches and Synthetic IPv4 Addresses
When BIH shuts down, or address mapping table entries are cleared for any reason, DNS cache entries for synthetic IPv4 addresses MUST be flushed 🧹 Stale synthetic entries are not it. There may be a DNS cache in the network-layer ENR itself, and there may also be one at the host's stub resolver 🌸
2.4. Address Mapper
Okay so the address mapper is basically the keeper of an IPv4 address pool 💖 that gets used for IPv4 address synthesis ✨. The pool is made of the IPv4 addresses from [RFC1918] as per Section 4.4. 🎀 It also keeps a table of pairs, matching each synthetic IPv4 address with a destination's real IPv6 address 🦋.
When the ENR, the translator, or the function mapper asks the address mapper for a synthetic IPv4 address for some IPv6 address, the mapper grabs one IPv4 address from the local pool, hands it back, and adds a brand new entry to the table 🧚. That registration happens in three cases, bestie:
- When the ENR only gets IPv6 addresses for the target host name, and there's no mapping entry for those IPv6 addresses yet. One or more synthetic IPv4 addresses get returned to the application, and mappings from those synthetic IPv4 addresses to the real IPv6 addresses get created 💅.
- When the ENR gets both real IPv4 and IPv6 addresses, but the real IPv4 addresses are only excluded ones (e.g., 127.0.0.1). This follows case (1) 🙈.
- When the function mapper gets triggered by a received IPv6 packet and there's no existing mapping entry for the IPv6 source address (for example, the client sent a UDP request to an anycast address, but the response came back from a unicast address) 😭.
Other possible combinations are outside of BIH. 💀 Not our problem, periodt.
3. Behavior and Network Examples ✨
Okay, here's a super basic network scenario 🌸. Figure 4 shows an IPv4-only application running on a host that's attached to the IPv6-only Internet, and it's talking to an IPv6-only server. Bump-in-the-Host is what makes this possible, and it's giving magic 🪄.
+----+ +-------------+
| H1 |----------- IPv6 Internet -------- | IPv6 server |
+----+ +-------------+
v4 only
applicationFigure 4: Network Scenario #1
Now let's level up 👑. Figure 5 shows a possible network scenario where an IPv4-only application runs on a host attached to a dual-stack network, but the destination server sits on a private site. That site is numbered with public IPv6 addresses, and it doesn't have globally reachable IPv4 addresses (like the [RFC1918] ones), and there's no port forwarding set up on the NAT44. So the only way to reach the server is over IPv6. Lowkey tragic, but also iconic 😭.
+----------------------+ +------------------------------+
| Dual-Stack Internet | | IPv4 Private site (Net 10) |
| | | IPv6 routed site |
| +---------+ +----------+ |
| +-| NAT44 |-------------+ | |
| +----+ | +---------+ | | |
| | H1 |---------+ | | | Server | |
| +----+ | +-----------+ | | |
| v4-only +-|IPv6 Router|-----------+ | |
| application +-----------+ +----------+ |
| | | Dual Stack |
| | | 10.1.1.1 |
| | | 2001:DB8::1 |
+----------------------+ +------------------------------+Figure 5: Network Scenario #2
Next up, how the host actually behaves 💅. There are two implementation alternatives, and they're both illustrated here. Figure 6 shows BIH (including the ENR) implemented at the socket API layer 🦋. Figure 7 shows BIH (including the ENR) implemented at the network layer 🧚. Both are so pretty, I'm obsessed 😍.
"dual stack" "host6"
IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name
appli- API | ENR Address Function| (v6/v4) Server
cation | Mapper Mapper |
| | | | | | | |
<<Resolve IPv4 addresses for "host6".>> | | |
| | | | | | | |
|------->|------->| Query IPv4 addresses for host6. | |
| | | | | | | |
| | |------------------------------------------------->|
| | | Query 'A' and 'AAAA' records for host6 |
| | | | | | | |
| | |<-------------------------------------------------|
| | | Reply with the 'AAAA' record. | |
| | | | | | |
| | |<<The 'AAAA' record is resolved.>> |
| | | | | | |
| | |+++++++>| Request synthetic IPv4 address |
| | | | corresponding to the IPv6 address.
| | | | | | |
| | | |<<Assign one synthetic IPv4 address.>>
| | | | | | |
| | |<+++++++| Reply with the synthetic IPv4 address.
| | | | | | |
|<-------|<-------| Reply with the IPv4 address |
| | | | | | |
| | | | | | |
<<Call IPv4 Socket API function >> | | |
| | | | | | |
|=======>|=========================>|An IPv4 Socket API action
| | | | | | |
| | | |<+++++++| Request IPv6 addresses|
| | | | | corresponding to the |
| | | | | synthetic IPv4 addresses.
| | | | | | |
| | | |+++++++>| Reply with the IPv6 addresses.
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| An IPv6 Socket API action |=======================>|
| | | | | | |
| | | | |<<IPv6 data received |
| | | | | from network.>> |
| | | | | | |
| An IPv6 Socket API action |<=======================|
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
| | | |<+++++++| Request synthetic IPv4 addresses
| | | | | corresponding to the |
| | | | | IPv6 addresses. |
| | | | | | |
| | | |+++++++>| Reply with the IPv4 addresses.
| | | | | | |
|<=======|<=========================| An IPv4 Socket API action
| | | | | | |Figure 6: Example of BIH as API Addition
"dual stack" "host6"
IPv4 stub TCP/ ENR address translator IPv6
app res. IPv4 mapper
| | | | | | | |
<<Resolve an IPv4 address for "host6".>> | |
|-->| | | | | | |
| |----------->| Query 'A' records for "host6". | Name
| | | | | | | | Server
| | | |------------------------------------------->|
| | | | Query 'A' and 'AAAA' records for "host6"
| | | | | | | | |
| | | |<-------------------------------------------|
| | | | Reply only with 'AAAA' record. |
| | | | | | | |
| | | |<<Only 'AAAA' record is resolved.>> |
| | | | | | | |
| | | |-------->| Request synthetic IPv4 address
| | | | | corresponding to each IPv6 address.
| | | | | | | |
| | | | |<<Assign synthetic IPv4 addresses.>>
| | | | | | | |
| | | |<--------| Reply with the synthetic IPv4 address.
| | | | | | | |
| | | |<<Create 'A' record for the IPv4 address.>>
| | | | | | | |
| |<-----------| Reply with the 'A' record. | |
| | | | | | | |
|<--|<<Reply with the IPv4 address | | |
| | | | | | | |
<<Send an IPv4 packet to "host6".>>| | |
| | | | | | | |
|=======>|========================>| An IPv4 packet. |
| | | | | | | |
| | | | |<++++++| Request IPv6 addresses
| | | | | | corresponding to the
| | | | | | synthetic IPv4 addresses.
| | | | | | | |
| | | | |++++++>| Reply with the IPv6|
| | | | | | addresses. |
| | | | | | | |
| | | | | |<<Translate IPv4 into IPv6.>>
| | | | | | | |
| | | |An IPv6 packet. |==========>|========>|
| | | | | | | |
| | | | | <<Reply with an IPv6 packet.>>
| | | | | | | |
| | | |An IPv6 packet. |<==========|<========|
| | | | | | | |
| | | | | |<<Translate IPv6 into IPv4.>>
| | | | | | | |
| | | | |<++++++| Request synthetic IPv4
| | | | | | addresses corresponding
| | | | | | to the IPv6 addresses.
| | | | | | | |
| | | | |++++++>| Reply with the IPv4 addresses.
| | | | | | | |
|<=======|=========================| An IPv4 packet. |
| | | | | | | |Figure 7: Example of BIH at the Network Layer
4. Considerations ✨
4.1. Socket API Conversion
Okay, this one's about the socket API 💖. IPv4 socket API functions get translated into IPv6 socket API functions that are semantically as identical as possible, and vice versa 🦋. The list of APIs that BIH intercepts is in Appendix A, so go check that out 📝.
But here's the tea ☕: some IPv4 socket API functions aren't fully compatible with IPv6, since IPv4 has features that IPv6 just doesn't have. SO_BROADCAST is the classic example 📣. Not every glow-up translates perfectly, bestie 🥺.
4.2. Socket Bindings 🎀
okay so the BIH SHOULD pick a source address for a socket out of the recommended source address pool 🌸 but only if that socket is used for communications and hasn't been explicitly bound to any IPv4 address.
if a socket has been explicitly bound, the BIH MUST NOT change that binding. hands off, bestie 🙅 that's a whole no-go zone.
4.3. ICMP Message Handling 🦋
ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT [RFC6145]. it's giving consistency ✨
in the network-layer implementation alternative, the protocol translator MUST translate ICMPv6 packets to ICMPv4 and vice versa. in the socket API implementation alternative, the socket API MUST handle conversions in a similar fashion. both paths slay 💅
4.4. IPv4 Address Pool and Mapping Table 🧚
okay this section is the big one, so get your snacks 🍓
the address pool is made up of the private IPv4 addresses from [RFC1918]. the pool can be set up at different granularities in the node. you could have one pool per node, or something finer like per-user or per-process. ngl the finer the better when it comes to avoiding trouble 💜
here's the tea: if you've got a ton of IPv4 apps talking to a ton of IPv6 servers, the address space could run out if the granularity isn't fine enough. this should be a rare event, and the chances go down as IPv6 support goes up 📉 which is honestly a whole vibe.
apps may hang onto the IPv4 addresses they learn for way longer than the DNS time to live says. so the mapping table entries should be kept active for a long time. for example, a web browser might do one DNS query and then open multiple TCP sessions to that address over time. when the mapping table needs cleaning up, the BIH may borrow techniques that NATs use, like the ones described in [RFC2663], [RFC5382], and [RFC5508]. smart, right? 🧠
why the RFC 1918 space? legacy apps generally already understand it as private address space. a brand new dedicated space would risk apps not recognising it as private 🙃 and 127/8 and 169.254/16 are rejected because apps might make assumptions when they see them. nope, not doing that to anyone 🚫
now the drama 😭 the RFC 1918 addresses the BIH uses could clash with addresses on the host's possible IPv4 interfaces and their local networks. you can soften that by using the less commonly used parts of the RFC 1918 space, but you can't fully avoid it. addresses from 172.16/12 are thought to be less likely to clash than ones from 10/8 or 192.168/16. a source address can usually be picked without a clash, but there's still a small chance that a synthesized destination address matches a real address on an attached IPv4 network. a tiny risk, but still a risk 🥺
the RECOMMENDED IPv4 addresses are the following 👑
- Primary source addresses:
172.21.112.0/20.
these addresses have to be allocated because apps use getsockname() calls. and in the network-layer mode, an IP address of the IPv4 interface has to be shown (e.g., by ifconfig). more than one address is allocated so there's room for implementation flexibility, like when a host has multiple IPv6 interfaces. the source addresses come from different subnets than the destination addresses. that way apps won't make on-link assumptions and will use NAT traversal functions instead 🙌
- Secondary source addresses:
10.170.224.0/20.
these are recommended if a host has a conflict with the primary source addresses 🔁
- Primary destination addresses:
10.170.160.0/20.
the address mapper will pick destination addresses mainly out of this pool 🎯
- Secondary destination addresses:
172.21.80.0/20.
the address mapper will pick destination addresses out of this pool if the node has a dual-stack connection that conflicts with the primary destination addresses 💫
4.5. Multi-Interface 🌈
in the case of dual-stack destinations, the BIH MUST NOT do protocol translation from IPv4 to IPv6 when the host has any IPv4 interfaces, native or tunneled, available for use. that's a hard rule, no exceptions 🛑
it's possible that an IPv4 interface gets activated while the BIH is running. for example, a node could wander into the coverage area of an IPv4-enabled network 🚶♀️ when that happens, the BIH MUST stop initiating protocol translation sessions for new connections, and the BIH MAY disconnect active sessions. whether it disconnects is up to implementations, and it may depend on whether an IPv4 address conflict happens between the addresses the BIH uses and the addresses on the new IPv4 interface. complicated, but iykyk 🤷♀️
4.6. Multicast 🍭
protocol translation for multicast is not supported. so no multicast translation over here, babe 🙅♀️
5. Application-Level Gateway Requirements Considerations 🌸
no Application-Level Gateway (ALG) functionality is specified in this document. ALG design is generally not encouraged for host-based translation, and the BIH is meant for applications that don't put IP addresses inside their protocol payloads. so the ALG drama is simply not our problem here 💅
6. Security Considerations 💀
okay, buckle up, this is serious business 😤 the security considerations of the BIH follow closely, but not completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. the following sections are copied from RFC 6146 and RFC 6147 and then modified for the BIH.
6.1. Implications on End-to-End Security 🔐
any protocols that protect IP header information are basically incompatible with the BIH. this means end-to-end IPsec verification will fail when the Authentication Header (AH) is used, in both transport and tunnel mode, and also when ESP is used in transport mode. this is inherent in any network-layer translation mechanism, so it's not a bug, it's just physics 😩
end-to-end IPsec protection can be restored using UDP encapsulation, as described in [RFC3948]. the actual extensions needed to support IPsec are out of scope for this document.
6.2. Filtering 🚧
the BIH creates binding state using packets flowing from the IPv4 side to the IPv6 side. following the guidelines defined in [RFC4787] and the procedures in this document, a BIH implementation MUST offer "Endpoint-Independent Mapping".
implementations MAY also provide support for "Address-Dependent Mapping", following the guidelines defined in [RFC4787].
the security properties, however, are determined by which packets the BIH allows in and which it doesn't. they come from the filtering behavior and the possible filtering configuration in the filtering portions of the BIH, not from the address mapping behavior. so the gatekeeping is what really matters 🛡️
6.3. Attacks on BIH 🚨
the BIH implementation is itself a potential victim of different types of attacks. in particular, the BIH can be a victim of Denial-of-Service (DoS) attacks. the implementation has a limited number of resources that attackers can consume to launch a DoS attack. the BIH also has a limited number of IPv4 addresses it uses to create bindings. even though the BIH performs address translation, an attacker could consume the synthetic IPv4 address pool by triggering a host to issue DNS queries for names that cause ENR to synthesize A records. yikes 😬
DoS attacks can also affect other limited resources on the host running the BIH, such as memory or link capacity. for instance, an attacker could launch a DoS attack on the memory of the device running the BIH by sending fragments that the BIH will store for a given period. if the number of fragments is large enough, the host's memory could be exhausted. so BIH implementations MUST implement proper protection against such attacks, for instance by allocating a limited amount of memory for fragmented packet storage 🧱
there's another consideration related to BIH resource depletion: preserving binding state. attackers may try to keep a binding state alive forever by sending periodic packets that refresh it. to let the BIH defend against this, the BIH implementation MAY choose not to extend the session entry lifetime for a specific entry when it receives packets for that entry through the external interface. the catch is that such an action would not let one-way communication sessions stay alive 🥀
6.4. DNS Considerations 🌐
the BIH works together with the DNS, so it's subject to whatever security considerations apply to the DNS mode it's operating in (i.e., recursive or stub-resolver mode). no escaping that one 🙃
BIH has the potential to interfere with DNSSEC, because the BIH modifies DNS answers. DNSSEC is designed to detect such modifications and to treat modified answers as bogus. so the BIH and DNSSEC are kind of at odds, and that's a real issue to keep in mind 😭
7. Changes since RFC 2767 and RFC 3338 ✨
this document combines and obsoletes both [RFC2767] and [RFC3338]. big glow-up energy 💖
the changes in this document mainly reflect the following:
- Addresses of RFC 1918 used for synthesis 🌷
RFC 3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 - 0.0.0.255) for synthetic IPv4 addresses. those addresses shouldn't have been used, and that may cause problems with applications. it's preferable to use the addresses defined in RFC 1918 instead, as described in Section 4.4.
- Support for reverse (PTR) DNS queries 🔄
neither RFC 2767 nor RFC 3338 included support for reverse (PTR) DNS queries. this document adds that support in Section 2.3.3.
- DNSSEC support 🔏
RFC 2767 didn't include DNSSEC considerations. those are now included in Section 2.3.2.
- Architectural recommendation 🏗️
this document recommends the socket API-layer implementation option over network layer translation. in other words, it recommends the approach introduced in RFC 2767 over the approach of RFC 3338. team socket API 🫶
- Standards-Track document 🛤️
RFC 2767 is classified as an Informational RFC, and RFC 3338 as an Experimental RFC. the IETF discussed it and decided that this technology should be on the Standards Track. glow up achieved 🌟
- Set of other extensions and improvements 🧩
a set of lesser extensions, improvements, and clarifications has been introduced. these include but are not limited to IPv4 and IPv6 address exclusion sets at Section 2.3.1, the host's DNS cache considerations, ENR behavior updates, updated security considerations, example updates, and deployment scenario updates. so much new stuff 🎀
8. Acknowledgments 🫶
the authors are grateful for discussion from Gang Chen, Dapeng Liu, Bo Zhou, Hong Liu, Tao Sun, Zhen Cao, and Feng Cao et al. in the development of this document. thank you, besties 💜
the efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens, Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and James Woodyatt in reviewing this document are gratefully acknowledged. the reviewers were giving real main character energy 🌟
special acknowledgments go to Dave Thaler for his extensive review and support 👑
the authors of RFC 2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. the authors of RFC 3338 acknowledged implementation contributions by Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation (www.i2soft.net). 🍓
the authors of "Bump-in-the-Wire IPv4/IPv6 Translator" (a draft document submitted to the v6ops WG in October 2006), P. Moster, L. Chin, and D. Green, are acknowledged. some ideas and clarifications from BIW have been adapted into this document 🦋
9. References 📚
9.1. Normative References
These are the must-read ones, bestie 📚. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van 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. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
9.2. Informative References
These ones are the extra reading that gives the whole picture 🦋 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
Appendix A. API List Intercepted by BIH ✨
Here's an informational list of some of the API functions BIH would make sense to intercept when it's implemented at the socket API layer 🧚. Heads up, it's not fully exhaustive, because the function names and services vary a lot between APIs 💀
The functions an application uses to pass addresses into the system are:
bind()connect()sendmsg()sendto()gethostbyaddr()getnameinfo()
The functions that return an address from the system to an application are:
accept()recvfrom()recvmsg()getpeername()getsockname()gethostbyname()getaddrinfo()
The functions related to socket options are:
getsocketopt()setsocketopt()
Raw sockets for IPv4 and IPv6 may be intercepted too 🌈
Most socket functions take a pointer to the socket address structure as an argument. Each IPv4 argument maps to a corresponding IPv6 argument, and vice versa 💅
According to [RFC3493], the following new IPv6 basic APIs and structures are required. The table is below 👑
IPv4 new IPv6
------------------------------------------------
AF_INET AF_INET6
sockaddr_in sockaddr_in6
gethostbyname() getaddrinfo()
gethostbyaddr() getnameinfo()
inet_ntoa()/inet_addr() inet_pton()/inet_ntop()
INADDR_ANY in6addr_any
Figure 8BIH may intercept inet_ntoa() and inet_addr() and use the address mapper for those. Doing that lets BIH support literal IP addresses 🔥 That said, IPv4 address literals can only be used once a mapping entry between the IPv4 address and the corresponding IPv6 address has been created 🙈
The gethostbyname() and getaddrinfo() calls return a list of addresses. When the name resolver function invokes getaddrinfo(), and getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, they should all be represented in the addresses returned by gethostbyname(). So if getaddrinfo() returns multiple IPv6 addresses, that means multiple address mappings will be created, one for each IPv6 address 🦋
Authors' Addresses 💌
Bill Huang
China Mobile
No.32 Xuanwumen West Street
Xicheng District
Beijing 100053
China
EMail: bill.huang@chinamobile.com
Hui Deng
China Mobile
No.32 Xuanwumen West Street
Xicheng District
Beijing 100053
China
EMail: denghui@chinamobile.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 TAMPERE
Finland
EMail: teemu.savolainen@nokia.com📦 where this page comes from
- ietf: rfc6535 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms