DHCPv4 over DHCPv6 Source Address OptionDeutsche Telekom AGCTO-ATI, Landgrabenweg 151BonnNRW53227Germanyian.farrer@telekom.deTsinghua UniversityBeijing100084P.R. China+86-10-6278-5822sunqi.csnet.thu@gmail.comTsinghua UniversityBeijing100084P.R. China+86-10-6260-3059yong@csnet1.cs.tsinghua.edu.cnTsinghua UniversityBeijing100084P.R. China+86-10-6278-5822lh.sunlinh@gmail.com
Internet
DHCWGDHCPv4 over DHCPv6 is 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 needs to know the IPv6
address that the client will use as the source of IPv4-in-IPv6
softwire tunnel. This address, in conjunction with the client's
IPv4 address and (in some deployments), the Port Set ID are
used to create a binding table entry in the operator's softwire
tunnel concentrator. This memo defines a DHCPv6 option to convey
IPv6 parameters for establishing the softwire tunnel and a
DHCPv4 option (to be used only with DHCP 4o6) 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. This document updates
"DHCPv6 Options for Configuration of Softwire Address and
Port-Mapped Clients" to allow the DHCPv6 option
OPTION_S46_BR (90) to appear outside of DHCPv6 softwire container
options.
This document updates RFC7598, allowing
OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's
ORO request and appear directly within subsequent messages
sent by the DHCPv6 server.
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 choice of
address used as the client's softwire source address: it must
use a pre-determined prefix which is usually
configured on the home gateway device.
describes a DHCPv6 based mechanism for provisioning such
deterministic softwires.
A dynamic provisioning model, such as using DHCPv4
over DHCPv6 (DHCP 4o6) allows much more
flexibility in the location of the IPv4-over-IPv6 softwire source
address. In this model, the IPv6 address is dynamically
communicated back to the service provider allowing the
corresponding softwire configuration to be created in the border
router (BR).
The DHCP 4o6 client and softwire 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. Dynamic
allocation also helps to optimize IPv4 resource usage as only clients
which are actively renewing their IPv4 lease hold on to the address.
This document describes a mechanism for dynamically provisioning
softwires created using DHCP 4o6, including provisioning the
client with the address of the softwire border router (BR) and
informing the service provider of client's binding between
the dynamically allocated IPv4 address and Port Set ID
and the IPv6 address that the softwire Initiator will use for
accessing IPv4-over-IPv6 services.
The mechanism operates alongside the DHCP 4o6 message flows to
communicate the binding information over the IPv6-only network.
The DHCP 4o6 server provides a single point in the network
which holds the current client binding information. The service
provider can then use this binding information to provision
other functional elements, such as the BR(s).
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 softwire technologies suitable for extending to incorporate
DHCP 4o6 with dynamic IPv4 address leasing include
and .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 RFC 2119.In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options carried inside the DHCPv6 message
DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is
used to provision the remote IPv6 address for the softwire
(see below).
OPTION_S46_BIND_IPV6_PREFIX (TBD1), is optionally sent 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.
IPv4 configuration is carried in DHCPv4 messages (inside
the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in .
In order for the client to communicate the softwire source
address, a new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is
defined in this document. This is included in DHCPREQUEST
messages sent by the client and is stored by the server for the
lifetime of the IPv4 address lease.
Section 4.2 of defines option
OPTION_S46_BR(90) for communicating remote softwire border
relay (BR)'s' IPv6 address(es) to a client, but mandates that
the option can only be used when encapsulated within one of
the softwire container options: OPTION_S46_CONT_MAPE (94) or
OPTION_S46_CONT_LW(96). From Section 3 of
:
"Softwire46 DHCPv6 clients that receive provisioning options that
are not encapsulated in container options MUST silently ignore these
options."This document updates , removing
this restriction for OPTION_S46_BR (90), allowing it to be
enumerated in the client's ORO request and appear directly
within subsequent messages sent by the DHCPv6 server.
The following diagram shows the relevant extensions to the
successful DHCP 4o6 IPv4 allocation client/server message flow for
the softwire source address function. The full process, including
error handling is described in .
In each step, the DHCPv6 portion of the message and any relevant
option is shown above the arrow. The DHCP 4o6 content of the
message and its relevant options are below the arrow. All the
DHCPv4 messages are encapsulated in DHCPV4-QUERY (20) or
DHCPV4-RESPONSE (21) messages. Where relevant, the necessary
options and their contents are shown.
The client constructs a DHCPv6
'DHCPV4-QUERY(20)' message. This message contains two
options: DHCPv6 OPTION_ORO (6) and OPTION_DHCPV4_MSG (87).
OPTION_ORO lists '90' (OPTION_S46_BR) and 'TBD1'
(OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG contains a
DHCPv4 DHCPDISCOVER message.
The server responds with a DHCPv6
'DHCPV4-RESPONSE (21)' message. This message contains
OPTION_S46_BR (90) containing the IPv6 address of the BR for
the client's softwire configuration. The message may also,
optionally contain OPTION_S46_BIND_IPV6_PREFIX (TBD1).
OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message.
The client sends with a DHCPv6
'DHCPV4-QUERY(20)' message containing a DHCPv4 DHCPREQUEST
message with OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6
address which the client will use as its softwire source
address.
The server sends a DHCPv6
'DHCPV4-RESPONSE(21)' message. OPTION_DHCPV4_MSG contains a
DHCPv4 DHCPACK message. OPTION_DHCP4O6_S46_SADDR with
the client's softwire source address is included.
The format of DHCPv6 Source Binding Prefix hint option is as
follows:option-code: OPTION_S46_BIND_IPV6_PREFIX (TBD1)option-length: 1 + length of bind-ipv6-prefix, specified
in bytes.
bindprefix6-len: 8-bit field expressing the bit mask length
of the IPv6 prefix specified in bind-ipv6-prefix. Valid
values are 0 to 128.
bind-ipv6-prefix: The IPv6 prefix indicating the preferred
prefix for the client to bind the received IPv4 configuration
to. The length is (bindprefix6-len + 7) / 8. The field is
padded on the right with zero bits up to the next octet
boundary when bind-ipv6-prefix is not evenly divisible by
8.
OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT
send more than one instance of the OPTION_S46_BIND_IPV6_PREFIX
option.
The format of DHCPv4 over DHCPv6 softwire source address
option is as follows:option-code: OPTION_DHCP4O6_S46_SADDR (TBD2)option-length: 16.softwire-ipv6-src-address: 16 bytes long; The IPv6
address that is associated (either being requested
for binding or currently bound) with the client's IPv4
configuration.
NB - The function of OPTION_DHCP4O6_S46_SADDR may
seem similar to the DHCPv4 message's 'chaddr' field, or the
Client Identifier (61) option in that it provides a lower-layer
address which is unique that the server can use for identifying
the client. However, as both of these are required to remain
constant throughout the address lease lifetime, they cannot be
used with the mechanism described in this document. This is
because the client may only be able to construct the IPv6
address to use as the source address after it has received the
first DHCPV4-RESPONSE message from the server containing
OPTION_S46_BIND_IPV6_PREFIX.
A client requiring dynamic softwire configuration first enables
DHCP 4o6 configuration using the method described in Section 5.
of . If OPTION_DHCP4_O_DHCP6_SERVER is
received in the corresponding REPLY message, the client MAY
continue with the configuration process described below.
It is also a prerequisite that the client has already learned
a suitable IPv6 prefix to use for its local softwire endpoint
using DHCPv6, RA/PIO or another mechanism.
When constructing the initial DHCP 4o6 DHCPDISCOVER message,
the client includes a DHCPv6 OPTION_ORO (6) within the options
field of the DHCP-QUERY message. OPTION_ORO contains the option
codes for OPTION_S46_BR (90) and
OPTION_S46_BIND_IPV6_PREFIX (TBD1).
On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE
containing a DHCPOFFER message), the client checks
the contents of the DHCPv4-RESPONSE for the presence of a valid
OPTION_S46_BR option. If this option is not present, or does not
contain at least one valid IPv6 address for a BR, then the client
MUST discard the message, as without the address of the BR the
client cannot configure the softwire and so has no interface to
request IPv4 configuration for.
The DHCPV4-RESPONSE message may also include
OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator
to indicate a preferred prefix that the client should use to
bind IPv4 configuration to. If received, the client first
checks the option according to . If
valid, the client uses this prefix as the 'IPv6 binding prefix'
and follows to the process described in Section 5.1
of in order to select an active IPv6
prefix to construct the softwire. If no match is found,
or the client doesn't receive OPTION_S46_BIND_IPV6_PREFIX the
client MAY select any valid IPv6 prefix (of a suitable scope)
to use as the tunnel source.
Once the client has selected a suitable prefix, it MAY
use either an existing IPv6 address that is already configured
on an interface, or create a new address specifically for use
as the softwire source address (e.g. using an Interface
Identifier constructed as per Section 6. of
). If a new address is being created,
the client MUST complete configuration of the new address,
performing duplicate address detection (if required) before
proceeding.
The client then constructs a DHCPV4-QUERY message containing
a DHCPv4 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is
included in the options field of the DHCPREQUEST message
with the IPv6 address of its softwire source address in the
softwire-ipv6-src-address field.
When the client receives a DHCPv4 DHCPACK message from the
server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR
against its active softwire source address. If they match,
the allocation process has concluded. If there is a discrepancy
then the process described in
is followed.
If the client receives a DHCPv4 DHCPNAK message from
the server, then the configuration process has been unsuccessful.
The client then restarts the process from Step 1 of
.
Whenever the client attempts to extend the lease time
of the IPv4 address, OPTION_DHCP4O6_S46_SADDR with the IPv6
address of its softwire source address in the
softwire-ipv6-src-address field MUST be included in the DHCPREQUEST
message.
Across the lifetime of the leased IPv4 address, it is possible
that the client's IPv6 will change. E.g. if there is a flash
IPv6 re-numbering event.
In this situation, the client MUST inform the server of the
new address. This is done by sending a DHCPREQUEST message
containing OPTION_DHCP4O6_S46_SADDR with the new IPv6
source address.
When the client receives a DHCPv4 DHCPACK message from the
server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR
against its active softwire source address. If they match,
the allocation process has concluded. If there is a discrepancy
then the process described in
is followed.
If the client receives a DHCPv4 DHCPNAK message in repsonse
from the server, then the change of the bound IPv6 Softwire
source address has been unsuccessful. In this case, the client
MUST stop using the new IPv6 source address. The client then
restarts the process from Step 1 of .
When the client no longer requires the IPv4 resource, it
sends a DHCPv4 DHCPRELEASE message to the server. As the
options field is unused in this message type, OPTION_DHCP4O6_S46_SADDR
is not included.
On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the
client makes the following validation checks:
The received bindprefix6-len value is not larger than 128.
The received bindprefix6-len value is not larger than the number
of bytes sent in the bind-ipv6-prefix field. (e.g. the
bindprefix6-len is 128 but the bind-ipv6-prefix has only 8 bytes).
For either of these cases the receiver MAY either discard the
option and proceed to attempt configuration as if the option had
not been received, or attempt to use the received values for the
longest prefix match anyway.
The receiver MUST only use bits from the bind-ipv6-prefix field up
to the value specified in the bindprefix6-len when performing the
longest prefix match. bind-ipv6-prefix bits beyond this value
MUST be ignored.
If the client receives a DHCPACK message with an
OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which
differs from its active softwire source address, the client
MAY either:Wait for a randomised time interval and then resend a
DHCPREQUEST message with the correct softwire source
address, OR
Send a DHCPRELEASE message and re-start the process
described in .
describes a mechanism for using DHCPv4
to distribute dynamic, shared IPv4 addresses to clients. The
mechanism described in this document is compatible with IPv4
address sharing, and can be enabled by following the
process described in Section 6 of .
Beyond the normal DHCP 4o6 functionality defined in
, the server MUST also store the IPv6
softwire source address of the client in the leasing address
database, alongside the IPv4 address and client identifier.
An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source
address MUST be sent in every DHCPACK message sent by the
server.
The binding entry between the client's IPv6 softwire source
address and the leased IPv4 address is valid as long as the IPv4
lease remains valid.
In the event that the server receives a DHCPREQUEST message
for an active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR
with an IPv6 address which differs from the address which
is currently stored, the server updates the stored softwire
source address with the new address supplied by the client,
and sends a DHCPACK message containing the updated softwire
source address in OPTION_DHCP4O6_S46_SADDR.
The server MAY implement a policy enforcing a minimum time
interval between a client updating its softwire source
IPv6 address. If a client attempts to update the softwire
source IPv6 address before the minimum time has expired,
the server can either silently drop the client's
message or send back a DHCPACK message containing the
exisiting IPv6 address binding in
OPTION_DHCP4O6_S46_SADDR.
Security considerations which are applicable to
are also applicable here.IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR option code from the
"BOOTP Vendor Extensions and DHCP Options" registry maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters.IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX option code from the
DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters.
The authors would like to thank Ted Lemon, Lishan Li, Tatuya
Jinmei, Jonas Gorski and Razvan Becheriu for their contributions
and comments.