draft-ietf-dhc-dynamic-shared-v4allocation-09.txt   rfc7618.txt 
DHC WG Y. Cui Internet Engineering Task Force (IETF) Y. Cui
Internet-Draft Q. Sun Request for Comments: 7618 Q. Sun
Intended status: Standards Track Tsinghua University Category: Standards Track Tsinghua University
Expires: November 29, 2015 I. Farrer ISSN: 2070-1721 I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
Y. Lee Y. Lee
Comcast Comcast
Q. Sun Q. Sun
China Telecom China Telecom
M. Boucadair M. Boucadair
France Telecom France Telecom
May 28, 2015 August 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-09
Abstract Abstract
This memo describes the dynamic allocation of shared IPv4 addresses This memo describes the dynamic allocation of shared IPv4 addresses
to clients using DHCPv4. Address sharing allows a single IPv4 to clients using DHCPv4. Address sharing allows a single IPv4
address to be allocated to multiple active clients simultaneously, address to be allocated to multiple active clients simultaneously,
each client being differentiated by a unique set of transport layer with each client being differentiated by a unique set of transport-
source port numbers. The necessary changes to existing DHCPv4 client layer source port numbers. The necessary changes to existing DHCPv4
and server behavior are described and a new DHCPv4 option for client and server behavior are described, and a new DHCPv4 option for
provisioning clients with shared IPv4 addresses is included. provisioning clients with shared IPv4 addresses is included.
Due to the nature of IP address sharing, some limitations to its Due to the nature of IP address sharing, some limitations to its
applicability are necessary. This memo describes these limitations applicability are necessary. This memo describes these limitations
and recommends suitable architectures and technologies where address and recommends suitable architectures and technologies where address
sharing may be utilized. sharing may be utilized.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 29, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7618.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement .........................................3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language ...........................................4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology .....................................................4
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 5. Functional Overview .............................................4
6. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 6. Client-Server Interaction .......................................5
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 7. Client Behavior .................................................6
7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6 7.1. Restrictions to Client Usage of a Shared IPv4 Address ......7
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 8. Server Behavior .................................................7
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a 8.1. Leasing Shared and Non-Shared IPv4 Addresses from a
Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8 Single DHCP 4o6 Server .....................................9
9. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8 9. DHCPv4 Port Parameters Option ...................................9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations .......................................10
10.1. Port Randomization . . . . . . . . . . . . . . . . . . . 10 10.1. Port Randomization .......................................11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations ...........................................11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References ....................................................11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References .....................................11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References ...................................12
13.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgements ..................................................14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses ................................................14
1. Introduction 1. Introduction
The shortage of available public IPv4 addresses means that it is not The shortage of available public IPv4 addresses means that it is not
always possible for operators to allocate a full IPv4 address to always possible for operators to allocate a full IPv4 address to
every connected device. This problem is particularly acute whilst an every connected device. This problem is particularly acute while an
operator is migrating from their existing, native IPv4 network to a operator is migrating from their existing, native IPv4 network to a
native IPv6 network with IPv4 provided as an overlay service. During native IPv6 network with IPv4 provided as an overlay service. During
this phase, public IPv4 addresses are needed to provide for both this phase, public IPv4 addresses are needed to provide for both
existing and transition networks. existing and transition networks.
Two main types of solutions have emerged to address the problem (see Two main types of solutions have emerged to address the problem (see
Appendix A of [RFC6269]): Appendix A of [RFC6269]):
1. Deploying Carrier Grade Network Address Translation devices 1. Deploying Carrier-Grade Network Address Translation devices
(CGNAT, [RFC6888]). (CGNs) [RFC6888].
2. Distributing the same public IPv4 address to multiple clients 2. Distributing the same public IPv4 address to multiple clients
differentiated by non-overlapping layer 4 port sets. differentiated by non-overlapping Layer 4 port sets.
This memo focuses on the second category of solutions. This memo focuses on the second category of solutions.
[RFC7341] introduces a "DHCP 4o6 Server", which offers dynamic [RFC7341] introduces a "DHCP 4o6 server", which offers dynamic
leasing for IPv4 addresses to clients as in DHCPv4 [RFC2131] but leasing for IPv4 addresses to clients as described in DHCPv4
transported within a DHCPv6 message flow. This memo specifies a new [RFC2131], but transported within a DHCPv6 message flow. This memo
DHCPv4 option: OPTION_V4_PORTPARAMS, and describes how it can be used specifies a new DHCPv4 option -- OPTION_V4_PORTPARAMS -- and
for the dynamic leasing of shared IPv4 addresses. describes how it can be used for the dynamic leasing of shared IPv4
addresses.
Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4
transport mechanism throughout this document, OPTION_V4_PORTPARAMS as transport mechanism throughout this document, OPTION_V4_PORTPARAMS as
a DHCPv4 option may also be used in other solutions, if required. a DHCPv4 option may also be used in other solutions, if required.
2. Applicability Statement 2. Applicability Statement
The solution allows multiple hosts to be simultaneously allocated the The solution allows multiple hosts to be simultaneously allocated the
same IP address. As the IP address is no longer a unique identifier same IP address. As the IP address is no longer a unique identifier
for a host, this extension is only suitable for specific for a host, this solution is only suitable for specific architectures
architectures based on the Address plus Port model (A+P) [RFC6346]. based on the Address plus Port model (A+P) [RFC6346]. Specifically,
Specifically, this document presents a solution that applies to this document presents a solution that applies to [RFC7596] and
[I-D.ietf-softwire-lw4over6] and certain configurations of certain configurations of [RFC7597] (e.g., Embedded Address bit
[I-D.ietf-softwire-map] (e.g., EA-bit length set to 0). (EA-bit) length set to 0).
The solution should only be used on point-to-point links, tunnels, The solution should only be used on point-to-point links, tunnels,
and/or in environments where authentication at the link layer is and/or in environments where authentication at the link layer is
performed before IP address assignment. It is not suitable for performed before IP address assignment. It is not suitable for
network access over shared media, including Ethernet, WLAN, cable, network access over shared media (e.g., Ethernet, WLAN, cable).
etc..
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Terminology 4. Terminology
This document makes use of the following terms: This document uses the following terms:
Shared IPv4 address: An IPv4 address with a restricted layer 4 port Shared IPv4 address: An IPv4 address with a restricted Layer 4
set. port set.
Port Set ID (PSID): Identifier for a range of ports assigned to a Port Set ID (PSID): Identifier for a range of ports assigned to a
DHCP client. DHCP client.
5. Functional Overview 5. Functional Overview
Functionally, the dynamic allocation of shared IPv4 addresses by the Functionally, the dynamic allocation of shared IPv4 addresses by the
DHCP 4o6 Server is similar to the dynamic allocation process for DHCP 4o6 server is similar to the dynamic allocation process for
'full' IPv4 addresses described in [RFC2131]. The essential "full" IPv4 addresses as described in [RFC2131]. The essential
difference is that the DHCP 4o6 Server can allocate the same IPv4 difference is that the DHCP 4o6 server can allocate the same IPv4
address to more than one DHCP 4o6 client simultaneously, providing address to more than one DHCP 4o6 client simultaneously, providing
that each shared address allocation also includes a range of layer 4 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 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). address and Port Set ID is to be unique for each active lease).
The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described
below), which is a DHCPv4 option containing PSID (Port Set ID) below), which is a DHCPv4 option containing PSID information. The
information. The client includes this option within the Parameter client includes this option within the Parameter Request List option
Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and [RFC2132] in its DHCPv4 DHCPDISCOVER and DHCPREQUEST messages,
DHCPREQUEST messages, indicating its support for shared, dynamic indicating its support for shared, dynamic address leasing to the
address leasing to the DHCP 4o6 server. DHCP 4o6 server.
OPTION_V4_PORTPARAMS is also implemented by the server to identify OPTION_V4_PORTPARAMS is also implemented by the server to identify
clients that support shared, dynamic address leasing. With this clients that support shared, dynamic address leasing. With this
option, the server can dynamically allocate PSIDs to clients and option, the server can dynamically allocate PSIDs to clients and
maintain shared IPv4 address leases. The server then manages unique maintain shared IPv4 address leases. The server then manages unique
client leases based the IPv4 address and PSID tuple, instead of using client leases based on the IPv4 address and PSID tuple, instead of
only the IPv4 address. using only the IPv4 address.
In the event that a dynamic, shared addressing capable client In the event that a client capable of dynamic, shared addressing
receives more than one DHCP 4o6 offer, where a received offer does 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 not contain OPTION_V4_PORTPARAMS (i.e., it is an offer for a full
address), then the client SHOULD prefer the full IPv4 offer over the IPv4 address), then the client SHOULD prefer the full IPv4 offer over
shared IPv4 address offer(s), unless specifically configured the shared IPv4 address offer(s), unless specifically configured
otherwise. otherwise.
6. Client-Server Interaction 6. Client-Server Interaction
The following DHCPv4 message flow is transported within the The following DHCPv4 message flow is transported within the
DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6 DHCPv4-query and DHCPv4-response messages as described in DHCPv4 over
[RFC7341]. DHCPv6 [RFC7341].
1. When the client constructs the DHCPv4 DHCPDISCOVER message to be 1. When the client constructs the DHCPv4 DHCPDISCOVER message to be
transported within the DHCPv4-query message, the DHCPDISCOVER transported within the DHCPv4-query message, the DHCPDISCOVER
message MUST include the client identifier option (constructed as message MUST include the client identifier option (constructed as
per [RFC4361]) and the Parameter Request List (PRL) option with per [RFC4361]) and the Parameter Request List option with the
the code of OPTION_V4_PORTPARAMS. The client MAY insert an code OPTION_V4_PORTPARAMS. The client MAY insert an
OPTION_V4_PORTPARAMS with preferred values in related fields as a OPTION_V4_PORTPARAMS with preferred values in related fields as a
suggestion to the DHCP 4o6 Server. suggestion to the DHCP 4o6 server.
2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and 2. DHCP 4o6 servers that receive the DHCPDISCOVER message and
support shared IPv4 addresses respond with a DHCPOFFER message support shared IPv4 addresses respond with a DHCPOFFER message
with the shared IPv4 address in the 'yiaddr' field and MUST add with the shared IPv4 address in the yiaddr field, and they MUST
an OPTION_V4_PORTPARAMS option containing an available restricted add an OPTION_V4_PORTPARAMS option containing an available
port set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS restricted port set. If the DHCPDISCOVER included an
option containing a non-zero PSID-Len field, the DHCP 4o6 Server OPTION_V4_PORTPARAMS option containing a non-zero PSID-len field,
MAY allocate a port set of the requested size to the client the DHCP 4o6 server MAY allocate a port set of the requested size
(depending on policy). The DHCPOFFER message is then to the client (depending on policy). The DHCPOFFER message is
encapsulated in the DHCPv4-response message and sent to the then encapsulated in the DHCPv4-response message and sent to the
client. client.
3. The client evaluates all received DHCPOFFER messages and selects 3. The client evaluates all received DHCPOFFER messages and selects
one (e.g., based on the configuration parameters received, such one (e.g., based on the configuration parameters received, such
as the size of the offered port set). The client then sends a as the size of the offered port set). The client then sends a
DHCPREQUEST encapsulated in the DHCPv4-query message containing DHCPREQUEST encapsulated in the DHCPv4-query message containing
the corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER the corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER
message. message.
4. The server identified in the DHCPREQUEST message creates a 4. The server identified in the DHCPREQUEST message creates a
binding for the client. The binding includes the client binding for the client. The binding includes the client
identifier, the IPv4 address and the PSID. These parameters are identifier, the IPv4 address, and the PSID. These parameters are
used by both the server and the client to identify a lease in any used by both the server and the client to identify a lease in any
DHCP message. The server MUST respond with a DHCPACK message DHCP message. The server MUST respond with a DHCPACK message
containing OPTION_V4_PORTPARAMS for the requesting client. containing OPTION_V4_PORTPARAMS for the requesting client.
5. On receipt of the DHCPACK message with the configuration 5. On receipt of the DHCPACK message with the configuration
parameters, the client MUST NOT perform an in-use probe on the parameters, the client MUST NOT perform an in-use probe on the
address, such as ARPing for a duplicate allocated address. address, such as ARPing for a duplicate allocated address.
6. If the client chooses to relinquish its lease by sending a 6. If the client chooses to relinquish its lease by sending a
DHCPRELEASE message, the client MUST include the leased network DHCPRELEASE message, the client MUST include the leased network
address and OPTION_V4_PORTPARAMS (with the allocated PSID) to address and OPTION_V4_PORTPARAMS (with the allocated PSID) to
identify the lease to be released. identify the lease to be released.
In the case that the client has stored the previously allocated In the case where the client has stored the previously allocated
address and restricted port set, the logic described in Section 3.2 address and restricted port set, the logic described in Section 3.2
of [RFC2131] MUST be followed on the condition that the client's of [RFC2131] MUST be followed on the condition that the client's
source IPv6 address for DHCP 4o6 does not change. Note, this source IPv6 address for DHCP 4o6 does not change. Note that this
corresponds to the INIT-REBOOT state defined in [RFC2131]. The corresponds to the INIT-REBOOT state defined in [RFC2131]. The
client MUST include the OPTION_V4_PORTPARAMS with the requested port client MUST include the OPTION_V4_PORTPARAMS with the requested
set information in the message flow, which starts with a DHCPREQUEST port-set information in the message flow, which starts with a
message. If the client's DHCP 4o6 IPv6 source address is changed for DHCPREQUEST message. If the client's DHCP 4o6 IPv6 source address
any reason, the client MUST re-initiate the DHCP 4o6 shared-address is changed for any reason, the client MUST re-initiate the DHCP 4o6
provisioning process by sending a DHCPDISCOVER message. shared-address provisioning process by sending a
DHCPDISCOVER message.
7. Client Behavior 7. Client Behavior
A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4 A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4
address MUST include the OPTION_V4_PORTPARAMS option code in the address MUST include the OPTION_V4_PORTPARAMS Option Code in the
Parameter Request List option. If a client has been successfully Parameter Request List option. If a client has previously been
allocated an IPv4 address and PSID previously, the client's successfully allocated an IPv4 address and PSID, the client's
DHCPDISCOVER message MAY include the 'requested IP address' option DHCPDISCOVER message MAY include the Requested IP Address option
along with an OPTION_V4_PORTPARAMS to request that a specific IPv4 along with an OPTION_V4_PORTPARAMS to request that a specific IPv4
address and PSID be re-assigned. Alternatively, the client MAY omit address and PSID be reassigned. Alternatively, the client MAY omit
the 'requested IP address' option, but include an the Requested IP Address option but include an OPTION_V4_PORTPARAMS
OPTION_V4_PORTPARAMS with a non-zero value in only the PSID-Len with a non-zero value in only the PSID-len field, as a hint to the
field, as a hint to the server for the preferred size of the port server for the preferred size of the port set.
set.
A client that requests OPTION_V4_PORTPARAMS, but receives DHCPOFFER A client that requests OPTION_V4_PORTPARAMS but receives DHCPOFFER
and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as
defined in [RFC7341] and configure a full IPv4 address with no described in Section 9 of [RFC7341] and configure a full IPv4 address
address sharing (see Section 8.1 for the server's behavior). with no address sharing (see Section 8.1).
When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the
client MUST use the received explicit PSID for configuring the client MUST use the received explicit PSID for configuring the
interface for which the DHCP 4o6 request was made. interface for which the DHCP 4o6 request was made.
The client MUST NOT probe a newly received IPv4 address (e.g., using The client MUST NOT probe a newly received IPv4 address (e.g., using
ARP) to see if it is in use by another host. ARP) to see if it is in use by another host.
When the client renews or releases its DHCP lease, it MUST put the When the client renews or releases its DHCP lease, it MUST include
values of offset, PSID length and PSID into OPTION_V4_PORTPARAMS, and the offset, PSID length, and PSID values in OPTION_V4_PORTPARAMS, and
send it to the server within corresponding DHCPv4 messages that are send it to the server within corresponding DHCPv4 messages.
conveyed through DHCPv4-query message.
In the event that the client's DHCP 4o6 IPv6 source address is 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 changed for any reason, the client MUST re-initiate the DHCP 4o6
shared-address provisioning process by sending a DHCPDISCOVER shared-address provisioning process by sending a DHCPDISCOVER
message. message.
7.1. Restrictions to Client Usage of a Shared IPv4 Address 7.1. Restrictions to Client Usage of a Shared IPv4 Address
As a single IPv4 address is being shared between a number of As a single IPv4 address is being shared between a number of
different clients, the allocated shared address is only suitable for different clients, the allocated shared address is only suitable for
certain uses. The client MUST implement a function to ensure that certain uses. The client MUST implement a function to ensure that
only the allocated layer 4 ports of the shared IPv4 address are used only the allocated Layer 4 ports of the shared IPv4 address are used
for sourcing new connections, or accepting inbound connections. for sourcing new connections or accepting inbound connections.
The client MUST apply the following rules for all traffic destined to The client MUST apply the following rules for all traffic destined
or originating from the shared IPv4 address: to, or originating from, the shared IPv4 address:
o The client MUST use only port-aware protocols (e.g., TCP, UDP, the
Datagram Congestion Control Protocol (DCCP)) and be ICMP compliant
with [RFC5508].
o The client MUST use only port-aware protocols (e.g., TCP, UDP,
DCCP etc.) or ICMP implementing [RFC5508].
o All connections originating from the shared IPv4 address MUST use o All connections originating from the shared IPv4 address MUST use
a source port taken from the allocated restricted port set. a source port taken from the allocated restricted port set.
o The client MUST NOT accept inbound connections on ports outside of o The client MUST NOT accept inbound connections on ports outside of
the allocated restricted port set. the allocated restricted port set.
In order to prevent addressing conflicts which could arise from the In order to prevent addressing conflicts that could arise from the
allocation of the same IPv4 address, the client MUST NOT use the allocation of the same IPv4 address, the client MUST NOT use the
received restricted IPv4 address to perform ARP operations. received restricted IPv4 address to perform ARP operations.
The mechanism by which a client implements the above rules is out of The mechanism by which a client implements the above rules is out of
the scope of this document. scope for this document.
In the event that the DHCPv4 over DHCPv6 configuration mechanism In the event that the DHCPv4-over-DHCPv6 configuration mechanism
fails for any reason, the client MUST NOT configure an IPv4 link- fails for any reason, the client MUST NOT configure an IPv4
local address [RFC3927] (taken from the 169.254.0.0/16 range). link-local address [RFC3927] (taken from the 169.254.0.0/16 range).
8. Server Behavior 8. Server Behavior
The DHCP 4o6 Server MUST NOT reply with OPTION_V4_PORTPARAMS unless The DHCP 4o6 server MUST NOT reply with OPTION_V4_PORTPARAMS unless
the client has explicitly listed the option code in the Parameter the client has explicitly listed the Option Code in the Parameter
Request List (Option 55) [RFC2132]. Request List (Option 55) [RFC2132].
The DHCP 4o6 Server SHOULD reply with OPTION_V4_PORTPARAMS if the The DHCP 4o6 server SHOULD reply with OPTION_V4_PORTPARAMS if the
client includes OPTION_V4_PORTPARAMS in its Parameter Request List. client includes OPTION_V4_PORTPARAMS in its Parameter Request List.
In order to achieve the dynamic management of shared IPv4 addresses, In order to achieve dynamic management of shared IPv4 addresses, the
the server is required to implement an address and port-set pool that server is required to implement an address and port-set pool that
provides the same function as the address pool in a regular DHCP provides the same function as the address pool in a regular DHCP
server. Also, the server uses the combination of address and PSID as 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 the key for maintaining the state of a lease and for searching for an
an available lease for assignment. The leasing database is required available lease for assignment. The leasing database is required to
to include the IPv4 address, PSID and client identifier of the include the IPv4 address, PSID, and client identifier of the
requesting client. requesting client.
When a server receives a DHCPDISCOVER message with When a server receives a DHCPDISCOVER message with
OPTION_V4_PORTPARAMS in the Parameter Request List option, the server OPTION_V4_PORTPARAMS in the Parameter Request List option, the server
determines an IPv4 address with a PSID for the requesting client. If determines an IPv4 address with a PSID for the requesting client. If
an IPv4 address with a PSID is available, the server SHOULD follow an IPv4 address with a PSID is available, the server SHOULD follow
the logic below to select which specific address and PSID to the logic below to select which specific address and PSID to
provision to the client. The logic is similar to that in provision to the client. The logic is similar to that described in
Section 4.3.1 of [RFC2131]. Section 4.3.1 of [RFC2131].
o The client's current address with the PSID as recorded in the o The client's current address with the PSID, as recorded in the
client's current lease binding, ELSE client's current lease binding, ELSE
o The client's previous address with PSID as recorded in the
o The client's previous address with the PSID, as recorded in the
client's (expired or released) binding, if that address with PSID client's (expired or released) binding, if that address with PSID
is in the server's pool of available addresses and PSIDs, and not is in the server's pool of available addresses and PSIDs, and not
already allocated, ELSE already allocated, ELSE
o The address requested in the 'Requested IP Address' option along
o The address requested in the Requested IP Address option along
with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if
that pair of address and PSID is valid and not already allocated, that pair of address and PSID is valid and not already allocated,
ELSE ELSE
o A new address with a PSID allocated from the server's pool of o A new address with a PSID allocated from the server's pool of
available addresses and PSIDs. available addresses and PSIDs.
Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the
server searches for the lease using the address in the 'ciaddr' field server searches for the lease using the address in the ciaddr field
and the PSID information in the OPTION_V4_PORTPARAMS, and marks the and the PSID information in the OPTION_V4_PORTPARAMS, and marks the
lease as unallocated if a record (matching that PSID) is maintained lease as unallocated if a record (matching that PSID) is maintained
by the server for that client. by the server for that client.
The port-set assignment MUST be coupled with the address assignment The port-set assignment MUST be coupled with the address assignment
process. Therefore the server MUST assign the address and port set process. Therefore, the server MUST assign the address and port set
in the same DHCP message. in the same DHCP message.
When defining the pools of IPv4 addresses and PSIDs which are When defining the pools of IPv4 addresses and PSIDs that are
available to lease to clients, the server MUST implement a mechanism available to lease to clients, the server MUST implement a mechanism
to reserve some port ranges (e.g., 0-1023) from allocation to to reserve some port ranges (e.g., 0-1023) from allocation to
clients. The reservation policy SHOULD be configurable. clients. The reservation policy SHOULD be configurable.
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single
4o6 Server DHCP 4o6 Server
A single DHCP 4o6 server may serve clients that do not support 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 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 allocation of shared addresses differ from the rules for full IPv4
address assignment, the DHCP 4o6 server MUST implement a mechanism to address assignment, the DHCP 4o6 server MUST implement a mechanism to
ensure that clients not supporting OPTION_V4_PORTPARAMS do not ensure that clients not supporting OPTION_V4_PORTPARAMS do not
receive shared addresses. For example, two separate IPv4 addressing receive shared addresses. For example, two separate IPv4 addressing
pools could be used, one of which allocates IPv4 addresses and PSIDs pools could be used, one of which allocates IPv4 addresses and PSIDs
only to clients that have requested them. only to clients that have requested them.
If the server is only configured with address pools for shared If the server is only configured with address pools for shared-
address allocation, it MUST discard requests that do not contain address allocation, it MUST discard requests that do not contain
OPTION_V4_PORTPARAMS in the Parameter Request List option. OPTION_V4_PORTPARAMS in the Parameter Request List option.
A server configured with non-shared address pools can be instructed A server configured with non-shared address pools can be instructed
to honor received requests that contain OPTION_V4_PORTPARAMS in the to honor received requests that contain OPTION_V4_PORTPARAMS in the
Parameter Request List option (that is ignore OPTION_V4_PORTPARAMS Parameter Request List option (that is, ignore OPTION_V4_PORTPARAMS
and serve the requesting clients with non-shared IPv4 addresses). and serve the requesting clients with non-shared IPv4 addresses).
9. DHCPv4 Port Parameters Option 9. DHCPv4 Port Parameters Option
The meaning of 'offset', 'PSID-len', and 'PSID' fields of the DHCPv4 The meanings of the offset, PSID-len, and PSID fields of the DHCPv4
Port Parameters Option is identical to that of 'offset', 'PSID-len', Port Parameters option are identical to those of the offset,
and 'PSID' fields of the S46 Port Parameters Option (Section 4.5 of PSID-len, and PSID fields of the S46 Port Parameters option
[I-D.ietf-softwire-map-dhcp]). The use of the same encoding in both (Section 4.5 of [RFC7598]). The use of the same encoding in both
options is meant to ensure compatibility with existing port set options is meant to ensure compatibility with existing port-set
implementations. implementations.
The format of OPTION_V4_PORTPARAMS is shown in Figure 1. The format of OPTION_V4_PORTPARAMS is shown in Figure 1.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | option-len | | option-code | option-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| offset | PSID-len | | offset | PSID-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PSID | | PSID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1: DHCPv4 Port Parameters Option Figure 1: DHCPv4 Port Parameters Option
o option-code: OPTION_V4_PORTPARAMS (TBA) o option-code: OPTION_V4_PORTPARAMS (159)
o option-len: 4 o option-len: 4
o offset: (PSID offset) 8 bits long field that specifies the numeric o offset: PSID offset. 8-bit field that specifies the numeric value
value for the excluded port range/offset bits (A-bits), as per for the excluded port range/offset bits ('a' bits), as per
section 5.1 of [I-D.ietf-softwire-map]. Allowed values are Section 5.1 of [RFC7597]. Allowed values are between 0 and 15,
between 0 and 15, with the default value being 6 for MAP based with the default value being 6 for MAP-based implementations.
implementations. This parameter is unused by a Lightweight 4over6 This parameter is unused by a Lightweight 4over6 client and should
client and should be set to 0. be set to 0.
o PSID-len: Bit length value of the number of significant bits in o 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 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 is to be ignored. After the first 'a' bits, there are k bits in
the port number representing the value of PSID. Subsequently, the the port number representing the value of PSID. Subsequently, the
address sharing ratio would be 2^k. address-sharing ratio would be 2^k.
o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value
algorithmically identifies a set of ports assigned to a client. 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 The first k bits on the left of this 2-octet field indicate the
value. The remaining (16-k) bits on the right are padding zeros. PSID value. The remaining (16 - k) bits on the right are padding
zeros.
[I-D.ietf-softwire-map] Section 5.1 provides a full description of Section 5.1 of [RFC7597] provides a full description of how the PSID
how the PSID is interpreted by the client. is interpreted by the client.
In order to exclude the system ports ([RFC6335]) or ports reserved by In order to exclude the system ports ([RFC6335]) or ports reserved by
ISPs, the former port-sets that contain well-known ports MUST NOT be ISPs, the former port sets that contain well-known ports MUST NOT be
assigned unless the operator has explicitly configured otherwise assigned unless the operator has explicitly configured otherwise
(e.g., by allocating a full IPv4 address). (e.g., by allocating a full IPv4 address).
10. Security Considerations 10. Security Considerations
The security considerations described in [RFC2131] and [RFC7341] are The security considerations described in [RFC2131] and [RFC7341] are
also potentially applicable to this solution. Unauthorised DHCP 4o6 also potentially applicable to this solution. Unauthorized DHCP 4o6
servers in the network could be used to stage an amplification attack servers in the network could be used to stage an amplification attack
or to supply invalid configuration leading to service disruption. or to supply an invalid configuration, leading to service disruption.
The risks of these types of attacks can be reduced through the use of The risks of these types of attacks can be reduced by using unicast
unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server unicast
unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option). addresses within the OPTION_DHCP4_O_DHCP6_SERVER option [RFC7341]).
A malicious user could attempt a DoS attack by requesting a large A malicious user could attempt a DoS attack by requesting a large
number ofIPv4 address (or fractional address) and port sets number of IPv4 address (or fractional address) and port-set
allocations, exhausting the available addresses and port sets for allocations, exhausting the available addresses and port sets for
other clients. This can be mitigated through DHCP 4o6 address other clients. This can be mitigated by implementing, on each
allocation policy, limiting the number of simultaneously active IPv4 applicable customer site, a DHCP 4o6 address allocation policy that
leases for clients whose request originate from each customer site. limits the number of simultaneously active IPv4 leases for clients
whose requests originate from that customer site.
The purpose of the client identifier option is to ensure that the The purpose of the client identifier option is to ensure that the
same client retains the same parameters over time. This interferes same client retains the same parameters over time. However, this
with the client's privacy, as it allows the server to track the interferes with the client's privacy, as it allows the server to
client. Clients can manage their privacy exposure by controlling the track the client. Clients can manage their level of exposure by
value of the client identifier, trading off stability of parameter controlling the value of the client identifier, thereby trading off
allocation for privacy. We expect that guidance on this trade-off stability of parameter allocation for privacy. We expect that
will be discussed in a future version of guidance on this trade-off will be discussed in a future version of
[I-D.ietf-dhc-anonymity-profile]. [DHCP-Anonymity].
Additional security considerations are discussed in Section 11 of Additional security considerations are discussed in Section 10 of
[I-D.ietf-softwire-map] and Section 9 of [RFC7597] and Section 9 of [RFC7596].
[I-D.ietf-softwire-lw4over6].
10.1. Port Randomization 10.1. Port Randomization
Preserving port randomization [RFC6056] may be more difficult because Preserving port randomization [RFC6056] may be more difficult because
the host can only randomize the ports inside a fixed port range (see the host can only randomize the ports inside a fixed port range (see
Section 13.4 of [RFC6269]). Section 13.4 of [RFC6269]).
More discussion to improve the robustness of TCP against Blind In- More discussion regarding improving the robustness of TCP against
Window Attacks can be found at [RFC5961]. Other means than the blind in-window attacks can be found in [RFC5961]. To provide
(IPv4) source port randomization to provide protection against protection against attacks, means other than (IPv4) source port
attacks should be used (e.g., use [RFC5961] to improve the robustness randomization should be used (e.g., use [RFC5961] to improve the
of TCP against Blind In-Window Attacks, use IPv6). robustness of TCP against blind in-window attacks, or use IPv6).
11. IANA Considerations 11. IANA Considerations
IANA is requested to assign the following new DHCPv4 Option Code in IANA has assigned the following new DHCPv4 Option Code in the
the registry maintained in: http://www.iana.org/assignments/bootp- registry maintained at
dhcp-parameters/: <http://www.iana.org/assignments/bootp-dhcp-parameters/>:
Option Name Value Data Meaning Option Name Tag Data Meaning
length Length
-------------------- ----- ------ ----------------------------------- -------------------- --- ------ -----------------------------------
OPTION_V4_PORTPARAMS TBA 4 This option is used to configure a OPTION_V4_PORTPARAMS 159 4 This option is used to configure a
set of ports bound to a shared IPv4 set of ports bound to a shared IPv4
address. address.
12. Acknowledgements 12. References
This document is merged from [I-D.sun-dhc-port-set-option] and
[I-D.farrer-dhc-shared-address-lease].
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.
13. References
13.1. Normative References
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
in progress), November 2014.
[I-D.ietf-softwire-map] 12.1. Normative References
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-13
(work in progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
2131, March 1997. 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 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. 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 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. 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 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August Robustness to Blind In-Window Attacks", RFC 5961,
2010. DOI 10.17487/RFC5961, August 2010,
<http://www.rfc-editor.org/info/rfc5961>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January Protocol Port Randomization", BCP 156, RFC 6056,
2011. DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
7341, August 2014. RFC 7341, DOI 10.17487/RFC7341, August 2014,
<http://www.rfc-editor.org/info/rfc7341>.
13.2. Informative References [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>.
[I-D.farrer-dhc-shared-address-lease] [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses Murakami, T., and T. Taylor, Ed., "Mapping of Address and
using DHCPv4 over DHCPv6", draft-farrer-dhc-shared- Port with Encapsulation (MAP-E)", RFC 7597,
address-lease-00 (work in progress), June 2013. DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[I-D.ietf-dhc-anonymity-profile] 12.2. Informative References
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-00 (work in progress), May 2015.
[I-D.ietf-softwire-map-dhcp] [DHCP-Anonymity]
Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for profile for DHCP clients", Work in Progress,
configuration of Softwire Address and Port Mapped draft-ietf-dhc-anonymity-profile-01, June 2015.
Clients", draft-ietf-softwire-map-dhcp-12 (work in
progress), March 2015.
[I-D.sun-dhc-port-set-option] [DHCP-Port-Set-Opt]
Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, Sun, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair,
"Dynamic Host Configuration Protocol (DHCP) Option for "Dynamic Host Configuration Protocol (DHCP) Option for
Port Set Assignment", draft-sun-dhc-port-set-option-02 Port Set Assignment", Work in Progress,
(work in progress), October 2013. 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 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May Configuration of IPv4 Link-Local Addresses", RFC 3927,
2005. DOI 10.17487/RFC3927, May 2005,
<http://www.rfc-editor.org/info/rfc3927>.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508, Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009. DOI 10.17487/RFC5508, April 2009,
<http://www.rfc-editor.org/info/rfc5508>.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
Roberts, "Issues with IP Address Sharing", RFC 6269, June P. Roberts, "Issues with IP Address Sharing", RFC 6269,
2011. DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165,
6335, August 2011. RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
IPv4 Address Shortage", RFC 6346, August 2011. the IPv4 Address Shortage", RFC 6346, DOI 10.17487/
RFC6346, August 2011,
<http://www.rfc-editor.org/info/rfc6346>.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
and H. Ashida, "Common Requirements for Carrier-Grade NATs A., and H. Ashida, "Common Requirements for Carrier-Grade
(CGNs)", BCP 127, RFC 6888, April 2013. 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 Authors' Addresses
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China China
Phone: +86-10-6260-3059 Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China China
Phone: +86-10-6278-5822 Phone: +86-10-62785822
Email: sunqi@csnet1.cs.tsinghua.edu.cn Email: sunqi.ietf@gmail.com
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151 CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227 Bonn, NRW 53227
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Yiu L. Lee Yiu L. Lee
Comcast Comcast
One Comcast Center One Comcast Center
Philadelphia PA 19103 Philadelphia, PA 19103
USA United States
Email: yiu_lee@cable.comcast.com Email: yiu_lee@cable.comcast.com
Qiong Sun Qiong Sun
China Telecom China Telecom
Room 708, No.118, Xizhimennei Street Room 708, No.118, Xizhimennei Street
Beijing 100035 Beijing 100035
P.R. China China
Phone: +86-10-58552936 Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn Email: sunqiong@ctbri.com.cn
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 107 change blocks. 
277 lines changed or deleted 301 lines changed or added

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