RFC 8925

IPv6-Only Preferred Option for DHCPv4

📅 published October 2020, from ietf

RFC 8925: IPv6-Only Preferred Option for DHCPv4 🎀

okay bestie, so this is RFC 8925, a Standards Track doc from the IETF (Internet Engineering Task Force), published in October 2020. The authors are L. Colitti, J. Linkova, M. Richardson and T. Mrugalski, repping Google, Sandelman and ISC 🫶. It updates RFC 2563 (the Auto-Configure one) and doesn't obsolete anything. Its ISSN is 2070-1721 ✨.

Abstract ✨

ok so this doc defines a DHCPv4 option 💖 that lets a host say "hey, I'm cool with IPv6-only mode and I don't need an IPv4 address if the network gives me IPv6." It also updates RFC 2563 so servers know what to do when they get a DHCPDISCOVER that has the new option but doesn't have the Auto-Configure option. main character energy 👑

Status of This Memo

this is an Internet Standards Track document 🦋

it's a product of the IETF, so 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). if you want more info on Internet Standards, check Section 2 of RFC 7841 📚

for the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8925 🌸

Copyright Notice

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the date of publication. read them carefully, because they explain your rights and restrictions for this doc 🧚

Code Components extracted from 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. so if you copy code out of here, keep that license text with it 🔥

1.  Introduction
  1.1.  Requirements Language
  1.2.  Terminology
2.  Reasons to Signal IPv6-Only Support in DHCPv4 Packets
3.  IPv6-Only Preferred Option
  3.1.  Option Format
  3.2.  DHCPv4 Client Behavior
  3.3.  DHCPv4 Server Behavior
    3.3.1.  Interaction with RFC 2563
  3.4.  Constants and Configuration Variables
4.  IPv6-Only Transition Technology Considerations
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌈

okay so the biggest headache with IPv6-only LANs is that they can be a total mix of hosts 🙈. some devices are IPv6-only ready, either because the OS and every app are IPv6-only capable or because they've got some 464XLAT [RFC6877] going on. others still have IPv4 dependencies and need an IPv4 address to work properly 😭.

so operators want to roll out IPv6-only bit by bit, giving IPv4 on demand. a host gets an IPv4 address only if it actually needs one, and modern mobile devices, for example, don't get IPv4 addresses at all ✨. the old way to do this was to shove IPv6-only devices onto their own IPv6-only segment or Wi-Fi SSID, and keep dual-stack devices on a different network with IPv4 and DHCPv4 turned on. but that approach has a bunch of problems, including (but not limited to) these:

splitting into more network segments creates operational chaos and hurts performance. for instance, you end up with lots of ACL entries eating up memory 💀
putting a host on the right segment is a pain. on 802.11 Wi-Fi, the user might just pick the wrong SSID 🙃. with wired 802.1x authentication, the auth server might not have enough info to choose between an IPv6-only VLAN and a dual-stack VLAN.

it would be SO good for IPv6 deployment if operators could run IPv6-mostly (or IPv4-on-demand) segments where IPv6-only hosts live alongside legacy dual-stack devices 🦋. the easy fix of just turning off IPv4 on IPv6-only-capable hosts doesn't work, because those clients still have to function on IPv4-only networks too 🙅‍♀️.

heuristics are another option. an IPv6-only-capable device could try to figure out whether the network is IPv6-only and then stop using IPv4. but that's probably not great in practice. when a host connects, it has no idea if the network is IPv4-only, dual-stack, or IPv6-only. so it usually starts configuring IPv4 and IPv6 right away, so connectivity shows up as fast as possible ⚡. if hosts waited on IPv4 until IPv6 reachability was confirmed, that would punish IPv4-only and dual-stack networks, and that's not a practical vibe 😤.

requesting IPv4 and then releasing it later, once IPv6 is confirmed, is also risky. it can cause errors users can see, because apps that already started using that IPv4 address get disrupted 😬. so what's needed is a way for a host to say its IPv4 request is optional, and for the network to signal that IPv6-only functionality (like NAT64 [RFC6146]) is available 💖.

this document delivers exactly that with a new DHCPv4 option. a client uses it to say it doesn't need an IPv4 address if the network provides IPv6-only connectivity (with NAT64 and DNS64). on an IPv4-on-demand segment, those clients don't get IPv4 addresses, while IPv4 still gets handed out on IPv4-only or dual-stack segments without NAT64 services 🌸.

[RFC2563] introduced the Auto-Configure DHCPv4 option and describes what DHCPv4 servers do when no address gets chosen for a host. this document updates [RFC2563] so server behavior changes when the DHCPOFFER contains the IPv6-Only Preferred option 🎀.

1.1. Requirements Language

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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like shown here 📏. (so if you see them lowercase, they're just normal words, no cap 🙂)

1.2. Terminology

Dual-stack network or device: a network or device with both versions of the Internet Protocol (IPv4 and IPv6) enabled and working ✨.

IPv6-only-capable host: a host that doesn't need an IPv4 address and can run on IPv6-only networks. the catch is that IPv6-only capability is per interface. say some apps on a host need IPv4, and the 464XLAT CLAT (customer-side translator) [RFC6877] is only turned on for one interface. then the host counts as IPv6-only capable when it's connected to a NAT64 network through that interface 🧠. this document assumes IPv6-only-capable hosts reach IPv4-only destinations through a NAT64 service the network provides. Section 4 talks about hypothetical scenarios for other transition technologies 🔮.

IPv4-requiring host: a host that isn't IPv6-only capable and can't work in an IPv6-only network that provides NAT64 service 💀.

IPv4 on demand: a deployment where end hosts are expected to run in IPv6-only mode by default, and some hosts can get IPv4 addresses if they explicitly opt in to receive them 🫶.

IPv6-mostly network: a network that provides NAT64 (possibly with DNS64) service and IPv4 connectivity, and lets IPv6-only, dual-stack and IPv4-only hosts all coexist on the same segment 🌈. operators can gradually turn IPv4 off on end hosts while still giving IPv4 to devices that need it. IPv6-only-capable devices don't have to get IPv4 addresses, though 💖.

IPv6-only mode: a mode where a host acts as an IPv6-only-capable host and has no IPv4 addresses assigned (except that IPv4 link-local addresses [RFC3927] may have been configured) 🧚.

IPv6-only network: a network that doesn't route IPv4 packets. it may or may not allow IPv4 connectivity inside the LAN. usually an IPv6-only network reaches IPv4-only resources through NAT64 [RFC6146] 🦋.

NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [RFC6146] 🔁.

Router Advertisement (RA): a message IPv6 routers use to announce that they exist, along with various link and Internet parameters [RFC4861] 📡.

DNS64: a mechanism that synthesizes AAAA records from A records [RFC6147] 🪄.

Network attachment event: a link up event, as described by [RFC4957], that makes a host detect an available network ⚡.

Disabling the IPv4 stack on the host interface: what the host does when it:

doesn't send any IPv4 packets from that interface,
drops all IPv4 packets it receives on that interface, and
doesn't forward any IPv4 packets to that interface 🙅‍♀️.

2. Reasons to Signal IPv6-Only Support in DHCPv4 Packets ✨

so if your network has a mix of IPv6-only-capable hosts and IPv4-requiring hosts, and you already use DHCPv4 to configure IPv4 on those hosts, it makes total sense to use that same protocol to signal that IPv4 is discretionary on a given segment 🧁. but being able to remotely turn off IPv4 on a host is kind of a new denial-of-service attack vector 😱. this approach keeps the attack surface limited to DHCPv4-related attacks, and doesn't bring in any new vulnerable pieces 🛡️.

another perk of signaling through DHCPv4 is that IPv4 only gets disabled if both the client and the server say they're IPv6-only capable 🤝. so IPv6-only-capable hosts only turn off IPv4 after an explicit signal from the network, and otherwise they keep running in dual-stack or IPv4-only mode 💅. also, the mechanism here doesn't add any extra delay to setting up a host's IP stack. if the network doesn't support IPv6-only/IPv4-on-demand mode, an IPv6-only-capable host gets an IPv4 address just as fast as any other host 🏃‍♀️.

because DHCPv4 is a client/server protocol, IPv4 can be turned off selectively on a per-host basis for a given network segment 🎯. IPv6-only, dual-stack and even IPv4-only hosts can all live on the same LAN. that means admins can save scarce IPv4 addresses, and they can roll out IPv6-only networks in steps, which is a huge boost for IPv6 adoption 🚀💜.

3. IPv6-Only Preferred Option ✨

3.1. Option Format

okay so let's look at the shape of this option 💖 it's giving tidy little packet vibes

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |   Length      |           Value               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Value (cont.)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: IPv6-Only Preferred Option Format

Here's what each field does 🎀

Code: an 8-bit identifier for the IPv6-Only Preferred option, assigned by IANA as 108. The client puts the Code in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST messages, as explained in Section 3.2.
Length: an 8-bit unsigned integer that counts the option's length, not including the Code and Length fields. The server MUST set the length field to 4. The client MUST ignore the IPv6-Only Preferred option if the length field value is not 4. Strict about it, and I respect that 🫶
Value: a 32-bit unsigned integer giving the number of seconds the client should disable DHCPv4 (the V6ONLY_WAIT configuration variable). If the server pool is explicitly configured with a V6ONLY_WAIT timer, the server MUST set the field to that configured value. Otherwise, the server MUST set it to 0. The client MUST process that field as described in Section 3.2.

The client never sets this field 🙈 it never sends the full option. It only includes the option code in the Parameter Request List, as described in Section 3.2.

3.2. DHCPv4 Client Behavior

A DHCPv4 client SHOULD let a device administrator configure IPv6-only capability either for one specific interface (to say the device is IPv6-only capable when it's connected to a NAT64 network through that interface) or for all interfaces. If only one specific interface is set as IPv6-only capable, the DHCPv4 client MUST NOT treat the host as IPv6-only capable when it sends or receives DHCPv4 packets on any other interface. Main character energy, but make it interface-specific 💅

A DHCPv4 client on an IPv4-requiring host MUST NOT include the IPv6-Only Preferred option code in the Parameter Request List of any DHCPv4 packets. It MUST ignore that option in packets received from DHCPv4 servers. Not that deep for these hosts 💀

DHCPv4 clients running on IPv6-only-capable hosts SHOULD include the IPv6-Only Preferred option code in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST messages, for the interfaces that are enabled. They should then follow the processing below on a per-enabled-interface basis 🦋

If the client did not include the IPv6-Only Preferred option code in the Parameter Request List in the DHCPDISCOVER or DHCPREQUEST message, it MUST ignore the IPv6-Only Preferred option in any messages it gets from the server. No sneaking it in 🙅‍♀️

If the client includes the IPv6-Only Preferred option code in the Parameter Request List and the DHCPOFFER message from the server contains a valid IPv6-Only Preferred option, the client SHOULD NOT request the IPv4 address given in the DHCPOFFER. If the IPv6-Only Preferred option returned by the server has a value greater than or equal to MIN_V6ONLY_WAIT, the client SHOULD set the V6ONLY_WAIT timer to that value. Otherwise, the client SHOULD set the V6ONLY_WAIT timer to MIN_V6ONLY_WAIT. The client SHOULD stop the DHCPv4 configuration process for V6ONLY_WAIT seconds, or until a network attachment event, whichever happens first. The host MAY disable the IPv4 stack completely on the affected interface for V6ONLY_WAIT seconds, or until the network attachment event, whichever happens first. Timer drama, but the good kind ⏰✨

The IPv6-Only Preferred option SHOULD be included in the Parameter Request List in DHCPREQUEST messages. That covers the case after receiving a DHCPOFFER without this option, for an INIT-REBOOT, and when renewing or rebinding a leased address. If the DHCPv4 server replies with a DHCPACK that includes the IPv6-Only Preferred option, the client's behavior depends on its state. If the client is in the INIT-REBOOT state, it SHOULD stop the DHCPv4 configuration process or disable the IPv4 stack completely for V6ONLY_WAIT seconds, or until the network attachment event, whichever happens first. It also MAY send a DHCPRELEASE message. If the client is in any other state, it SHOULD keep using the assigned IPv4 address until the next DHCPv4 reconfiguration events 🌸

If the client includes the IPv6-Only Preferred option code in the Parameter Request List and the server responds with a DHCPOFFER message without a valid IPv6-Only Preferred option, the client MUST proceed as normal with a DHCPREQUEST. Nothing extra needed, bestie 🍓

If the client waits for multiple DHCPOFFER responses and then picks one of them, it MUST follow the processing for the IPv6-Only Preferred option based on the selected response. A client MAY use the presence of the IPv6-Only Preferred option as a selection criterion. Choose wisely 👑

When an IPv6-only-capable client gets the IPv6-Only Preferred option from the server, the client MAY configure an IPv4 link-local address [RFC3927]. In that case, IPv6-only-capable devices might still be able to talk over IPv4 to other devices on the link. The Auto-Configure option [RFC2563] can be used to control autoconfiguration of IPv4 link-local addresses. Section 3.3.1 covers how the IPv6-Only Preferred option and the Auto-Configure option interact 🧚

3.3. DHCPv4 Server Behavior

The DHCPv4 server SHOULD be able to configure all pools, or individual pools, to include the IPv6-Only Preferred option in DHCPv4 responses if the client included the option code in the Parameter Request List. The DHCPv4 server MAY have a configuration option to specify the V6ONLY_WAIT timer for all IPv6-mostly pools, or for individual ones 🎀

The server MUST NOT include the IPv6-Only Preferred option in the DHCPOFFER or DHCPACK message if the selected pool is not configured as IPv6-mostly. The server MUST NOT include the IPv6-Only Preferred option in the DHCPOFFER or DHCPACK message if the option was not present in the Parameter Request List sent by the client. Gatekeeping at its finest 🔥

If the IPv6-Only Preferred option is in the Parameter Request List received from the client, and the corresponding DHCPv4 pool is explicitly configured as belonging to an IPv6-mostly network segment, the server MUST include the IPv6-Only Preferred option when it responds with the DHCPOFFER or DHCPACK message. If the server responds with the IPv6-Only Preferred option and the V6ONLY_WAIT timer is configured for the pool, the server MUST copy the configured value to the IPv6-Only Preferred option value field. Otherwise, it MUST set the field to zero. The server SHOULD NOT assign an address from the pool. Instead, it SHOULD return 0.0.0.0 as the offered address. Alternatively, if offering 0.0.0.0 is not feasible (for example, because of some limitations of the server or the network infrastructure), the server MAY include in the DHCPOFFER an available IPv4 address from the pool, following the recommendations in [RFC2131]. In that case, the offered address MUST be a valid address that is not committed to any other client. Because the client is never expected to request this address, the server SHOULD NOT reserve the address and SHOULD NOT verify its uniqueness. If the client then issues a DHCPREQUEST for the address, the server MUST process it per [RFC2131], including replying with a DHCPACK for the address if it has not been committed to another client in the meantime 🧩

If a client includes both a Rapid Commit option [RFC4039] and an IPv6-Only Preferred option in the DHCPDISCOVER message, the server SHOULD NOT honor the Rapid Commit option if the response to the client would contain the IPv6-Only Preferred option. It SHOULD instead respond with a DHCPOFFER as described above. Rapid Commit gets benched here 🙃

If the server receives a DHCPREQUEST containing the IPv6-Only Preferred option for the address from a pool configured as IPv6-mostly, the server MUST process it per [RFC2131].

3.3.1. Interaction with RFC 2563

[RFC2563] defines an Auto-Configure DHCPv4 option that turns off IPv4 link-local address configuration for IPv4 clients. Clients can support both the IPv6-Only Preferred option and the Auto-Configure option, just one of them, or neither one. If a client sends both the IPv6-Only Preferred option and the Auto-Configure option, the network administrator can stop the host from configuring an IPv4 link-local address on an IPv6-mostly network. To do that, the server needs to send a DHCPOFFER that contains a 'yiaddr' of 0.0.0.0, and the Auto-Configure flag set to "DoNotAutoConfigure" 🔒

Special care should be taken, though, when a server supports both options and receives only the IPv6-Only Preferred option from a client. Section 2.3 of [RFC2563] says that if no address is chosen for the host (which is the case for IPv6-only-capable clients on an IPv6-mostly network), then "If the DHCPDISCOVER does not contain the Auto-Configure option, it is not answered." That would be a problem for clients that support the IPv6-Only Preferred option but not the Auto-Configure option. They'd get no response from the server and keep asking for one, instead of turning off DHCPv4 for V6ONLY_WAIT seconds. So the following update is made to Section 2.3 of [RFC2563] 😭

   OLD TEXT:

   |  However, if no address is chosen for the host, a few additional
   |  steps MUST be taken.
   |
   |  If the DHCPDISCOVER does not contain the Auto-Configure option, it
   |  is not answered.

   NEW TEXT:

   |  However, if no address is chosen for the host, a few additional
   |  steps MUST be taken.
   |
   |  If the DHCPDISCOVER does not contain the Auto-Configure option and
   |  the IPv6-Only Preferred option is not present, it is not answered.
   |  If the DHCPDISCOVER does not contain the Auto-Configure option but
   |  contains the IPv6-Only Preferred option, the processing rules for
   |  the IPv6-Only Preferred option apply.

3.4. Constants and Configuration Variables

Here are the important numbers, the lil' settings that run the show ⭐

V6ONLY_WAIT: the time for which the client SHOULD stop the DHCPv4 configuration process. The value MUST NOT be less than MIN_V6ONLY_WAIT seconds. Default: 1800 seconds 🌈
MIN_V6ONLY_WAIT: the lower boundary for V6ONLY_WAIT. Value: 300 seconds 💜

4. IPv6-Only Transition Technology Considerations 🌈

okay so until IPv6 adoption across the Internet hits 100%, an IPv6-only host talking to an IPv4-only destination needs some kind of transition mechanism set up in the network 🫶. At the time of writing, the only one that end hosts widely support is NAT64 [RFC6146] (with or without 464XLAT). So the IPv6-Only Preferred option only gets sent by hosts that can actually run on NAT64 networks 💅. In a typical setup, a network admin wouldn't configure the DHCPv4 server to hand out the IPv6-Only Preferred option unless the network actually provides NAT64 service ✨.

Hypothetically, multiple transition technologies could coexist 🦋. If that happened, the client and server would need some kind of negotiation so the client's transition tech matches what the network provides. BUT it seems pretty unlikely that a brand new transition technology will show up and get widely adopted anytime soon 🙈. So adding support for stuff that doesn't exist yet feels kinda suboptimal, and this document just assumes NAT64 is the thing that handles connectivity between IPv6 and IPv4 💖. If a new mechanism does become widely deployed by some miracle, whether the IPv6-Only Preferred option still applies depends on how that mechanism works. If it's fully transparent to hosts that support both NAT64 and the IPv6-Only Preferred option, the option can keep being used with it 🎀. If it's not compatible with NAT64 and the host has to implement something to support it, then a new DHCPv4 option would need to be defined 🧚.

Also, saying a host (technically, a host interface) is IPv6-only capable is a policy decision 👑. For example:

An OS vendor might make that call and set their DHCPv4 clients to send the IPv6-Only Preferred option by default, if the OS has a 464XLAT CLAT [RFC6877] enabled 💅.
An enterprise network admin might provision corporate hosts as IPv6-only capable, but only if every app users are supposed to run has been tested in an IPv6-only environment (or if a 464XLAT CLAT is enabled on the devices) 🍓.
Internet of Things (IoT) devices might ship in IPv6-only-capable mode if they're only designed to connect to an IPv6-enabled cloud destination 🌸.

5. IANA Considerations 📝

okay bestie, IANA has assigned a new DHCPv4 option code for the IPv6-Only Preferred option 🎀. It lives in the "BOOTP Vendor Extensions and DHCP Options" registry, which you can find at https://www.iana.org/assignments/bootp-dhcp-parameters/ ✨. Here's the entry:

Tag:  108
Name:  IPv6-Only Preferred
Data Length:  4
Meaning:  Number of seconds that DHCPv4 should be disabled
Reference:  RFC 8925

6. Security Considerations 🚨

okay this section is giving thriller plot, so buckle up 😭. An attacker could send a spoofed DHCPOFFER with an IPv6-Only Preferred option whose value field is set to a huge number, like 0xffffffff. That would effectively disable DHCPv4 on clients that support the option 💀. If the network is IPv4-only, those clients would completely lose connectivity 🙀. On a dual-stack network without NAT64 service, only connectivity to IPv4-only destinations would be affected 🥲. Recovering from this kind of attack would require triggering a network attachment event 🔄.

BUT here's the tea: if the network doesn't protect against a rogue DHCPv4 server, a similar attack can be pulled off by offering an invalid address and setting the Lease Time option [RFC2132] value field to 0xffffffff 😱. That one hits ALL hosts, not just the ones that support the IPv6-Only Preferred option 🚫. So the security measures against rogue DHCPv4 servers are already enough to stop attacks specific to the IPv6-Only Preferred option 🛡️. Also, these attacks only work if the victim picks the rogue DHCPOFFER over the legit offers 🤨. So for the attack to succeed, the attacker has to know the selection criteria the client uses and make their rogue offer more appealing than the others 🕵️‍♀️.

Lastly, disabling IPv4 on a host after it receives the IPv6-Only Preferred option from the DHCPv4 server protects that host from IPv4-related attacks 🦺. Because it reduces the attack surface, it could honestly be considered a security feature 💜.

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
           RFC 2131, DOI 10.17487/RFC2131, March 1997,
           <https://www.rfc-editor.org/info/rfc2131>.

[RFC2563]  Troll, R., "DHCP Option to Disable Stateless Auto-
           Configuration in IPv4 Clients", RFC 2563,
           DOI 10.17487/RFC2563, May 1999,
           <https://www.rfc-editor.org/info/rfc2563>.

[RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
           Configuration of IPv4 Link-Local Addresses", RFC 3927,
           DOI 10.17487/RFC3927, May 2005,
           <https://www.rfc-editor.org/info/rfc3927>.

[RFC4039]  Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
           the Dynamic Host Configuration Protocol version 4
           (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005,
           <https://www.rfc-editor.org/info/rfc4039>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
           Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
           <https://www.rfc-editor.org/info/rfc2132>.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           DOI 10.17487/RFC4861, September 2007,
           <https://www.rfc-editor.org/info/rfc4861>.

[RFC4957]  Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli,
           S., and A. Yegin, Ed., "Link-Layer Event Notifications for
           Detecting Network Attachments", RFC 4957,
           DOI 10.17487/RFC4957, August 2007,
           <https://www.rfc-editor.org/info/rfc4957>.

[RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
           NAT64: Network Address and Protocol Translation from IPv6
           Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
           April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[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,
           DOI 10.17487/RFC6147, April 2011,
           <https://www.rfc-editor.org/info/rfc6147>.

[RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
           Combination of Stateful and Stateless Translation",
           RFC 6877, DOI 10.17487/RFC6877, April 2013,
           <https://www.rfc-editor.org/info/rfc6877>.

Acknowledgements 💌

Huge thanks to these amazing people (listed alphabetically) for reviewing and giving feedback: Mohamed Boucadair, Martin Duke, Russ Housley, Sheng Jiang, Benjamin Kaduk, Murray Kucherawy, Ted Lemon, Roy Marples, Bjorn Mork, Alvaro Retana, Peng Shuping, Pascal Thubert, Bernie Volz, Éric Vyncke, and Robert Wilton. The authors also want to thank Bob Hinden and Brian Carpenter for the original idea of signaling IPv6-only capability to hosts 🌟. And special thanks to Erik Kline, Mark Townsley, and Maciej Zenczykowski for the discussion that led to the idea of signaling IPv6-only capability over DHCPv4 🫶🥹.

Authors' Addresses 🖊️

Lorenzo Colitti
Google
Shibuya 3-21-3, Shibuya, Tokyo
150-0002
Japan

Email: lorenzo@google.com


Jen Linkova
Google
1 Darling Island Rd
Pyrmont NSW 2009
Australia

Email: furry@google.com


Michael C. Richardson
Sandelman Software Works

Email: mcr+ietf@sandelman.ca
URI:   https://www.sandelman.ca/


Tomek Mrugalski
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America

Email: tomasz.mrugalski@gmail.com

📦 where this page comes from

ietf: rfc8925 2020-10
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms