One document matched: draft-ietf-dhc-dynamic-shared-v4allocation-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc2131 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc2132 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml">
<!ENTITY rfc4361 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml">
<!ENTITY rfc5508 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY rfc5961 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
<!ENTITY rfc6056 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY rfc6335 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY rfc6346 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6346.xml">
<!ENTITY rfc6269 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY rfc3927 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml">
<!ENTITY rfc7341 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7341.xml">
]>
<rfc category="std" docName="draft-ietf-dhc-dynamic-shared-v4allocation-09"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Dynamic Shared IPv4 Allocation">Dynamic Allocation of
Shared IPv4 Addresses</title>
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6260-3059</phone>
<email>yong@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Qi Sun" initials="Q.S" surname="Sun">
<organization>Tsinghua University</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>sunqi@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I.F" surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>CTO-ATI, Landgrabenweg 151</street>
<city>Bonn</city>
<region>NRW</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<author fullname="Yiu L. Lee" initials="Y.L" surname="Lee">
<organization>Comcast</organization>
<address>
<postal>
<street>One Comcast Center</street>
<city>Philadelphia</city>
<code>PA 19103</code>
<country>USA</country>
</postal>
<phone></phone>
<email>yiu_lee@cable.comcast.com</email>
</address>
</author>
<author fullname="Qiong Sun" initials="Q.S" surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street>Room 708, No.118, Xizhimennei Street</street>
<city>Beijing</city>
<code>100035</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M.B" surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<phone></phone>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date year="2015" />
<area>Internet</area>
<workgroup>DHC WG</workgroup>
<abstract>
<t>This memo describes the dynamic allocation of shared IPv4 addresses
to clients using DHCPv4. Address sharing allows a single IPv4 address to
be allocated to multiple active clients simultaneously, each client
being differentiated by a unique set of transport layer source port
numbers. The necessary changes to existing DHCPv4 client and server
behavior are described and a new DHCPv4 option for provisioning clients
with shared IPv4 addresses is included.</t>
<t>Due to the nature of IP address sharing, some limitations to its
applicability are necessary. This memo describes these limitations and
recommends suitable architectures and technologies where address sharing
may be utilized.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section anchor="Introduction" title="Introduction">
<t>The shortage of available public IPv4 addresses means that it is not
always possible for operators to allocate a full IPv4 address to every
connected device. This problem is particularly acute whilst an operator
is migrating from their existing, native IPv4 network to a native IPv6
network with IPv4 provided as an overlay service. During this phase,
public IPv4 addresses are needed to provide for both existing and
transition networks.</t>
<t>Two main types of solutions have emerged to address the problem (see
Appendix A of <xref target="RFC6269"></xref>):</t>
<t><list style="numbers">
<t>Deploying Carrier Grade Network Address Translation devices
(CGNAT, <xref target="RFC6888"></xref>).</t>
<t>Distributing the same public IPv4 address to multiple clients
differentiated by non-overlapping layer 4 port sets.</t>
</list></t>
<t>This memo focuses on the second category of solutions.</t>
<t><xref target="RFC7341"></xref> introduces a "DHCP 4o6 Server", which
offers dynamic leasing for IPv4 addresses to clients as in DHCPv4 <xref
target="RFC2131"></xref> but transported within a DHCPv6 message flow.
This memo specifies a new DHCPv4 option: OPTION_V4_PORTPARAMS, and
describes how it can be used for the dynamic leasing of shared IPv4
addresses.</t>
<t>Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4
transport mechanism throughout this document, OPTION_V4_PORTPARAMS as a
DHCPv4 option may also be used in other solutions, if required.</t>
</section>
<section anchor="aps" title="Applicability Statement ">
<t>The solution allows multiple hosts to be simultaneously allocated the
same IP address. As the IP address is no longer a unique identifier for
a host, this extension is only suitable for specific architectures based
on the Address plus Port model (A+P) <xref target="RFC6346"></xref>.
Specifically, this document presents a solution that applies to <xref
target="I-D.ietf-softwire-lw4over6"></xref> and certain configurations
of <xref target="I-D.ietf-softwire-map"></xref> (e.g., EA-bit length set
to 0).</t>
<t>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, including Ethernet, WLAN, cable, etc..</t>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms: <list hangIndent="22"
style="hanging">
<t hangText="Shared IPv4 address:">An IPv4 address with a restricted
layer 4 port set.</t>
<t hangText="Port Set ID (PSID):">Identifier for a range of ports
assigned to a DHCP client.</t>
</list></t>
</section>
<section title="Functional Overview">
<t>Functionally, the dynamic allocation of shared IPv4 addresses by the
DHCP 4o6 Server is similar to the dynamic allocation process for 'full'
IPv4 addresses described in <xref target="RFC2131"></xref>. The
essential difference is that the DHCP 4o6 Server can allocate the same
IPv4 address to more than one DHCP 4o6 client simultaneously, providing
that each shared address allocation also includes a range of layer 4
source ports unique to that address (i.e., the combined tuple of IPv4
address and Port Set ID is to be unique for each active lease).</t>
<t>The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described
below), which is a DHCPv4 option containing PSID (Port Set ID)
information. The client includes this option within the Parameter
Request List option <xref target="RFC2132"></xref> in its DHCPv4
DHCPDISCOVER and DHCPREQUEST messages, indicating its support for
shared, dynamic address leasing to the DHCP 4o6 server.</t>
<t>OPTION_V4_PORTPARAMS is also implemented by the server to identify
clients that support shared, dynamic address leasing. With this option,
the server can dynamically allocate PSIDs to clients and maintain shared
IPv4 address leases. The server then manages unique client leases based
the IPv4 address and PSID tuple, instead of using only the IPv4
address.</t>
<t>In the event that a dynamic, shared addressing capable client
receives more than one DHCP 4o6 offer, where a received offer does not
contain OPTION_V4_PORTPARAMS (i.e., is an offer for a full IPv4
address), then the client SHOULD prefer the full IPv4 offer over the
shared IPv4 address offer(s), unless specifically configured
otherwise.</t>
</section>
<section title="Client-Server Interaction">
<t>The following DHCPv4 message flow is transported within the
DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6 <xref
target="RFC7341"></xref>.</t>
<t><list style="numbers">
<t>When the client constructs the DHCPv4 DHCPDISCOVER message to be
transported within the DHCPv4-query message, the DHCPDISCOVER
message MUST include the client identifier option (constructed as
per <xref target="RFC4361"></xref>) and the Parameter Request List
(PRL) option with the code of 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.</t>
<t>DHCP 4o6 Servers that receive the DHCPDISCOVER message and
support shared IPv4 addresses respond with a DHCPOFFER message with
the shared IPv4 address in the 'yiaddr' field and MUST add an
OPTION_V4_PORTPARAMS option containing an available restricted port
set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS option
containing 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). The DHCPOFFER message is then encapsulated in the
DHCPv4-response message and sent to the client.</t>
<t>The client evaluates all received DHCPOFFER messages and selects
one (e.g., based on the configuration parameters received, such as
the size of the offered port set). The client then sends a
DHCPREQUEST encapsulated in the DHCPv4-query message containing the
corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER
message.</t>
<t>The server identified in the DHCPREQUEST message creates a
binding for the client. The binding includes the client identifier,
the IPv4 address and the PSID. These parameters are used by both the
server and the client to identify a lease in any DHCP message. The
server MUST respond with a DHCPACK message containing
OPTION_V4_PORTPARAMS for the requesting client.</t>
<t>On receipt of the DHCPACK message with the configuration
parameters, the client MUST NOT perform an in-use probe on the
address, such as ARPing for a duplicate allocated address.</t>
<t>If the client chooses to relinquish its lease by sending a
DHCPRELEASE message, the client MUST include the leased network
address and OPTION_V4_PORTPARAMS (with the allocated PSID) to
identify the lease to be released.</t>
</list></t>
<t>In the case that the client has stored the previously allocated
address and restricted port set, the logic described in Section 3.2 of
<xref target="RFC2131"></xref> MUST be followed on the condition that
the client's source IPv6 address for DHCP 4o6 does not change. Note,
this corresponds to the INIT-REBOOT state defined in <xref
target="RFC2131"></xref>. The client MUST include the
OPTION_V4_PORTPARAMS with the requested port set information in the
message flow, which starts with a DHCPREQUEST message. If the client's
DHCP 4o6 IPv6 source address is changed for any reason, the client MUST
re-initiate the DHCP 4o6 shared-address provisioning process by sending
a DHCPDISCOVER message.</t>
</section>
<section anchor="client" title="Client Behavior">
<t>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 has been successfully
allocated an IPv4 address and PSID previously, the client's DHCPDISCOVER
message MAY include the 'requested IP address' option along with an
OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID be
re-assigned. Alternatively, the client MAY omit the 'requested IP
address' option, but include an OPTION_V4_PORTPARAMS with a non-zero
value in only the PSID-Len field, as a hint to the server for the
preferred size of the port set.</t>
<t>A client that requests OPTION_V4_PORTPARAMS, but receives DHCPOFFER
and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as
defined in <xref target="RFC7341"></xref> and configure a full IPv4
address with no address sharing (see <xref target="shnsh"></xref> for
the server's behavior).</t>
<t>When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the
client MUST use the received explicit PSID for configuring the interface
for which the DHCP 4o6 request was made.</t>
<t>The client MUST NOT probe a newly received IPv4 address (e.g., using
ARP) to see if it is in use by another host.</t>
<t>When the client renews or releases its DHCP lease, it MUST put the
values of offset, PSID length and PSID into OPTION_V4_PORTPARAMS, and
send it to the server within corresponding DHCPv4 messages that are
conveyed through DHCPv4-query message.</t>
<t>In the event that the client's DHCP 4o6 IPv6 source address is
changed for any reason, the client MUST re-initiate the DHCP 4o6
shared-address provisioning process by sending a DHCPDISCOVER
message.</t>
<section title="Restrictions to Client Usage of a Shared IPv4 Address">
<t>As a single IPv4 address is being shared between a number of
different clients, the allocated shared address is only suitable for
certain uses. The client MUST implement a function to ensure that only
the allocated layer 4 ports of the shared IPv4 address are used for
sourcing new connections, or accepting inbound connections.</t>
<t>The client MUST apply the following rules for all traffic destined
to or originating from the shared IPv4 address:</t>
<t><list style="symbols">
<t>The client MUST use only port-aware protocols (e.g., TCP, UDP,
DCCP etc.) or ICMP implementing <xref
target="RFC5508"></xref>.</t>
<t>All connections originating from the shared IPv4 address MUST
use a source port taken from the allocated restricted port
set.</t>
<t>The client MUST NOT accept inbound connections on ports outside
of the allocated restricted port set.</t>
</list></t>
<t>In order to prevent addressing conflicts which could arise from the
allocation of the same IPv4 address, the client MUST NOT use the
received restricted IPv4 address to perform ARP operations.</t>
<t>The mechanism by which a client implements the above rules is out
of the scope of this document.</t>
<t>In the event that the DHCPv4 over DHCPv6 configuration mechanism
fails for any reason, the client MUST NOT configure an IPv4 link-local
address <xref target="RFC3927"></xref> (taken from the 169.254.0.0/16
range).</t>
</section>
</section>
<section title="Server Behavior">
<t>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) <xref target="RFC2132"></xref>.</t>
<t>The DHCP 4o6 Server SHOULD reply with OPTION_V4_PORTPARAMS if the
client includes OPTION_V4_PORTPARAMS in its Parameter Request List. In
order to achieve the dynamic management of shared IPv4 addresses, the
server is required to implement an address and port-set pool that
provides the same function as the address pool in a regular DHCP server.
Also, the server uses the combination of address and PSID as the key for
maintaining the state of a lease, and for searching for an available
lease for assignment. The leasing database is required to include the
IPv4 address, PSID and client identifier of the requesting client.</t>
<t>When a server receives a DHCPDISCOVER message with
OPTION_V4_PORTPARAMS in the Parameter Request List option, the server
determines 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 select which specific address and PSID to provision to
the client. The logic is similar to that in Section 4.3.1 of <xref
target="RFC2131"></xref>.</t>
<t><list style="symbols">
<t>The client's current address with the PSID as recorded in the
client's current lease binding, ELSE</t>
<t>The client's previous address with 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</t>
<t>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</t>
<t>A new address with a PSID allocated from the server's pool of
available addresses and PSIDs.</t>
</list></t>
<t>Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, 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 a record (matching that PSID) is maintained by
the server for that client.</t>
<t>The port-set assignment MUST be coupled with the address assignment
process. Therefore the server MUST assign the address and port set in
the same DHCP message.</t>
<t>When defining the pools of IPv4 addresses and PSIDs which 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.</t>
<section anchor="shnsh"
title="Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 4o6 Server">
<t>A single DHCP 4o6 server may serve clients that do not support
OPTION_V4_PORTPARAMS as well as those that do. As the rules for the
allocation of shared addresses differ from the rules for full IPv4
address assignment, the DHCP 4o6 server MUST implement a mechanism to
ensure that clients not supporting OPTION_V4_PORTPARAMS do not 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 have requested them.</t>
<t>If the server is only configured with address pools for shared
address allocation, it MUST discard requests that do not contain
OPTION_V4_PORTPARAMS in the Parameter Request List option.</t>
<t>A server configured with non-shared address pools can be instructed
to honor received requests that contain OPTION_V4_PORTPARAMS in the
Parameter Request List option (that is ignore OPTION_V4_PORTPARAMS and
serve the requesting clients with non-shared IPv4 addresses).</t>
</section>
</section>
<section title="DHCPv4 Port Parameters Option">
<t>The meaning of 'offset', 'PSID-len', and 'PSID' fields of the DHCPv4
Port Parameters Option is identical to that of 'offset', 'PSID-len', and
'PSID' fields of the S46 Port Parameters Option (Section 4.5 of <xref
target="I-D.ietf-softwire-map-dhcp"></xref>). The use of the same
encoding in both options is meant to ensure compatibility with existing
port set implementations.</t>
<t>The format of OPTION_V4_PORTPARAMS is shown in <xref
target="img-option-portparams"></xref>.</t>
<figure align="center" anchor="img-option-portparams"
title="DHCPv4 Port Parameters Option">
<preamble></preamble>
<artwork align="center"><![CDATA[
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_V4_PORTPARAMS (TBA)</t>
<t>option-len: 4</t>
<t>offset: (PSID offset) 8 bits long field that specifies the
numeric value for the excluded port range/offset bits (A-bits), as
per section 5.1 of <xref target="I-D.ietf-softwire-map"></xref>.
Allowed values are between 0 and 15, with the default value being 6
for MAP based implementations. This parameter is unused by a
Lightweight 4over6 client and should be set to 0.</t>
<t>PSID-len: Bit length value of the number of significant bits in
the PSID field (also known as 'k'). When set to 0, the PSID field is
to be ignored. After the first 'a' bits, there are k bits in the
port number representing the value of PSID. Subsequently, the
address sharing ratio would be 2^k.</t>
<t>PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value
algorithmically identifies a set of ports assigned to a client. The
first k-bits on the left of this 2-octets field is the PSID value.
The remaining (16-k) bits on the right are padding zeros.</t>
</list></t>
<t><xref target="I-D.ietf-softwire-map"></xref> Section 5.1 provides a
full description of how the PSID is interpreted by the client.</t>
<t>In order to exclude the system ports (<xref target="RFC6335"></xref>)
or ports reserved by ISPs, the former port-sets that contain well-known
ports MUST NOT be assigned unless the operator has explicitly configured
otherwise (e.g., by allocating a full IPv4 address).</t>
</section>
<section title="Security Considerations">
<t>The security considerations described in <xref
target="RFC2131"></xref> and <xref target="RFC7341"></xref> are also
potentially applicable to this solution. Unauthorised DHCP 4o6 servers
in the network could be used to stage an amplification attack or to
supply invalid configuration leading to service disruption. The risks of
these types of attacks can be reduced through the use of unicast DHCP
4o6 message flows (enabled by supplying DHCP 4o6 server unicast
addresses within the OPTION_DHCP4_O_DHCP6_SERVER option).</t>
<t>A malicious user could attempt a DoS attack by requesting a large
number ofIPv4 address (or fractional address) and port sets allocations,
exhausting the available addresses and port sets for other clients. This
can be mitigated through DHCP 4o6 address allocation policy, limiting
the number of simultaneously active IPv4 leases for clients whose
request originate from each customer site.</t>
<t>The purpose of the client identifier option is to ensure that the
same client retains the same parameters over time. This interferes with
the client's privacy, as it allows the server to track the client.
Clients can manage their privacy exposure by controlling the value of
the client identifier, trading off stability of parameter allocation for
privacy. We expect that guidance on this trade-off will be discussed in
a future version of <xref
target="I-D.ietf-dhc-anonymity-profile"></xref>.</t>
<t>Additional security considerations are discussed in Section 11 of
<xref target="I-D.ietf-softwire-map"></xref> and Section 9 of <xref
target="I-D.ietf-softwire-lw4over6"></xref>.</t>
<section title="Port Randomization">
<t>Preserving port randomization <xref target="RFC6056"></xref> may be
more difficult because the host can only randomize the ports inside a
fixed port range (see Section 13.4 of <xref
target="RFC6269"></xref>).</t>
<t>More discussion to improve the robustness of TCP against Blind
In-Window Attacks can be found at <xref target="RFC5961"></xref>.
Other means than the (IPv4) source port randomization to provide
protection against attacks should be used (e.g., use <xref
target="RFC5961"></xref> to improve the robustness of TCP against
Blind In-Window Attacks, use IPv6).</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign the following new DHCPv4 Option Code in
the registry maintained in:
http://www.iana.org/assignments/bootp-dhcp-parameters/:</t>
<texttable style="headers">
<ttcol align="right">Option Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Data length</ttcol>
<ttcol>Meaning</ttcol>
<c>OPTION_V4_PORTPARAMS</c>
<c>TBA</c>
<c>4</c>
<c>This option is used to configure a set of ports bound to a shared
IPv4 address.</c>
</texttable>
<t></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is merged from <xref
target="I-D.sun-dhc-port-set-option"></xref> and <xref
target="I-D.farrer-dhc-shared-address-lease"></xref>.</t>
<t>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.</t>
<t>Many thanks to Brian Haberman for the review.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-softwire-lw4over6"?>
<?rfc include='reference.RFC.7341'?>
<?rfc include='reference.RFC.6056'?>
<?rfc include='reference.RFC.5961'?>
<?rfc include='reference.RFC.4361'?>
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.2132'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.I-D.ietf-softwire-map'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-softwire-map-dhcp'?>
<?rfc include='reference.I-D.ietf-dhc-anonymity-profile'?>
<?rfc include='reference.RFC.6335'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.5508'?>
<?rfc include='reference.RFC.3927'?>
<?rfc include='reference.RFC.6346'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.I-D.sun-dhc-port-set-option'?>
<?rfc include='reference.I-D.farrer-dhc-shared-address-lease'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:40:19 |