RFC 7618

Dynamic Allocation of Shared IPv4 Addresses

📅 published August 2015, from ietf

RFC 7618: Dynamic Allocation of Shared IPv4 Addresses 🎀

okay bestie, let's do the paperwork first 💅 this is from the Internet Engineering Task Force (IETF), it's Request for Comments: 7618, and it's a Standards Track doc, so it's the real deal, not a vibe. It's dated August 2015 and the ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there 🦋

The authors are Y. Cui and Q. Sun (Tsinghua University), I. Farrer (Deutsche Telekom AG), Y. Lee (Comcast), Q. Sun again (China Telecom), and M. Boucadair (France Telecom). yes, Q. Sun is in the list twice, it's giving multiverse 🌈

Abstract ✨

so this memo explains how to dynamically hand out shared IPv4 addresses to clients using DHCPv4 🧚 address sharing means one IPv4 address can go to several active clients at the same time, and each client is told apart by its own unique set of transport-layer source port numbers. it describes the changes that existing DHCPv4 client and server behavior needs, and it adds a brand new DHCPv4 option for giving clients shared IPv4 addresses 🎀

address sharing comes with limits, so the memo spells those out too, and it recommends architectures and technologies where address sharing can be used 🫶

Status of This Memo 🌸

this is an Internet Standards Track document 💜

this doc is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚

info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7618 ✨

Copyright (c) 2015 IETF Trust and the persons identified 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. read them carefully, because they explain your rights and restrictions for this doc 📜 any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💖

Table of Contents 🌈

1. Introduction ....................................................3
2. Applicability Statement .........................................3
3. Requirements Language ...........................................4
4. Terminology .....................................................4
5. Functional Overview .............................................4
6. Client-Server Interaction .......................................5
7. Client Behavior .................................................6
   7.1. Restrictions to Client Usage of a Shared IPv4 Address ......7
8. Server Behavior .................................................7
   8.1. Leasing Shared and Non-Shared IPv4 Addresses from a
        Single DHCP 4o6 Server .....................................9
9. DHCPv4 Port Parameters Option ...................................9
10. Security Considerations .......................................10
   10.1. Port Randomization .......................................11
11. IANA Considerations ...........................................11
12. References ....................................................11
   12.1. Normative References .....................................11
   12.2. Informative References ...................................12
Acknowledgements ..................................................14
Authors' Addresses ................................................14

1. Introduction ✨

okay so public IPv4 addresses are scarce, which means operators can't always give every connected device its own full IPv4 address 😭 this is extra painful while an operator is moving from its existing native IPv4 network to a native IPv6 network with IPv4 running as an overlay service. during that phase, public IPv4 addresses are needed for both the existing networks and the transition networks 🧚

there are two main types of solutions for this (see Appendix A of [RFC6269]):

  1. Deploying Carrier-Grade Network Address Translation devices (CGNs) [RFC6888].
  2. Distributing the same public IPv4 address to multiple clients, told apart by non-overlapping Layer 4 port sets.

this memo is all about the second category 🦋

[RFC7341] introduces a "DHCP 4o6 server". it offers dynamic leasing for IPv4 addresses to clients, as described in DHCPv4 [RFC2131], except it's transported inside a DHCPv6 message flow 🌸 this memo specifies a new DHCPv4 option, OPTION_V4_PORTPARAMS, and explains how it can be used for dynamic leasing of shared IPv4 addresses 💜

even though DHCPv4 over DHCPv6 is the underlying DHCPv4 transport mechanism throughout this document, OPTION_V4_PORTPARAMS as a DHCPv4 option may also be used in other solutions, if required 🫶

2. Applicability Statement 🎀

the solution lets multiple hosts be allocated the same IP address at the same time. since the IP address stops being a unique identifier for a host, this solution is only suitable for specific architectures based on the Address plus Port model (A+P) [RFC6346] 🙈 specifically, this doc presents a solution that applies to [RFC7596] and certain configurations of [RFC7597] (for example, Embedded Address bit (EA-bit) length set to 0) 💅

the solution should only be used on point-to-point links, tunnels, and/or in environments where authentication at the link layer is performed before IP address assignment. it is not suitable for network access over shared media (for example, Ethernet, WLAN, cable) 🚫

3. Requirements Language 📜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🤓

4. Terminology 🧚

this doc uses the following terms:

Shared IPv4 address:  An IPv4 address with a restricted Layer 4
                      port set.

Port Set ID (PSID):   Identifier for a range of ports assigned to a
                      DHCP client.

5. Functional Overview 🌈

okay so functionally, the DHCP 4o6 server handles dynamic allocation of shared IPv4 addresses a lot like the normal dynamic allocation process for "full" IPv4 addresses in [RFC2131] 💖 the big difference is that the DHCP 4o6 server can give the same IPv4 address to more than one DHCP 4o6 client at once, as long as each shared-address allocation also comes with a range of Layer 4 source ports that's unique to that address. so the combined tuple of IPv4 address and Port Set ID has to be unique for each active lease 👑

the DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described below), which is a DHCPv4 option carrying PSID information. the client puts this option inside the Parameter Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and DHCPREQUEST messages, which tells the DHCP 4o6 server it supports shared, dynamic address leasing ✨

the server implements OPTION_V4_PORTPARAMS too, so it can spot clients that support shared, dynamic address leasing. with this option, the server can dynamically allocate PSIDs to clients and keep track of shared IPv4 address leases. it manages unique client leases based on the IPv4 address and PSID tuple, instead of using only the IPv4 address 🦋

now the tricky bit 🙈 if a client that can do dynamic, shared addressing gets more than one DHCP 4o6 offer, and one of those offers doesn't contain OPTION_V4_PORTPARAMS (meaning it's an offer for a full IPv4 address), then the client SHOULD prefer the full IPv4 offer over the shared IPv4 address offer(s), unless it's specifically configured otherwise 🫶

6. Client-Server Interaction ✨

okay so this whole DHCPv4 message flow gets tunneled inside the DHCPv4-query and DHCPv4-response messages, as described in DHCPv4 over DHCPv6 [RFC7341] 🫶

  1. okay first, the client builds the DHCPDISCOVER message that rides inside the DHCPv4-query message. The DHCPDISCOVER message MUST include the client identifier option (constructed as per [RFC4361]) and the Parameter Request List option with the code OPTION_V4_PORTPARAMS 💖 The client MAY insert an OPTION_V4_PORTPARAMS with preferred values in related fields as a suggestion to the DHCP 4o6 server 🌸
  2. DHCP 4o6 servers that get that DHCPDISCOVER and support shared IPv4 addresses reply with a DHCPOFFER message. It carries the shared IPv4 address in the yiaddr field, and they MUST add an OPTION_V4_PORTPARAMS option containing an available restricted port set 🦋 If the DHCPDISCOVER had an OPTION_V4_PORTPARAMS option with a non-zero PSID-len field, the DHCP 4o6 server MAY allocate a port set of the requested size to the client (depending on policy) ✨ Then the DHCPOFFER gets wrapped in the DHCPv4-response message and sent back to the client 💌
  3. the client looks at every DHCPOFFER it got and picks one (for example, based on the configuration parameters it received, like the size of the offered port set) 👑 Then it sends a DHCPREQUEST wrapped in the DHCPv4-query message, containing the matching OPTION_V4_PORTPARAMS from that DHCPOFFER 🎀
  4. the server named in the DHCPREQUEST makes a binding for the client. The binding includes the client identifier, the IPv4 address, and the PSID 🧚 Both the server and the client use these parameters to identify a lease in any DHCP message. The server MUST respond with a DHCPACK message containing OPTION_V4_PORTPARAMS for the requesting client 🔥
  5. when the client gets the DHCPACK with the configuration parameters, the client MUST NOT perform an in-use probe on the address, such as ARPing for a duplicate allocated address 🙈
  6. if the client decides to give up its lease by sending a DHCPRELEASE message, it MUST include the leased network address and OPTION_V4_PORTPARAMS (with the allocated PSID) so the lease being released gets identified 🍓

okay now the restart case 🌈 If the client already stored the previously allocated address and restricted port set, the logic in Section 3.2 of [RFC2131] MUST be followed, on the condition that the client's source IPv6 address for DHCP 4o6 does not change. Note that this lines up with the INIT-REBOOT state defined in [RFC2131]. The client MUST include the OPTION_V4_PORTPARAMS with the requested port-set information in the message flow, which starts with a DHCPREQUEST message. And if the client's DHCP 4o6 IPv6 source address changes for any reason, the client MUST re-initiate the DHCP 4o6 shared-address provisioning process by sending a DHCPDISCOVER message 😭

7. Client Behavior 💅

A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4 address MUST include the OPTION_V4_PORTPARAMS Option Code in the Parameter Request List option 🫶 If a client was already successfully given an IPv4 address and PSID before, its DHCPDISCOVER message MAY include the Requested IP Address option along with an OPTION_V4_PORTPARAMS to ask for that specific IPv4 address and PSID to be reassigned 🦋 Or, the client MAY omit the Requested IP Address option but still include an OPTION_V4_PORTPARAMS with a non-zero value in only the PSID-len field, as a hint to the server about the preferred size of the port set 🌸

A client that asks for OPTION_V4_PORTPARAMS but gets DHCPOFFER and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as described in Section 9 of [RFC7341] and configure a full IPv4 address with no address sharing (see Section 8.1) 🍓

When a client receives a DHCPACK message containing OPTION_V4_PORTPARAMS, it MUST use the received explicit PSID for configuring the interface the DHCP 4o6 request was made for ✨

The client MUST NOT probe a newly received IPv4 address (e.g., using ARP) to see if another host is using it 🙈

When the client renews or releases its DHCP lease, it MUST include the offset, PSID length, and PSID values in OPTION_V4_PORTPARAMS, and send it to the server within the corresponding DHCPv4 messages 💖

If the client's DHCP 4o6 IPv6 source address changes for any reason, the client MUST re-initiate the DHCP 4o6 shared-address provisioning process by sending a DHCPDISCOVER message 😭

7.1. Restrictions to Client Usage of a Shared IPv4 Address 🔥

okay so a single IPv4 address is shared between a bunch of different clients, which means the shared address is only suitable for certain uses 🧚 The client MUST implement a function to make sure that only the allocated Layer 4 ports of the shared IPv4 address get used for sourcing new connections or accepting inbound connections 👑

The client MUST apply the following rules for all traffic going to, or coming from, the shared IPv4 address:

  • The client MUST use only port-aware protocols (e.g., TCP, UDP, the Datagram Congestion Control Protocol (DCCP)) and be ICMP compliant with [RFC5508].
  • All connections originating from the shared IPv4 address MUST use a source port taken from the allocated restricted port set.
  • The client MUST NOT accept inbound connections on ports outside of the allocated restricted port set.

To prevent addressing conflicts that could come from the same IPv4 address being handed out to more than one client, the client MUST NOT use the received restricted IPv4 address to perform ARP operations 🙅‍♀️

How a client carries out the rules above is out of scope for this document 🌈

If the DHCPv4-over-DHCPv6 configuration mechanism fails for any reason, the client MUST NOT configure an IPv4 link-local address [RFC3927] (taken from the 169.254.0.0/16 range) 😭

8. Server Behavior 🧚

The DHCP 4o6 server MUST NOT reply with OPTION_V4_PORTPARAMS unless the client has explicitly listed the Option Code in the Parameter Request List (Option 55) [RFC2132] 🙈

The DHCP 4o6 server SHOULD reply with OPTION_V4_PORTPARAMS if the client includes OPTION_V4_PORTPARAMS in its Parameter Request List 💅 To get dynamic management of shared IPv4 addresses, the server is required to implement an address and port-set pool that does the same job as the address pool in a regular DHCP server 🎀 The server also uses the combo of address and PSID as the key for keeping track of a lease's state and for searching for an available lease to assign ✨ The leasing database is required to include the IPv4 address, PSID, and client identifier of the requesting client 🫶

When a server gets a DHCPDISCOVER message with OPTION_V4_PORTPARAMS in the Parameter Request List option, it works out an IPv4 address with a PSID for the requesting client 🦋 If an IPv4 address with a PSID is available, the server SHOULD follow the logic below to pick which specific address and PSID to provision to the client 👑 The logic is similar to what's described in Section 4.3.1 of [RFC2131] 💖

  • The client's current address with the PSID, as recorded in the client's current lease binding, ELSE
  • The client's previous address with the PSID, as recorded in the client's (expired or released) binding, if that address with PSID is in the server's pool of available addresses and PSIDs, and not already allocated, ELSE
  • The address requested in the Requested IP Address option along with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if that pair of address and PSID is valid and not already allocated, ELSE
  • A new address with a PSID allocated from the server's pool of available addresses and PSIDs.

When a DHCPRELEASE message with OPTION_V4_PORTPARAMS comes in, the server searches for the lease using the address in the ciaddr field and the PSID information in the OPTION_V4_PORTPARAMS, and marks the lease as unallocated if the server keeps a record (matching that PSID) for that client 🍓

The port-set assignment MUST be coupled with the address assignment process 💕 So, the server MUST assign the address and port set in the same DHCP message 💕

When defining the pools of IPv4 addresses and PSIDs that are available to lease to clients, the server MUST implement a mechanism to reserve some port ranges (e.g., 0-1023) from allocation to clients 🛡️ The reservation policy SHOULD be configurable ⭐

8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 4o6 Server 🌸

A single DHCP 4o6 server may serve clients that don't support OPTION_V4_PORTPARAMS, as well as those that do 🌈 The rules for handing out shared addresses are different from the rules for full IPv4 address assignment, so the DHCP 4o6 server MUST implement a mechanism that makes sure clients not supporting OPTION_V4_PORTPARAMS never receive shared addresses 🙅‍♀️ For example, two separate IPv4 addressing pools could be used, one of which allocates IPv4 addresses and PSIDs only to clients that asked for them 🦋

If the server is only configured with address pools for shared-address allocation, it MUST discard requests that don't contain OPTION_V4_PORTPARAMS in the Parameter Request List option 💀

A server configured with non-shared address pools can be told to honor received requests that contain OPTION_V4_PORTPARAMS in the Parameter Request List option. That means it ignores OPTION_V4_PORTPARAMS and serves the requesting clients with non-shared IPv4 addresses 🫧

9. DHCPv4 Port Parameters Option ✨

okay bestie, the offset, PSID-len, and PSID fields in the DHCPv4 Port Parameters option mean the exact same thing as their twins in the S46 Port Parameters option (Section 4.5 of [RFC7598]) 🎀 using the same encoding in both is on purpose, so existing port-set implementations stay compatible. so smart, literally iconic 💅

here's what OPTION_V4_PORTPARAMS looks like 👇

              0                             1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |      option-code      |     option-len        |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |         offset        |       PSID-len        |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                     PSID                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                  Figure 1: DHCPv4 Port Parameters Option

the fields, explained 🦋

  • option-code: OPTION_V4_PORTPARAMS (159) 🧚
  • option-len: 4
  • offset: PSID offset 🌸 this is an 8-bit field that gives the numeric value for the excluded port range/offset bits ('a' bits), as per Section 5.1 of [RFC7597]. allowed values are between 0 and 15, and the default is 6 for MAP-based implementations. a Lightweight 4over6 client doesn't use this parameter, so it should be set to 0.
  • PSID-len: the bit length of the significant bits in the PSID field (also called 'k') 💜 when it's set to 0, the PSID field is to be ignored. after the first 'a' bits, there are k bits in the port number that represent the PSID value, and the address-sharing ratio is then 2^k. no cap, that math slaps 🔥
  • PSID: an explicit 16-bit (unsigned word) PSID value 🍓 it algorithmically identifies a set of ports assigned to a client. the first k bits on the left of this 2-octet field are the PSID value, and the remaining (16 - k) bits on the right are padding zeros.

Section 5.1 of [RFC7597] has the full rundown on how the client interprets the PSID, so go read that if you want the deep dive 🤓

⚠️ bestie, the port sets that contain well-known ports MUST NOT be assigned, unless the operator has explicitly configured otherwise (for example, by allocating a full IPv4 address). the system ports ([RFC6335]) and ports reserved by ISPs are excluded this way, so don't mess with it 🙅‍♀️

10. Security Considerations 💀

ok this section is serious, so listen up 🫶

The security considerations described in [RFC2131] and [RFC7341] are also potentially applicable to this solution. unauthorized DHCP 4o6 servers in the network could be used to stage an amplification attack or to supply an invalid configuration, which leads to service disruption 😭 the risks can be reduced by using unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option [RFC7341]).

a malicious user could also attempt a DoS attack by requesting a large number of IPv4 address (or fractional address) and port-set allocations, which would exhaust the available addresses and port sets for other clients. this can be mitigated by implementing, on each applicable customer site, a DHCP 4o6 address allocation policy that limits the number of simultaneously active IPv4 leases for clients whose requests come from that customer site.

the purpose of the client identifier option is to make sure the same client keeps the same parameters over time. however, this interferes with the client's privacy, because it lets the server track the client 🙈 clients can manage their level of exposure by controlling the value of the client identifier, which trades stability of parameter allocation for privacy. we expect that guidance on this trade-off will be discussed in a future version of [DHCP-Anonymity].

additional security considerations are discussed in Section 10 of [RFC7597] and Section 9 of [RFC7596].

10.1. Port Randomization

preserving port randomization [RFC6056] may be harder, because the host can only randomize ports inside a fixed port range (see Section 13.4 of [RFC6269]) 🌈

more discussion on improving TCP's robustness against blind in-window attacks is in [RFC5961]. to protect against these attacks, means other than (IPv4) source port randomization should be used (for example, use [RFC5961] to improve TCP's robustness against blind in-window attacks, or use IPv6) 🦋

11. IANA Considerations 📋

IANA has assigned the following new DHCPv4 Option Code in the registry maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters/> 🎀

Option Name           Tag  Data   Meaning
                              Length
--------------------  ---  ------ -----------------------------------
OPTION_V4_PORTPARAMS  159  4      This option is used to configure a
                                    set of ports bound to a shared IPv4
                                    address.

12. References 📚

12.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, <http://www.rfc-editor.org/info/rfc2119>.

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

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

[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, February 2006, <http://www.rfc-editor.org/info/rfc4361>.

[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.

[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <http://www.rfc-editor.org/info/rfc7341>.

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.

12.2. Informative References

[DHCP-Anonymity] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity profile for DHCP clients", Work in Progress, draft-ietf-dhc-anonymity-profile-01, June 2015.

[DHCP-Port-Set-Opt] Sun, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, "Dynamic Host Configuration Protocol (DHCP) Option for Port Set Assignment", Work in Progress, draft-sun-dhc-port-set-option-02, October 2013.

[DHCPv4_v6-Shared-Addr] Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses using DHCPv4 over DHCPv6", Work in Progress, draft-farrer-dhc-shared-address-lease-00, June 2013.

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

[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, April 2009, <http://www.rfc-editor.org/info/rfc5508>.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.

[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.

[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.

[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <http://www.rfc-editor.org/info/rfc7598>.

Acknowledgements 🫶

This document is the result of merging [DHCP-Port-Set-Opt] and [DHCPv4_v6-Shared-Addr] 🌸

The authors would like to thank Peng Wu, Gabor Bajko, Teemu Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu, Marcin Siodelski, and Christian Huitema for their contributions 💖

Many thanks to Brian Haberman for the review 👑

Authors' Addresses 🎀

Yong Cui
Tsinghua University
Beijing  100084
China

Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun
Tsinghua University
Beijing  100084
China

Phone: +86-10-62785822
Email: sunqi.ietf@gmail.com
Ian Farrer
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
Bonn, NRW  53227
Germany

Email: ian.farrer@telekom.de
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA  19103
United States

Email: yiu_lee@cable.comcast.com
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing  100035
China

Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
Mohamed Boucadair
France Telecom
Rennes  35000
France

Email: mohamed.boucadair@orange.com
📦 where this page comes from