draft-ietf-dhc-dhcp4o6-saddr-opt-04.txt   draft-ietf-dhc-dhcp4o6-saddr-opt-05.txt 
DHCWG I. Farrer DHCWG I. Farrer
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Updates: 7598 (if approved) Q. Sun Updates: 7598 (if approved) Q. Sun
Intended status: Standards Track Y. Cui Intended status: Standards Track Y. Cui
Expires: December 16, 2018 L. Sun Expires: April 5, 2019 L. Sun
Tsinghua University Tsinghua University
June 14, 2018 October 2, 2018
Softwire Provisioning using DHCPv4 Over DHCPv6 Softwire Provisioning using DHCPv4 Over DHCPv6
draft-ietf-dhc-dhcp4o6-saddr-opt-04 draft-ietf-dhc-dhcp4o6-saddr-opt-05
Abstract Abstract
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
to function with some IPv4-over-IPv6 softwire mechanisms and (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms
deployment scenarios, the operator needs to know the IPv6 address and deployment scenarios (e.g., RFC7596 or RFC7597), the operator
that the client will use as the source of IPv4-in-IPv6 softwire needs to know the IPv6 address that the client will use as the s
tunnel. This address, in conjunction with the client's IPv4 address, ource of IPv4-in-IPv6 softwire tunnel. This address, in conjunction
and (in some deployments) the Port Set ID are used to create a with the client's IPv4 address, and (in some deployments) the Port
binding table entry in the operator's softwire tunnel concentrator. Set ID are used to create a binding table entry in the operator's
This memo defines a DHCPv6 option to convey IPv6 parameters for softwire tunnel concentrator. This memo defines a DHCPv6 option to
establishing the softwire tunnel and a DHCPv4 option (to be used only convey IPv6 parameters for establishing the softwire tunnel and a
with DHCP 4o6) to communicate the source tunnel IPv6 address between DHCPv4 option (to be used only with DHCP 4o6) to communicate the
the DHCP 4o6 client and server. It is designed to work in source tunnel IPv6 address between the DHCP 4o6 client and server.
conjunction with the IPv4 address allocation process. It is designed to work in conjunction with the IPv4 address
allocation process.
This document updates "DHCPv6 Options for Configuration of Softwire DHCPv6 Options for Configuration of Softwire Address and Port-Mapped
Address and Port-Mapped Clients" (RFC7598), allowing OPTION_S46_BR Clients (RFC7598) describes a deterministic DHCPv6 based mechanism
(90) to be enumerated in the DHCPv6 client's ORO request and appear for provisioning softwires. This document updates "DHCPv6 Options
directly within subsequent messages sent by the DHCPv6 server. for Configuration of Softwire Address and Port-Mapped Clients"
(RFC7598), allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6
client's Option Request Option (ORO) request and appear directly
within subsequent messages sent by the DHCPv6 server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2018.
This Internet-Draft will expire on April 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 27
deterministic softwires. deterministic softwires.
A dynamic provisioning model, such as using DHCPv4 over DHCPv6 A dynamic provisioning model, such as using DHCPv4 over DHCPv6
[RFC7341] (DHCP 4o6) allows much more flexibility in the location of [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
the IPv4-over-IPv6 softwire source address. In this model, the IPv6 the IPv4-over-IPv6 softwire source address. In this model, the IPv6
address is dynamically communicated back to the service provider address is dynamically communicated back to the service provider
allowing the corresponding softwire configuration to be created in allowing the corresponding softwire configuration to be created in
the border router (BR). the border router (BR).
The DHCP 4o6 client and softwire client could be run on end devices The DHCP 4o6 client and softwire client could be run on end devices
attached to any routable IPv6 prefix allocated to an end-user, attached to a network segment using any routable IPv6 prefix
located anywhere within an arbitrary home network topology. Dynamic allocated to an end-user, located anywhere within an arbitrary home
allocation also helps to optimize IPv4 resource usage as only clients network topology. Dynamic allocation also helps to optimize IPv4
which are actively renewing their IPv4 lease hold on to the address. 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 This document describes a mechanism for dynamically provisioning
softwires created using DHCP 4o6, including provisioning the client softwires created using DHCP 4o6, including provisioning the client
with the address of the softwire border router (BR) and informing the with the address of the softwire border router (BR) and informing the
service provider of client's binding between the dynamically service provider of client's binding between the dynamically
allocated IPv4 address and Port Set ID and the IPv6 address that the allocated IPv4 address and Port Set ID and the IPv6 address that the
softwire Initiator will use for accessing IPv4-over-IPv6 services. softwire Initiator will use for accessing IPv4-over-IPv6 services.
The mechanism operates alongside the DHCP 4o6 message flows to The mechanism operates alongside the DHCP 4o6 message flows to
communicate the binding information over the IPv6-only network. The communicate the binding information over the IPv6-only network. The
skipping to change at page 4, line 18 skipping to change at page 4, line 21
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Solution Overview 4. Solution Overview
In order to provision a softwire, both IPv6 and IPv4 configuration 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 needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in DHCPv6 configuration process, the IPv6 configuration is carried in DHCPv6
options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message
DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used
to provision the remote IPv6 address for the softwire (see to provision the remote IPv6 address for the softwire border router
Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is (see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is
optionally sent by the DHCP 4o6 server to indicate to the client a optionally sent by the DHCP 4o6 server to indicate to the client a
preferred IPv6 prefix for binding the received IPv4 configuration and preferred IPv6 prefix for binding the received IPv4 configuration and
sourcing tunnel traffic. This may be necessary if there are multiple 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 IPv6 prefixes in use in the customer network (e.g., Unique Local
specific IPv4-over-IPv6 transition mechanism requires the use of a Addresses (ULAs)), or if the specific IPv4-over-IPv6 transition
particular prefix for any reason. mechanism requires the use of a particular prefix for any reason.
IPv4 configuration is carried in DHCPv4 messages [RFC2131], (inside IPv4 configuration is carried in DHCPv4 messages [RFC2131], (inside
the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in [RFC7341]. described in [RFC7341].
In order for the client to communicate the softwire source address, a In order for the client to communicate the softwire source address, a
new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this
document. This is included in DHCPREQUEST messages sent by the document. This is included in DHCPREQUEST messages sent by the
client and is stored by the server for the lifetime of the IPv4 client and is stored by the server for the lifetime of the IPv4
address lease. address lease.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
| DHCPv6 - DHCPV4-RESPONSE message containing | | DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) |
| (bind-ipv6-prefix with service provider's | | (bind-ipv6-prefix with service provider's |
| preferred prefix) | | preferred prefix) |
Step 2 |<-----------------------------------------------------| Step 2 |<-----------------------------------------------------|
| DHCPv4 - DHCPOFFER message | | DHCPv4 - DHCPOFFER message |
| | | |
| | | |
| DHCPv6 - DHCPV4-QUERY message | | DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->| Step 3 |----------------------------------------------------->|
| DHCPv4 - DHCPREQUEST message containing | | DHCPv4 - DHCPREQUEST message containing |
| OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
| with client's bound IPv6 softwire source address) | | with client's bound IPv6 softwire source address) |
| | | |
| | | |
| DHCPv6 - DHCPV4-RESPONSE message | | DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------| Step 4 |<-----------------------------------------------------|
| DHCPv4 - DHCPACK message containing | | DHCPv4 - DHCPACK message containing |
| OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
| with client's bound IPv6 softwire source address) | | with client's bound IPv6 softwire source address) |
| | | |
skipping to change at page 7, line 7 skipping to change at page 7, line 7
the IPv6 address of the BR for the client's softwire the IPv6 address of the BR for the client's softwire
configuration. The message may also optionally contain configuration. The message may also optionally contain
OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG
contains a DHCPv4 DHCPOFFER message. contains a DHCPv4 DHCPOFFER message.
Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message
containing a DHCPv4 DHCPREQUEST message with containing a DHCPv4 DHCPREQUEST message with
OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which
the client will use as its softwire source address. the client will use as its softwire source address.
Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE(21)' message. Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message.
OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message.
OPTION_DHCP4O6_S46_SADDR with the client's softwire source OPTION_DHCP4O6_S46_SADDR with the client's softwire source
address is included. address is included.
6. DHCP Options 6. DHCP Options
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option
The format of DHCPv6 Source Binding Prefix hint option is as follows: The format of DHCPv6 Source Binding Prefix hint option is as follows:
skipping to change at page 9, line 27 skipping to change at page 9, line 27
according to Section 7.4. If valid, the client uses this prefix as according to Section 7.4. If valid, the client uses this prefix as
the 'IPv6 binding prefix' and follows to the process described in the 'IPv6 binding prefix' and follows to the process described in
Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to
construct the softwire. If no match is found, or the client doesn't 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 receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid
IPv6 prefix (of a suitable scope) to use as the tunnel source. 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 Once the client has selected a suitable prefix, it MAY use either an
existing IPv6 address that is already configured on an interface, or existing IPv6 address that is already configured on an interface, or
create a new address specifically for use as the softwire source create a new address specifically for use as the softwire source
address (e.g. using an Interface Identifier constructed as per address (e.g., using an Interface Identifier constructed as per
Section 6 of [RFC7597]). If a new address is being created, the Section 6 of [RFC7597]). If a new address is being created, the
client MUST complete configuration of the new address, performing client MUST complete configuration of the new address, performing
duplicate address detection (if required) before proceeding. duplicate address detection (if required) before proceeding.
The client then constructs a DHCPV4-QUERY message containing a DHCPv4 The client then constructs a DHCPV4-QUERY message containing a DHCPv4
DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the
options field of the DHCPREQUEST message with the IPv6 address of its options field of the DHCPREQUEST message with the IPv6 address of its
softwire source address in the softwire-ipv6-src-address field. softwire source address in the softwire-ipv6-src-address field.
When the client receives a DHCPv4 DHCPACK message from the server, it When the client receives a DHCPv4 DHCPACK message from the server, it
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Address Address
Whenever the client attempts to extend the lease time of the IPv4 Whenever the client attempts to extend the lease time of the IPv4
address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its
softwire source address in the softwire-ipv6-src-address field MUST softwire source address in the softwire-ipv6-src-address field MUST
be included in the DHCPREQUEST message. be included in the DHCPREQUEST message.
7.2.1. Changing the Bound IPv6 Softwire Source Address 7.2.1. Changing the Bound IPv6 Softwire Source Address
Across the lifetime of the leased IPv4 address, it is possible that 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- the client's IPv6 will change. E.g., if there is an IPv6 re-
numbering event. numbering event.
In this situation, the client MUST inform the server of the new In this situation, the client MUST inform the server of the new
address. This is done by sending a DHCPREQUEST message containing address. This is done by sending a DHCPREQUEST message containing
OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.
When the client receives a DHCPv4 DHCPACK message from the server, it When the client receives a DHCPv4 DHCPACK message from the server, it
checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
active softwire source address. If they match, the allocation active softwire source address. If they match, the allocation
process has concluded. If there is a discrepancy then the process process has concluded. If there is a discrepancy then the process
skipping to change at page 10, line 42 skipping to change at page 10, line 42
DHCPv4 DHCPRELEASE message to the server. As the options field is DHCPv4 DHCPRELEASE message to the server. As the options field is
unused in this message type, OPTION_DHCP4O6_S46_SADDR is not unused in this message type, OPTION_DHCP4O6_S46_SADDR is not
included. included.
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior
On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client
makes the following validation checks: makes the following validation checks:
o The received bindprefix6-len value is not larger than 128. o The received bindprefix6-len value is not larger than 128.
o The received bindprefix6-len value is not larger than the number o The number of bytes received in the bind-ipv6-prefix field is
of bytes, divided by 8, received in the bind-ipv6-prefix field. consistent with the received bindprefix6-len value (calculated as
(e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is described in Section 6.1).
only 8 bytes long).
For either of these cases, the receiver discards the invalid option If either check fails, the receiver discards the invalid option and
and proceeds to attempt configuration as if the option had not been proceeds to attempt configuration as if the option had not been
received. received.
The receiver MUST only use bits from the bind-ipv6-prefix field up to The receiver MUST only use bits from the bind-ipv6-prefix field up to
the value specified in the bindprefix6-len when performing the the value specified in the bindprefix6-len when performing the
longest prefix match. bind-ipv6-prefix bits beyond this value MUST be longest prefix match. bind-ipv6-prefix bits beyond this value MUST be
ignored. ignored.
7.5. Client and Server Softwire Source Address Mismatch 7.5. Client and Server Softwire Source Address Mismatch
If the client receives a DHCPACK message with an If the client receives a DHCPACK message with an
OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs
from its active softwire source address, the client SHOULD wait for a from its active softwire source address, the client SHOULD wait for a
randomised time interval and then resend the DHCPREQUEST message with randomized time interval and then resend the DHCPREQUEST message with
the correct softwire source address. [RFC2131] Section 4.1 descibes the correct softwire source address. [RFC2131] Section 4.1 descibes
the retransmission backoff interval process. the retransmission backoff interval process.
If, after a number of re-tries, the retransmission process does not The default time minimum time for the client to attempt
return a DHCPACK message with the correct bound IPv6 address, a retransmission is 60 seconds. If, after this time has expired, the
client MAY send a DHCPRELEASE message and re-start the process client has not received a DHCPACK message with the correct bound IPv6
described in Section 7. The number of re-tries should be address, client MAY send a DHCPRELEASE message and re-start the
process described in Section 7. The re-try interval should be
configurable and aligned with any server policy defining the minimum configurable and aligned with any server policy defining the minimum
time interval for client address updates as described in Section 8.1. time interval for client address updates as described in Section 8.1.
7.6. Use With Dynamic, Shared IPv4 Addresses 7.6. Use With Dynamic, Shared IPv4 Addresses
[RFC7618] describes a mechanism for using DHCPv4 to distribute [RFC7618] describes a mechanism for using DHCPv4 to distribute
dynamic, shared IPv4 addresses to clients. The mechanism described dynamic, shared IPv4 addresses to clients. The mechanism described
in this document is compatible with IPv4 address sharing, and can be in this document is compatible with IPv4 address sharing, and can be
enabled by following the process described in Section 6 of [RFC7618]. enabled by following the process described in Section 6 of [RFC7618].
skipping to change at page 12, line 12 skipping to change at page 12, line 12
server updates the stored softwire source address with the new server updates the stored softwire source address with the new
address supplied by the client, and sends a DHCPACK message address supplied by the client, and sends a DHCPACK message
containing the updated softwire source address in containing the updated softwire source address in
OPTION_DHCP4O6_S46_SADDR. OPTION_DHCP4O6_S46_SADDR.
The server MAY implement a policy enforcing a minimum time interval The server MAY implement a policy enforcing a minimum time interval
between a client updating its softwire source IPv6 address. If a between a client updating its softwire source IPv6 address. If a
client attempts to update the softwire source IPv6 address before the client attempts to update the softwire source IPv6 address before the
minimum time has expired, the server can either silently drop the minimum time has expired, the server can either silently drop the
client's message or send back a DHCPACK message containing the client's message or send back a DHCPACK message containing the
existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If
implemented, the default minimum client source address update
interval is 60 seconds.
9. Security Considerations 9. Security Considerations
Security considerations which are applicable to [RFC7341] are also Security considerations which are applicable to [RFC7341] are also
applicable here. applicable here.
A rogue client could attempt to use the mechanism described in A rogue client could attempt to use the mechanism described in
Section 7.2.1 to redirect IPv4 traffic intended for another client to Section 7.2.1 to redirect IPv4 traffic intended for another client to
itself. This would be performed by sending a DHCPREQUEST message for itself. This would be performed by sending a DHCPREQUEST message for
another client's active IPv4 lease containing the attacker's softwire another client's active IPv4 lease containing the attacker's softwire
IPv6 address in OPTION_DHCP4O6_S46_SADDR. IPv6 address in OPTION_DHCP4O6_S46_SADDR.
For such an attack to be effective, the attacker would need to know For such an attack to be effective, the attacker would need to know
both the client identifier and active IPv4 address lease currently in both the client identifier and active IPv4 address lease currently in
use by another client. The risk of this can be reduced by using a use by another client. The risk of this can be reduced by using a
client identifier format which is not easily guessable, e.g. by client identifier format which is not easily guessable, e.g., by
including a time component for when the client identifier was including a time component for when the client identifier was
generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2). generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).
A client may attempt to overload the server by sending multiple A client may attempt to overload the server by sending multiple
source address update messages (see Section 7.2.1) in a short time source address update messages (see Section 7.2.1) in a short time
frame. This risk can be reduced by implementing a server policy frame. This risk can be reduced by implementing a server policy
enforcing a minimum time interval between client address changes as enforcing a minimum time interval between client address changes as
described in Section 8.1. described in Section 8.1.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 13, line 14 skipping to change at page 13, line 18
Old entry: Old entry:
| 90 | S46_BR | No | No | | 90 | S46_BR | No | No |
New entry: New entry:
| 90 | S46_BR | Yes | No | | 90 | S46_BR | Yes | No |
IANA is also requested to make a new entry for IANA is also requested to make a new entry for
OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the table at OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
https://www.iana.org/assignments/dhcpv6-parameters: https://www.iana.org/assignments/dhcpv6-parameters:
| TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | | TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes |
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei,
Jonas Gorski and Razvan Becheriu for their contributions and Jonas Gorski and Razvan Becheriu for their contributions and
comments. comments.
skipping to change at page 14, line 45 skipping to change at page 14, line 45
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: sunqi.csnet.thu@gmail.com Email: sunqi.ietf@gmail.com
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
Linhui Sun Linhui Sun
Tsinghua University Tsinghua University
 End of changes. 21 change blocks. 
47 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/