RFC 7051

Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix

📅 published November 2013, from ietf

RFC 7051: Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix 🎀 (Part 1 of 5)

okay so this is an Informational doc, which means it's not a Standards Track spec. It's published just to share info 🧚 It came out in November 2013 and has ISSN 2070-1721. J. Korhonen, Ed. from Broadcom and T. Savolainen, Ed. from Nokia wrote it. The title block doesn't list anything it obsoletes or updates, so it's a clean slate 💅

Abstract ✨

bestie, hosts and apps can actually benefit from knowing whether an IPv6 address was synthesized, and whether NAT64 and DNS64 are running on the network 🦋 This doc goes through every proposal anyone had come up with at the time of writing for communicating three things: whether synthesis is happening, what address format got used, and what IPv6 prefix the NAT64 and DNS64 are using. These solutions make NAT64 avoidance and local IPv6 address synthesis possible. The doc wraps up by recommending that the heuristic-discovery approach get standardized 🫶

Status of This Memo 📝

This doc is not an Internet Standards Track spec. It's published for informational purposes 🌸

It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7051 🔗

Copyright (c) 2013 IETF Trust and the people listed as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc. Any code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says 🧾

Table of Contents 📚

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Issues ..........................................................5
4. Background ......................................................6
5. Proposed Solutions to Learn about Synthesis and
   Network-Specific Prefix .........................................7
   5.1. DNS Query for a Well-Known Name ............................7
        5.1.1. Solution Description ................................7
        5.1.2. Analysis and Discussion .............................7
        5.1.3. Summary .............................................8
   5.2. EDNS0 Option Indicating AAAA Record Synthesis and Format ...8
        5.2.1. Solution Description ................................8
        5.2.2. Analysis and Discussion .............................9
        5.2.3. Summary ............................................10
   5.3. EDNS0 Flags Indicating AAAA Record Synthesis and Format ...10
        5.3.1. Solution Description ...............................10
        5.3.2. Analysis and Discussion ............................10
        5.3.3. Summary ............................................11
   5.4. DNS Resource Record for IPv4-Embedded IPv6 Address ........11
        5.4.1. Solution Description ...............................11
        5.4.2. Analysis and Discussion ............................12
        5.4.3. Summary ............................................12
   5.5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS ...13
        5.5.1. Solution Description ...............................13
        5.5.2. Analysis and Discussion ............................13
        5.5.3. Summary ............................................14
   5.6. Learning the IPv6 Prefix of a Network's NAT64
        Using DHCPv6 ..............................................14
        5.6.1. Solution Description ...............................14
        5.6.2. Analysis and Discussion ............................15
        5.6.3. Summary ............................................15

   5.7. Learning the IPv6 Prefix of a Network's NAT64
        Using Router ..............................................16
        5.7.1. Solution Description ...............................16
        5.7.2. Analysis and Discussion ............................16
        5.7.3. Summary ............................................17
   5.8. Using Application-Layer Protocols such as STUN ............17
        5.8.1. Solution Description ...............................17
        5.8.2. Analysis and Discussion ............................17
        5.8.3. Summary ............................................19
   5.9. Learning the IPv6 Prefix of a Network's NAT64
        Using Access-Technology-Specific Methods ..................19
        5.9.1. Solution Description ...............................19
        5.9.2. Analysis and Discussion ............................19
        5.9.3. Summary ............................................20
6. Conclusion .....................................................20
7. Security Considerations ........................................21
8. Contributors ...................................................22
9. Acknowledgements ...............................................22
10. References ....................................................22
   10.1. Normative References .....................................22
   10.2. Informative References ...................................23

1. Introduction 🧚

okay so hosts and apps can get a lot out of learning whether an IPv6 address was synthesized. That would mean a NAT64 is being used to reach the IPv4 network or the Internet 🌐 There are two issues that these solutions can tackle, and they're about letting hosts and apps learn the Network-Specific Prefix (NSP) [RFC6052] that the NAT64 [RFC6146] and DNS64 [RFC6147] devices use.

The first issue is figuring out whether a particular address is synthetic, which means learning that a NAT64 is there. Picture a dual-stack host with IPv4 connectivity. It could use this info to skip NAT64 and use native IPv4 transport for destinations it can reach over IPv4 🙈 We'll call this 'Issue #1' for the rest of the doc.

The second issue is figuring out how to build an IPv6 address from an IPv4 address, one that the NAT64 can route to and from. This comes up when IPv4 literals show up in the payload of some protocol, or when apps don't use DNS to resolve names and already know the destination's IPv4 address some other way 💅 We'll call this 'Issue #2' for the rest of the doc.

On top of that, a solution that tackles the first two issues has to think about three more things: whether DNS is required ('Issue #3'), whether the solution supports changing the NSP ('Issue #4'), and whether multiple NSPs are supported, either of the same or different lengths, for load-balancing ('Issue #5') ✨

This doc analyzes every proposed solution known at the time of writing for communicating whether synthesis is happening, what address format is used, and what IPv6 prefix the NAT64 and DNS64 use. From that analysis, we figure out whether learning the Network-Specific Prefix is worth solving, and if it is, what the recommended solution or solutions would be 👑

2. Terminology 📖

Address Synthesis

Address synthesis, for this doc, is a mechanism where an IPv4 address gets represented as an IPv6 address that a NAT64 device understands 🦋 The synthesized IPv6 address is made by embedding the IPv4 address as-is into an IPv6 address that starts with an NSP or WKP. The 'unused' suffix bits of the synthesized address are assumed to be set to zero, as described in Section 2.2 of [RFC6052] 🫧

DNS64

DNS extensions for network address translation from IPv6 clients to IPv4 servers. A DNS64 is a network entity that synthesizes IPv6 addresses and AAAA records out of IPv4 addresses and A records, which makes IPv4 namespaces visible in the IPv6 namespace 🌸 DNS64 uses an NSP and/or a WKP in the synthesis process.

NAT64

NAT64 is a Network Address and protocol Translation mechanism. It translates IPv6 packets into IPv4 packets and back again. It's a network entity that a host or an application may want to either avoid or use 🙌 IPv6 packets that hosts send to addresses in the NSP and/or WKP get routed to the NAT64.

NSP

Network-Specific Prefix: a prefix that a network administrator picks for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace 🍓

WKP

Well-Known Prefix: the prefix 64:ff9b::/96. The IETF picks it, and a network administrator configures it for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace 🌈

3. Issues 🎯

This doc digs into different solutions and focuses on these five issues:

Issue #1

This is the problem of telling synthesized IPv6 addresses apart from real ones, which lets a host learn that a NAT64 is in the network 🕵️

Issue #2

This is the problem of learning the NSP that the access network uses, which is needed for local IPv6 address synthesis 💖

Issue #3

This is the problem of a host that doesn't implement DNS learning the NSP or WKP that the access network uses. That means apps can't use DNS to find the prefix 🥺

Issue #4

This is the problem of supporting a changing NSP. The NSP a host learned can go stale for several reasons. For example, the host might move to a new network that uses a different NSP, which makes the old one stale. The NSP in use on the network can also change for administrative reasons, which again makes the previously learned NSP stale 🔄

Issue #5

This is the problem of supporting multiple NSPs. A network can be configured with several NSPs for address synthesis. For example, for load-balancing, each NAT64 device on the same network could get its own NSP ⚖️ Learning a single NSP is enough for an end host to do local IPv6 address synthesis successfully. But to avoid NAT64, the end host needs to learn all of the NSPs that the access network uses 💜

Part 1 of 5 done, bestie. Part 2 picks up with Section 4, Background 🌈✨

4. Background ✨

Okay bestie, so certain apps working in protocol translation scenarios can seriously benefit from knowing the IPv6 prefix used by a local NAT64 on the attached access network 🫶. This applies to Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6 Internet to the IPv4 Internet") in the IPv4/IPv6 translation framework document [RFC6144]. Scenario 3 ("The IPv6 Internet to an IPv4 network") is not considered applicable here 🙅‍♀️. In that case the NAT64 sits at the front of a remote IPv4 network, so a host on the IPv6 Internet gets very little out of learning the NSP IPv6 prefix used by that remote NAT64. The NAT64 prefix can be either a Network-Specific Prefix (NSP) or the Well-Known Prefix (WKP). Here's an (incomplete) list of use cases where it's super useful for a host or app to know about a NAT64 and its NSP/WKP:

  • Host-based DNSSEC validation. As is documented in DNS64 [RFC6147], Section 5.5, Point 3, synthetic AAAA records cannot be successfully validated in a host. 😭 So in order to use NAT64, a security-aware and validating host has to perform the DNS64 function locally, which means it has to be able to learn the WKP or the proper NSP.
  • Protocols that use IPv4 literals. In IPv6-only access, native IPv4 connections cannot be created. If a network has NAT64, it's possible to synthesize an IPv6 address by combining the IPv4 literal with the IPv6 prefix used by the NAT64. The synthesized IPv6 address can then be used to create an IPv6 connection. 🧚
  • Multicast translation [MCAST-TRANSLATOR] [V4V6MC-FRAMEWORK].
  • URI schemes with host IPv4 address literals rather than domain names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, ipp://192.0.2.1). A host can synthesize an IPv6 address out of the literal in the URI and use IPv6 to create a connection through NAT64. 🌸
  • Updating the host's preference table [RFC6724] to prefer native prefixes over translated prefixes. This is useful because applications are more likely to be able to traverse NAT44 than NAT64. 👑

DNS64 can't serve applications that aren't using DNS or that get referrals as an IPv4 literal address, which is kind of a bummer 💀. One example is the Session Description Protocol (SDP) [RFC4566], as used by the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Initiation Protocol (SIP) [RFC3261]. Other examples include web browsers, since IPv4 address literals still show up in web pages and URLs. Some of these applications could still work through NAT64, as long as they're able to create locally valid IPv6 presentations of their peers' IPv4 addresses. 🦋

It is a known issue that passing IP address referrals often fails on today's Internet [REFERRAL-PS]. Synthesizing IPv6 addresses doesn't necessarily make things any better, because the synthesized addresses that use an NSP aren't distinguishable from public IPv6 addresses for the referral receiver. However, the situation isn't really any different from today's Internet, since using public addresses doesn't really guarantee reachability (for example, because of firewalls). A node 'A' behind NAT64 may detect that it is talking to a node 'B' through NAT64, in which case node 'A' may want to avoid passing its IPv6 address as a referral to node 'B'. The node 'B' on the IPv4 side of the NAT64 should not see the IPv6 address of node 'A' from the IPv6 side of the NAT64, and so node 'B' should not be able to pass an IPv6 address referral to a node 'C'. Passing the IPv4 presentation of the IPv6 address of host 'A' to node 'C' runs into similar problems as passing a public IPv4 address of a host behind NAT44 as a referral. 🙈 This analysis focuses on detecting NAT64 presence from the IPv6 side of the NAT64.

5. Proposed Solutions to Learn about Synthesis and Network-Specific Prefix ✨

5.1. DNS Query for a Well-Known Name

5.1.1. Solution Description

Section 3 of [RFC7050] describes a host behavior for discovering the presence of a DNS64 server and a NAT64 device, plus heuristics for discovering the NSP being used. A host that needs information for local IPv6 address synthesis or for NAT64 avoidance sends a DNS query for a AAAA record of a Well-Known IPv4-only Fully Qualified Domain Name (FQDN). If the host gets a negative reply, it knows there's no DNS64 or NAT64 in the network. 🙌

If the host receives a AAAA reply, it knows the network must be using IPv6 address synthesis. After receiving a synthesized AAAA resource record, the host may examine the received IPv6 address and use heuristics, such as "subtracting" the known IPv4 address out of the synthesized IPv6 address, to figure out the NSP. 🔍

5.1.2. Analysis and Discussion

The PROs of this proposal are listed below: 💖

  • Can be used to solve Issues #1 and #2.
  • Solves Issue #4 via the lifetime of the DNS record.
  • Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response. Can find multiple address formats.
  • Does not necessarily require any standards effort.
  • Does not require host stack or resolver changes. All required logic and heuristics can be implemented in applications that are interested in learning about the address synthesis taking place.
  • The solution is backward compatible from the point of view of 'legacy' hosts and servers.
  • Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
  • Does not require explicit support from the network using NAT64.

The CONs of this proposal are listed below: 💀

  • Requires hosting of a DNS resource record for the Well-Known Name.
  • Does not provide a solution for Issue #3.
  • This method is only able to find one NSP even if a network is utilizing multiple NSPs (Issue #5) (unless DNS64 includes multiple synthetic AAAA records in the response).

5.1.3. Summary

This is the only approach that can be deployed without explicit support from the network or the host. 🌈 It could also complement explicit methods and be used as a fallback approach when explicit methods aren't supported by an access network.

5.2. EDNS0 Option Indicating AAAA Record Synthesis and Format

5.2.1. Solution Description

[SYNTH-FLAG-2011] defined a new Extension Mechanisms for DNS (EDNS0) option [RFC2671] that contained 3 flag bits (called SY-bits). The EDNS0 option served as an implicit indication of the presence of a DNS64 server and NAT64 device. SY-bit values other than '000' and '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record. 🎀

5.2.2. Analysis and Discussion

The PROs of this proposal are listed below: 💜

  • Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.
  • Solves Issue #4 via the lifetime of the DNS record.
  • Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use the same format.
  • The solution is backward compatible from the point of view of 'legacy' hosts and servers.
  • Even if the solution is bundled with DNS queries and responses, a standardization of a new DNS record type is not required; rather, just defining a new EDNS0 option is needed. ✨
  • EDNS0 option implementation requires changes only to DNS64 servers.
  • Does not require additional provisioning or management, as the EDNS0 option is added automatically by the DNS64 server to the responses.
  • Does not involve additional queries towards the global DNS infrastructure, as EDNS0 logic can be handled within the DNS64 server.

The CONs of this proposal are listed below: 😭

  • Requires end hosts to support EDNS0 extension mechanisms [RFC6891].
  • Requires host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what the NSP prefix length is.
  • Requires a modification to DNS64 servers to include the EDNS0 option in the synthesized responses.
  • Does not provide a solution for Issue #3.
  • EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0-capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between. 🥺

5.2.3. Summary

The solution based on the EDNS0 option works by extending the existing EDNS0 resource record. 🧁 Although the solution has host resolver and DNS64 server impacts, the changes are limited to those entities (end hosts, applications) that are interested in learning the presence of NAT64 and the NAT64 prefix in use. The provisioning and management overhead is minimal, if not non-existent, because the EDNS0 options are synthesized in a DNS64 server in the same manner as the synthesized AAAA resource records. Moreover, EDNS0 doesn't induce any load on DNS servers, because no new RRType query is defined. 🫶

5.3. EDNS0 Flags Indicating AAAA Record Synthesis and Format

5.3.1. Solution Description

[SYNTH-FLAG-2010] defined 3 new flag bits (called SY-bits) in the EDNS0 OPT [RFC2671] header that served as an implicit indication of the presence of a DNS64 server and NAT64 device. SY-bit values other than '000' or '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record. 🌸

5.3.2. Analysis and Discussion

okay so let's talk pros and cons 💅 first, the pros 🌸

  • ➕ Can be used to solve Issue #1 and is designed to explicitly solve Issue #2. ✨
  • ➕ Solves Issue #4 via the lifetime of the DNS record. ⏳
  • ➕ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use same format. 🦋
  • ➕ The solution is backward compatible from the point of view of 'legacy' hosts and servers. 🫶
  • ➕ EDNS0 option implementation requires changes only to DNS64 servers. 🔥
  • ➕ Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses. 🧚
  • ➕ Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server. 👑

now the cons 🥲

  • ➖ Requires end hosts to support EDNS0 extension mechanisms [RFC6891]. 💀
  • ➖ Consumes scarce flag bits from the EDNS0 OPT header. 🙈
  • ➖ Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length. 💜
  • ➖ Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses. 🍓
  • ➖ Does not provide a solution for Issue #3. 😭
  • ➖ EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0-capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between. 🚧

5.3.3. Summary

ngl this option is only here for completeness 🫠 eating three bits of the limited EDNS0 OPT space is kind of a big ask, so it's unlikely to get accepted 💔

5.4. DNS Resource Record for IPv4-Embedded IPv6 Address

5.4.1. Solution Description

okay so [DNS-A64] proposed a brand new DNS resource record (A64) that would be dedicated to storing a single IPv4-embedded IPv6 address [RFC6052] 🎀 the vibe is that a host could tell real IPv6 addresses apart from synthesized ones, because the A64 record is its own thing. the host has to send a query for an A64 record. if it gets a positive answer with an A64 record, it knows the resolved address is not native but an IPv4-embedded IPv6 address. this makes local policies way easier, so the host can prefer direct communications (avoiding IPv4-embedded IPv6 addresses when a native IPv6 address or a native IPv4 address is available) ✨ applications may be notified via a new or modified API 📱

5.4.2. Analysis and Discussion

the pros first 🌷

  • ➕ Can be used to solve Issues #1 and #5. ✨
  • ➕ Solves Issue #4 via the lifetime of the DNS record. ⏳
  • ➕ The solution is backward compatible from the point of view of 'legacy' hosts and servers. 🫶
  • ➕ Synthesized addresses can be used in authoritative DNS servers. 🧚
  • ➕ Maintains the reliability of the DNS model (i.e., a synthesized IPv6 address is presented as such and not as a native IPv6 address). 🔥
  • ➕ When both IPv4-converted and native IPv6 addresses are configured for the same QNAME, native addresses are preferred. 👑

and now the cons 😩

  • ➖ Does not address Issues #2 or #3 in any way. 💀
  • ➖ Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized. 🙈
  • ➖ Requires standardization of a new DNS resource record type (A64) and the implementation of it in both resolvers and servers. 💜
  • ➖ Requires a coordinated deployment between different flavors of DNS servers within the provider to work deterministically. 🍓
  • ➖ Additional load on the DNS servers (3 queries -- A64, AAAA, and A -- may be issued by a dual-stack host). 🥲
  • ➖ Does not help to identify synthesized IPv6 addresses if the session does not involve any DNS queries. 🚫

5.4.3. Summary

so the proposed solution does give explicit info that address synthesis is happening, which solves Issue #1 🎉 BUT standardizing a whole new DNS record type might be way too much work as a fix for a temporary transition phase 😵‍💫 defining a new record type also raises the load on the DNS server, since the host fires off parallel A64, AAAA, and A queries 📈

5.5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS

5.5.1. Solution Description

[LEARN-PREFIX] came up with two DNS-based methods for discovering the presence of a DNS64 server and a NAT64 device 🕵️‍♀️ it also proposed a way to discover the used NSP.

first, the document proposed that a host may learn the presence of a DNS64 server and a NAT64 device by receiving a TXT resource record with a well-known string (which the document proposes to be reserved by IANA) followed by the NAT64 unicast IPv6 address and the prefix length. the DNS64 server would add the TXT resource record into the DNS response 🎀

second, the document proposed specifying a new URI-Enabled NAPTR (U-NAPTR) [RFC4848] application to discover the NAT64's IPv6 prefix and length 🦋 the input domain name is exactly the same as would be used for a reverse DNS lookup, derived from the host's IPv6 in the .ip6.arpa. tree. the host doing the U-NAPTR queries may need multiple queries until the host finds the provisioned domain name with the correct prefix length. the response to a successful U-NAPTR query contains the unicast IPv6 address and the prefix length of the NAT64 device. 🧩

5.5.2. Analysis and Discussion

pros first 💖

  • ➕ Can be used to solve Issues #1 and #2. ✨
  • ➕ Solves Issue #4 via the lifetime of the DNS record. ⏳
  • ➕ Does not require host stack or resolver changes if the required logic and heuristics are implemented in applications that are interested in learning about address synthesis taking place. 🧚

now the cons 🥹

  • ➖ Requires standardization of a Well-Known Name by IANA for the TXT resource record and/or standardization of a new U-NAPTR application. 💜
  • ➖ Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length. However, it is possible that the U-NAPTR application logic is completely implemented by the application itself as noted in the PROs list. 🙈
  • ➖ The U-NAPTR prefix-learning method may entail multiple queries. 🌀
  • ➖ The U-NAPTR prefix-learning method requires provisioning of NSPs in the .ip6.arpa. tree. 🛠️
  • ➖ RFC5507 [RFC5507] specifically recommends against reusing TXT resource records to expand DNS. 🚫
  • ➖ Requires configuration on the access network's DNS servers. 🍓
  • ➖ Does not provide a solution for Issue #3. 😭
Note: If the TXT record includes multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs. 🤷‍♀️

5.5.3. Summary

implementing this solution means some changes to the applications and resolvers, kinda like the solutions in Sections 5.2, 5.3, and 5.4 🛠️ the U-NAPTR-based one is extra special though, because it also needs info provisioned into the .ip6.arpa. tree, which is no longer entirely internal to the provider hosting the NAT64/DNS64 service 👀

and the iterative approach in the U-NAPTR-based solution may mean multiple DNS queries, which is more complex and inefficient compared to the other DNS-based solutions 🌀

5.6. Learning the IPv6 Prefix of a Network's NAT64 Using DHCPv6

5.6.1. Solution Description

two separate IETF documents specified DHCPv6-based approaches 🧁

[LEARN-PREFIX] described a new DHCPv6 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix, IPv6 Any-Source Multicast (ASM) prefix, and IPv6 Source-Specific Multicast (SSM) prefix (and their lengths) for the NAT64 🎀

[DHCPV6-SHARED-ADDRESS] proposed a DHCPv6 option that could be used to communicate to a requesting host the prefix used for building IPv4-converted IPv6 addresses together with the format type and therefore also the used address synthesis algorithm. provisioning the format type is required so it can be correctly handled by the NAT64-enabled devices deployed in a given domain 🔧

5.6.2. Analysis and Discussion

pros time 🌈

  • ➕ Can be used to solve Issues #1, #2, #3, and #4 via the lifetime of the DHCPv6 information. 👑
  • ➕ Does not involve the DNS system. Therefore, applications that would not normally initiate any DNS queries can still learn the NAT64 prefix. 🦋
  • ➕ DHCPv6 is designed to provide various kinds of configuration information in a centrally managed fashion. 🧠

and the cons 😬

  • ➖ Change of NSP requires change to the DHCPv6 configuration. 🔁
  • ➖ Requires at least stateless DHCPv6 client on hosts. 💻
  • ➖ Requires support on DHCPv6 clients, which is not trivial in all operating systems. 😤
  • ➖ The DHCPv6-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64. 🙃
  • ➖ A new DHCPv6 option is required along with the corresponding changes to both DHCPv6 clients and servers. 🛠️
Note: If DHCPv6 would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs. 🤷‍♀️

5.6.3. Summary

the DHCPv6-based solution would be a really good one 😌 because it hooks into the general IP configuration phase, allows easy updates when configuration info changes, and doesn't involve DNS in general 💅 but using DHCPv6 needs configuration changes on DHCPv6 clients and servers and, in some cases, may need implementation changes too. also, it's not obvious that all devices that need translation services would implement stateless DHCPv6. for example, cellular Third Generation Partnership Project (3GPP) networks do not mandate hosts or networks to implement or deploy DHCPv6 📱

5.7. Learning the IPv6 Prefix of a Network's NAT64 Using Router Advertisements

5.7.1. Solution Description

revision three of [LEARN-PREFIX] described a new Router Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that would contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64 🚀 the RA option is essentially the same as for DHCPv6, discussed in Section 5.6 🎀

5.7.2. Analysis and Discussion ✨

okay so here are the PROs 💖

  • Can be used to solve Issues #1, #2, and #3.
  • Can solve Issue #4 if lifetime information can be communicated.

and now the CONs, aka the not-so-cute part 💀

  • Requires configuration and management of all access routers to emit correct information in the RA. This could, for example, be accomplished somehow by piggybacking on top of routing protocols (which would then require enhancements to routing protocols).
  • In some operating systems, it may not be trivial to transfer information obtained in the RA to upper layers.
  • Requires changes to the host operating system's IP stack.
  • An NSP change requires changes to the access router configuration.
  • Requires standardization of a new option to the Router Advertisement, which is generally an unfavored approach.
  • The RA-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.

Note: If the RA would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs. 🙈

5.7.3. Summary 🦋

the RA-based solution would be a really good solution because it hooks into the general IP configuration phase, allows easy updates when configuration information changes, and does not involve DNS in general 🫶. however, generally introducing any changes to the Neighbor Discovery Protocol that are not absolutely necessary is unfavored, due to the impact on both the network-side node and end host IP stack implementations 😭.

compared to the DHCPv6 equivalent solution in Section 5.6, the management overhead is greater with the RA-based solution. with the DHCPv6-based solution, the management can be centralized to a few DHCPv6 servers, whereas with the RA-based solution each access router is supposed to be configured with the same information 🌸.

5.8. Using Application-Layer Protocols such as STUN 🧚

5.8.1. Solution Description 💅

application-layer protocols, such as Session Traversal Utilities for NAT (STUN) [RFC5389], that define methods for endpoints to learn their external IP addresses could be used for NAT64 and NSP discovery. this document focuses on STUN, but the protocol could be something else as well 🍓.

a host must first use DNS to discover IPv6 representations of STUN servers' IPv4 addresses, because the host has no way to directly use IPv4 addresses to contact STUN servers 🙈.

after learning the IPv6 address of a STUN server, the STUN client sends a request to the STUN server containing a new SENDING-TO attribute that tells the server the IPv6 address to which the client sent the request. in a reply, the server includes another new attribute called RECEIVED-AS, which contains the server's IP address on which the request arrived. after receiving the reply, the client compares the SENDING-TO and RECEIVED-AS attributes to find out an NSP candidate 🔥.

5.8.2. Analysis and Discussion 👑

this solution is pretty similar to the one described in Section 5.1, but instead of using DNS, it uses STUN to get input for heuristic algorithms ✨.

here are the PROs 💖

  • Can be used to solve Issues #1 and #2.
  • Does not require host changes or supportive protocols such as DNS or DHCPv6. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.
  • The solution is backward compatible from the point of view of 'legacy' hosts and servers.
  • Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
  • Does not require explicit support from the network using NAT64.
  • Can possibly be bundled to existing STUN message exchanges as new attributes, and hence, a client can learn its external IPv4 address and an NSP/WKP with the same exchange.
  • Can be used to confirm the heuristics by synthesizing the IPv6 address of another STUN server, or by synthesizing the IPv6 address of the first STUN server after the host has heuristically determined NSP using the method in Section 5.1. In other words, the connectivity test could be done with STUN.
  • The true IPv4 destination address is used in NSP determination instead of the IPv4 address received from DNS. This may increase reliability.
  • The same STUN improvement could also be used to reveal NAT66 on the data path, if the RECEIVED-AS would contain a different IPv6 address from SENDING-TO.

and the CONs, the not-so-cute part 💀

  • Requires a server on the network to respond to the queries.
  • Requires standardization if done as an extension to STUN.
  • The solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
  • Does not solve Issue #3 if the STUN server's synthetic IPv6 address is provisioned via DNS.
  • Does not solve Issue #4 as the STUN server would not be aware of the learned NSP's validity time.
  • Does not solve Issue #5 as the STUN server would not be aware of multiple NSP prefixes.
  • Heavyweight solution, especially if an application does not otherwise support STUN.

5.8.3. Summary 🫶

an approach based on STUN or a similar protocol is a second way to solve the problem without explicit access-network support 🌈. the heuristics for NSP discovery would still be in the client, however the result may be more reliable, because an actual IPv4 destination address is compared to the IPv6 address used in sending. the additional benefit of STUN is that the client learns its public IPv4 address with the same message exchange.

STUN could also be used as the connectivity test tool if the client would first heuristically determine NSP out of DNS as described in Section 5.1, synthesize the IPv6 representation of the STUN server's IPv4 address, and then test connectivity to the STUN server 🧚.

as an additional benefit, the STUN improvement could be used for NAT66 discovery 💜.

5.9. Learning the IPv6 Prefix of a Network's NAT64 Using Access-Technology-Specific Methods 🌸

5.9.1. Solution Description 💅

several link layers on different access systems have attachment-time signaling protocols for negotiating various parameters that are used later on with the established link-layer connection. examples of such include the 3GPP Non-Access-Stratum (NAS) signaling protocol [NAS.24.301] among other link layers and tunneling solutions. there, using NAS signaling it could be possible to list all NSPs with their respective prefix lengths in generic protocol configuration option containers during the network access establishment. the lack of NSPs in protocol configuration option containers would be an implicit indication that there is no NAT64 present in the network 🙈.

5.9.2. Analysis and Discussion 🔥

here are the PROs 💖

  • Can be used to solve Issues #1, #2, #3, and #5.
  • Can solve Issue #4 if lifetime information is also communicated.

and the CONs 💀

  • Requires configuration and management of all access routers/gateways to emit correct information in "link/lower-layer" signaling. If NAT64 functionality is implemented into the access router/gateway that terminates the generic protocol configuration exchange, then the configuration management can be automated.
  • In some operating systems, it may not be trivial to transfer information obtained in "link/lower layers" to upper layers.
  • An NSP change may require changes to the access router/gateway configuration.
  • Requires standardization of a new configuration parameter exchange/container for each access system of interest. The proposed solution is indeed specific to each access technology.

5.9.3. Summary 👑

the solution based on access technology would be a good solution because it hooks into the general network access establishment phase, allows easy updates when configuration information changes, and does not involve DNS in general ✨. however, generally introducing any changes to the link/lower layers is a long and slow process, and changes would need to be done for all access technologies/systems that are used with NAT64 😭.

compared to the RA-equivalent solution in Section 5.7, the management overhead is equivalent to or even less than the RA-based solution 🦋.

6. Conclusion 🌈

our conclusion is to recommend publishing the Well-Known DNS Name heuristic discovery-based method as a Standards Track IETF document for applications and host implementors to implement as-is 💖.

as a general principle, we prefer to have as minimal a solution as possible, avoid impacts to entities not otherwise involved in the protocol translation scheme, minimize host impact, and require minimal to no operational effort on the network side 🫶.

of the different issues, we give the most weight to Issues #1 and #2. we do not give much weight to Issue #3, as cases where hosts need to synthesize IPv6 addresses but do not have DNS available seem rare to us. even if an application does not otherwise utilize DNS, it ought to be able to trigger a simple DNS query to find out WKP/NSP 🧚. Issue #4 is handled by the majority of solutions, and Issue #5 is considered to be mostly insignificant, as even if individual hosts would use only one NSP at a time, different hosts would be using different NSPs, hence supporting load-balancing targets 🍓. only one of the discussed solutions, see Section 5.6, supports learning of possible new or indicating support for multiple algorithms for address synthesis other than the one described in [RFC6052] 🔥.

the DNS64 entity has to be configured with WKP/NSP in order for it to do synthesis, so using DNS also for delivering the synthesis information sounds logical 💅. the fact that the synthesis information fate-shares the information received in the DNS response is a valuable attribute, and it reduces the possible distribution of stale prefix information ✨. however, having all DNS64 servers support explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record approaches) is difficult to arrange 😭. the U-NAPTR-based approach would require provisioning information into the .ip6.arpa. tree, which would not be entirely internal for the provider 🙈.

use of DHCPv6 would involve additional trouble configuring DHCPv6 servers and ensuring DHCPv6 clients are in place. it would also involve ensuring that the NAT64 and DHCPv6 (and possibly even some DNS64 servers) are all in sync 🌸. RA-based mechanisms are operationally expensive, as configuration would have to be placed and maintained in the access routers 💀. furthermore, both DHCPv6 and RA-based mechanisms involve entities that do not otherwise need to be aware of protocol translation (they only need to know DNS server addresses) 🫶.

finally, regarding the use of STUN, a host does not need to implement STUN, whereas DNS is, in practice, required anyway 💜. also, the STUN protocol would need to be changed on both the host and network side to support the discovery of NAT64 and WKP/NSP 🔥.

7. Security Considerations 🔐✨

okay bestie, this section is a lot of "be careful or someone gets in the middle" energy, so buckle up 😭. It's basically the same vibe as DNS64 [RFC6147]. The big worry is man-in-the-middle and denial-of-service attacks, and they happen when someone forges the info needed to synthesize IPv6 addresses from IPv4 ones 🕵️‍♀️. If an attacker pulls that off, they can slide right in as a middle man or just knock things offline. Not it 💀.

The DHCPv6 and RA-based approaches are the most exposed. An attacker can send forged RAs or pretend to be a rogue DHCPv6 server 🚨. The only things that really stop that are DHCPv6 authentication [RFC3315] or Secure Neighbor Discovery (SEND) [RFC3971], so if you're not using either of those, you're kinda leaving the door unlocked 🚪.

Now the plot twist: if an attacker can already modify and forge DNS responses (flags, addresses of known IPv4-only servers, records, etc.), then being able to mess with local address synthesis is of low additional value to them 🙃. They already have the keys to the kingdom, lowkey.

Also, a DNS-based mechanism is only as secure as the method used to configure the DNS server's IP addresses on the host 🎀. So if the host can't trust DHCPv6, it can't trust the DNS server it learned from DHCPv6 either 😬. The only exception is if the host has a way to authenticate all DNS responses, for example with DNSSEC [RFC4033]. No authentication, no trust, periodt 💅.

8. Contributors 🫶

The following individual contributed text to this document 🌸.

   Mohamed Boucadair
   France Telecom
   Rennes, 35000
   France

   EMail: mohamed.boucadair@orange-ftgroup.com

9. Acknowledgements 🍓

The authors would like to thank Dan Wing and Christian Huitema, especially for the STUN idea and for their valuable comments and discussions 💖. Literal main character behavior, honestly 👑.

Jouni Korhonen would like to specifically thank Nokia Siemens Networks, since he completed the majority of this document while employed there 🦋.

10. References 📚

10.1. Normative References

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [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.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, November 2013.

10.2. Informative References

   [DHCPV6-SHARED-ADDRESS]
              Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
              and G. Bajko, "Dynamic Host Configuration Protocol
              (DHCPv6) Options for Shared IP Addresses Solutions", Work
              in Progress, December 2009.

   [DNS-A64]  Boucadair, M. and E. Burgey, "A64: DNS Resource Record for
              IPv4-Embedded IPv6 Address", Work in Progress,
              September 2010.

   [LEARN-PREFIX]
              Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
              IPv4 Translator", Work in Progress, October 2009.

   [MCAST-TRANSLATOR]
              Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
              IPv4 - IPv6 multicast translator", Work in Progress,
              December 2010.

   [NAS.24.301]
              3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
              Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010,
              <http://www.3gpp.org/ftp/Specs/html-info/24301.htm>.

   [REFERRAL-PS]
              Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement
              for Referral", Work in Progress, February 2011.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, April 2011.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [SYNTH-FLAG-2010]
              Korhonen, J. and T. Savolainen, "EDNS0 Option for
              Indicating AAAA Record Synthesis and Format", Work
              in Progress, July 2010.

   [SYNTH-FLAG-2011]
              Korhonen, J. and T. Savolainen, "EDNS0 Option for
              Indicating AAAA Record Synthesis and Format", Work
              in Progress, February 2011.

   [V4V6MC-FRAMEWORK]
              Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
              Multicast Translation", Work in Progress, June 2011.

Authors' Addresses 🦋

   Jouni Korhonen (editor)
   Broadcom
   Porkkalankatu 24
   FIN-00180 Helsinki
   Finland

   EMail: jouni.nospam@gmail.com


   Teemu Savolainen (editor)
   Nokia
   Hermiankatu 12 D
   FI-33720 Tampere
   Finland

   EMail: teemu.savolainen@nokia.com
📦 where this page comes from