One document matched: draft-fsc-softwire-dhcp4o6-saddr-opt-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes"?>
<rfc category="std" docName="draft-fsc-softwire-dhcp4o6-saddr-opt-02"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="DHCP 4o6 SADDR option">DHCPv4 over DHCPv6 Source Address Option</title>
<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="Qi Sun" initials="Q." surname="Sun">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>sunqi.csnet.thu@gmail.com</email>
</address>
</author>
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<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>
<date year="2015"/>
<area>Internet</area>
<workgroup>Softwire WG</workgroup>
<abstract>
<t>DHCPv4 over DHCPv6 <xref target="RFC7341"/> describes a mechanism for
dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over
DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and
deployment scenarios, the operator must learn the /128 IPv6 address that
the client will use as the source of IPv4-in-IPv6 tunnel. This address,
in conjunction with the IPv4 address and the Port Set ID allocated to
the DHCP 4o6 client are used to create a binding table entry in the
softwire tunnel concentrator. This memo defines two DHCPv6 options used
to communicate the source tunnel IPv6 address between the DHCP 4o6 client
and server. It is designed to work in conjunction with the IPv4 address
allocation process.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section anchor="Introduction" title="Introduction">
<t>Deterministic IPv4-over-IPv6 transition technologies require
that elements are pre-configured with binding rules for routing traffic
to clients. This places a constraint on the location of the
client's tunnel endpoint: The tunnel endpoint has to be a pre-determined
prefix which is usually be configured on the home gateway device.
<xref target="I-D.ietf-softwire-map-dhcp"/> describes a DHCPv6
based mechanism for provisioning such deterministic softwires.</t>
<t>If a dynamic provisioning model is used, such as using DHCPv4
over DHCPv6, then pre-configuation of the softwire elements is
not possible and client rules must be created/deleted in line
with the allocation of IPv4 addresses to clients. This has the
benefit of removing the fixed address constraint for the client's
tunnel endpoint, as the address that the client will use can be
learnt when the tunnel is provisioned. The operator's tunnel
concentrator(s) can then be configured with the binding rule.</t>
<t>This document describes a mechanism for informing the service provider of
the binding between the dynamically allocated IPv4 address and Port Set ID
(learnt through DHCPv4 over DHCPv6) and the IPv6 address that the
softwire Initiator will use for accessing IPv4-over-IPv6 services.
It is used with DHCPv4 over DHCPv6 <xref target="RFC7341"/>
message flows to communicate the binding over the IPv6-only network.
The service provider can then use this binding information to provision
other functional elements in their network accordingly, e.g. using
the client's binding information to synchronise the binding table
in the border router.</t>
<t>The mechanism allows much more flexibility in the location of the
IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically
signalled back to the service provider. The DHCP 4o6 client and tunnel
client could be run on end devices attached to any routable IPv6 prefix
allocated to an end-user, located anywhere within an arbitrary home
network topology.</t>
</section>
<section title="Applicability">
<t>The mechanism described in this document is only suitable for use for
provisioning softwire clients via DHCP 4o6. The options described here are only
applicable within the DHCP 4o6 message exchange process. Current
mechanisms suitable for extending to incorporate DHCPv4 over DHCPv6
with dynamic IPv4 address leasing include
<xref target="I-D.ietf-softwire-map"/> and
<xref target="I-D.ietf-softwire-lw4over6"/>.</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">RFC 2119</xref>.</t>
</section>
<section title="Solution Overview">
<t>The solution in this document is intended for the dynamic establishment
of IPv4-over-IPv6 softwires. DHCP 4o6 <xref target="RFC7341"/> supports
dynamically allocating (shared) IPv4 address. For a softwire to be successfully
created, the IPv4 address has to be linked to the client's IPv6 tunnel source
address. Within this process, the DHCP 4o6 client uses a
DHCPv6 option to signal its tunnel source IPv6 address to the DHCP
4o6 server so that the operator's provisioning system can create the binding
and configure the tunnel concentrator accordingly.</t>
<t>Two new DHCPv6 options are defined in this memo: OPTION_DHCP4O6_SADDR_HINT
and OPTION_DHCP4O6_SADDR. They are intended to be used alongside the
normal DHCPv4 IPv4 address allocation message flow in the context of
DHCPv4 over DHCPv6 <xref target="RFC7341"/>. If a DHCP 4o6 client supports
this mechanism, it MUST include the code of OPTION_DHCP4O6_SADDR_HINT
in the Option Request Option (ORO) <xref target="RFC3315"/> when requesting
IPv4 configuration through DHCP 4o6.</t>
<!--
[Qi] NOTE: The 'MUST' for OPTION_DHCP4O6_SADDR_HINT is because that
RFC 3315 states that servers don't send options that the clients did not
request in the ORO.
-->
<t>The communication of parameters between the client and server is a
two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by
the DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for
binding the received IPv4 configuration and sourcing tunnel traffic.
This may be necessary if there are multiple IPv6 prefixes in use in the
customer network (e.g. ULAs), or if the specific IPv4-over-IPv6 transition
mechanism requires the use of a particular prefix for any reason. When the client
has selected an IPv6 address to bind the IPv4 configuration to, it passes
the address back to the DHCP 4o6 server through OPTION_DHCP4O6_SADDR.
</t>
<t>A softwire initiator also requires the IPv6 address of the border router
(i.e. softwire tunnel concentrator). In the dynamic mode, it SHOULD acquire
an IPv6 prefix of the BR through OPTION_BR_PREFIX. Then the /128 border router
address is constructed in the same manner as described in
<xref target="I-D.ietf-softwire-map"/>, by concatenating
the OPTION_BR_PREFIX with IPv4 address and PSID.
</t>
<!--[Qi] I'm not sure how to handle this. The OPTION_BR_PREFIX is not
required for signalling back client's IPv6 address, but for dynamic
mode as a whole. Currently, we put the usage of this option here, similar
to the previous version with container.
[if] Now that I read this here, I think that this is the wrong
document, but it will do for this update. Once multi endpoints and
the dynamic provision arch docs are updated, then we should have a
better idea of the right place.
-->
<t>To configure a softwire with DHCP 4o6, the DHCP client requests the
4o6 Server Address option using DHCPv6. If the DHCPv6 server includes
the DHCP 4o6 Server Address option in its response, then DHCPv4
over DHCPv6 can be enabled, as in <xref target="RFC7341"/>. If the
IPv6 source address of the client changes (such as IPv6 lease expiration,
etc.), the client follows the Section 9 of <xref target="RFC7341"/> to
re-enable the DHCPv4-over-DHCPv6 function.</t>
</section>
<section title="IPv6/IPv4 Binding Message Flow">
<t>The following diagram shows the client/server message flow and how
the options defined in this document are used. In each step, the
relevant DHCPv4 message is given above the arrow and the relevant
options below the arrow. The DHCPv4 messages are encapsulated in
DHCPv4-query or DHCPv4-response messages, and those options are included
in the 'options' field of the DHCPv4-query or DHCPv4-response message.</t>
<figure title="IPv6/IPv4 Binding Message Flow">
<artwork align="center"><![CDATA[
DHCP 4o6 DHCP 4o6
Client Server
| DHCPDISCOVER (DHCPv4) |
Step 1 |----------------------------------------------------->|
| ORO with OPTION_BR_PREFIX, |
| OPTION_DHCP4O6_SADDR_HINT(DHCPv6) |
| |
| DHCPOFFER (DHCPv4) |
Step 2 |<-----------------------------------------------------|
| OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT |
| (cipv6-prefix-hint with service provider's |
| preferred prefix) (DHCPv6) |
| |
| DHCPREQUEST (DHCPv4) |
Step 3 |----------------------------------------------------->|
| OPTION_BR_PREFIX, |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with |
| client's bound /128 IPv6 address) (DHCPv6) |
| |
| DHCPACK (DHCPv4) |
Step 4 |<-----------------------------------------------------|
| OPTION_BR_PREFIX, |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with |
| client's bound /128 IPv6 prefix) (DHCPv6) |
| |
]]></artwork>
</figure>
<t>A client attempting dynamic softwire configuration includes the
option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the
DHCPv6 ORO in all DHCPv4-query messages it sends.</t>
<t>When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD include
an OPTION_BR_PREFIX. It MAY also include OPTION_DHCP4O6_SADDR_HINT, which is
used to indicate a preferred prefix that the client should use to bind IPv4
configuration to. If this option is received, the client MUST perform a
longest prefix match between cipv6-prefix-hint and all prefixes/addresses
in use on the device. If a match is found, the selected prefix MUST then be
used to bind the received IPv4 configuration to. If the client
doesn't receive OPTION_DHCP4O6_SADDR_HINT the client
can select any valid /128 IPv6 prefix to use.</t>
<!--[if] I've removed ', or the matching fails,' as I can't see a case
where an LP match can fail. Well, one - if the client did not have any
globally scoped prefixes and the SADDR_HINT contained a prefix of global
scope. However, if this is the case, then the client only has link-local
addresses in use and so selecting any address is useless anyway -->
<!--[Qi] Agreed. See your point. In theory, I think it could happen, i.e. the prefix
in HINT is completely different from the global prefix(es) client is using.
But in an operator's netowrk, it is not reality. -->
<t>OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 Server
which IPv6 address the IPv4 configuration has been bound to. The client MUST
put the selected IPv6 address into this option and include it
in the DHCPv4-response message when it sends the DHCPREQUEST message.</t>
</section>
<section title="DHCPv6 Options">
<section title="DHCPv4 over DHCPv6 Source Address Hint Option">
<t></t>
<figure>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DHCP4O6_SADDR_HINT | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|cipv6-hintlen | |
+-+-+-+-+-+-+-+-+ cipv6-prefix-hint .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1)</t>
<t>option-length: 1 + length of cipv6-prefix-hint, specified in bytes.</t>
<t>cipv6-hintlen: 8-bit field expressing the bit mask length of the
IPv6 prefix specified in cipv6-prefix-hint.</t>
<t>cipv6-prefix-hint: The IPv6 prefix indicating the preferred
prefix for the client to bind the received IPv4 configuration
to.</t>
</list>
</t>
</section>
<section title="DHCPv4 over DHCPv6 Source Address Option">
<t>The format of DHCPv4 over DHCPv6 Source address option is defined
as follows:</t>
<figure>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DHCP4O6_SADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ cipv6-src-address +
. (128 bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_DHCP4O6_SADDR (TBA2)</t>
<t>option-length: 16.</t>
<t>cipv6-src-address: The IPv6 address that the client has bound
the allocated IPv4 configuration to.</t>
</list>
</t>
</section>
<section title="Border Router Prefix Option">
<t>The format of Border Router Prefix option is defined as follows:</t>
<figure>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_BR_PREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|br-prefix6-len | |
+-+-+-+-+-+-+-+-+ br-ipv6-prefix +
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>ooption-code: OPTION_BR_PREFIX (TBA3)</t>
<t>option-length: 1 + length of br-ipv6-prefix specified in bytes.</t>
<t>br-prefix6-len: 8 bits long field expressing the length of the IPv6
prefix specified in the br-ipv6-prefix field.</t>
<t>br-ipv6-prefix: a variable length field specifying the IPv6 address
or prefix for the border router. It SHOULD be /64 or /128.</t>
</list>
</t>
<t>This option provisions the softwire initiator with an IPv6 prefix of BR.
If the prefix length is /128, the softwire initiator takes this /128 IPv6
address as the BR's tunnel endpoint address. If the prefix length is /64,
the softwire initiator MUST create the BR's /128 tunnel endpoint address
by concatenating that prefix, its IPv4 address and PSID. This is similar
to the initiator creating its own IPv6 tunnel endpoint address
<xref target="I-D.ietf-softwire-map"/>.</t>
<figure>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix from the OPTION_BR_PREFIX |
| (64-bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero Padding | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Addr cont. | PSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>Prefix from the OPTION_BR_PREFIX: The IPv6 prefix got from
the OPTION_BR_PREFIX.</t>
<t>Padding: Padding (all zeros).</t>
<t>IPv4 Address: Public IPv4 address allocated to the client</t>
<t>PSID: Port Set ID allocated to the client, left padded with
zeros to 16-bits. If no PSID is provisioned, all zeros.</t>
</list>
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to allocate the DHCPv6 option codes:
OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and OPTION_BR_PREFIX.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ted Lemon and Lishan Li for their
contributions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.7341'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-lw4over6'?>
<?rfc include='reference.I-D.ietf-softwire-map-dhcp'?>
<?rfc include='reference.I-D.farrer-softwire-br-multiendpoints'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:42:40 |