draft-ietf-sunset4-nat64-port-allocation-01.txt   draft-ietf-sunset4-nat64-port-allocation-02.txt 
Network Working Group G. Chen Network Working Group G. Chen
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational W. Li Intended status: Informational W. Li
Expires: January 23, 2016 China Telecom Expires: July 21, 2016 China Telecom
T. Tsou T. Tsou
J. Huang J. Huang
Huawei Technologies Huawei Technologies
T. Taylor T. Taylor
PT Taylor Consulting PT Taylor Consulting
JF. Tremblay JF. Tremblay
Viagenie Viagenie
July 22, 2015 January 18, 2016
Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses
draft-ietf-sunset4-nat64-port-allocation-01 draft-ietf-sunset4-nat64-port-allocation-02
Abstract Abstract
This document enumerates methods of port assignment in Carrier Grade This document enumerates methods of port assignment in Carrier Grade
NATs (CGNs), focused particularly on NAT64 environments. Different NATs (CGNs), focused particularly on NAT64 environments. Different
NAT port allocation methods have been categorized and described. A NAT port allocation methods have been categorized and described. A
series of port allocation design principles has been proposed to series of port allocation design principle has been proposed to
facilitate the implementations and deployment. facilitate the implementations and deployment.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 23, 2016. This Internet-Draft will expire on July 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 7 2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 7
3. Port Allocation Design Principles . . . . . . . . . . . . . . 7 3. Port Allocation Design Principles . . . . . . . . . . . . . . 7
3.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 7 3.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 7
3.2. Connectivity State Optimization . . . . . . . . . . . . . 9 3.2. Connectivity State Optimization . . . . . . . . . . . . . 9
3.3. Port Randomization . . . . . . . . . . . . . . . . . . . 9 3.3. Port Randomization . . . . . . . . . . . . . . . . . . . 9
3.4. Port-range Implementation Recommendation . . . . . . . . 10 3.4. Port-range Implementation Recommendation . . . . . . . . 10
3.4.1. Port Randomization and Port-Range Deallocation . . . 10 3.4.1. Port Randomization and Port-Range Deallocation . . . 10
3.4.2. Issues Of Traceability . . . . . . . . . . . . . . . 11 3.4.2. Issues Of Traceability . . . . . . . . . . . . . . . 11
3.4.3. Other Considerations . . . . . . . . . . . . . . . . 12 3.4.3. Other Considerations . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
As a result of the depletion of public IPv4 addresses, Carrier Grade As a result of the depletion of public IPv4 addresses, Carrier Grade
NAT (CGN) has been adopted by ISPs to share the available IPv4 NAT (CGN) has been adopted by ISPs to share the available IPv4
skipping to change at page 4, line 22 skipping to change at page 4, line 22
that the global address could be recycled for later use. This that the global address could be recycled for later use. This
increases the efficiency of usage of IPv4 resources. increases the efficiency of usage of IPv4 resources.
o Stateless o Stateless
Stateless NAT is performed in compliance with [RFC6145]. The Stateless NAT is performed in compliance with [RFC6145]. The
public IPv4 address is required to be embedded in the IPv6 public IPv4 address is required to be embedded in the IPv6
address. Thus the NAT64 can directly extract the address and has address. Thus the NAT64 can directly extract the address and has
no need to record mapping states. no need to record mapping states.
A promising usage of stateless NAT may appear in the data centre A promising usage of stateless NAT may appear in a data centre
environment where IPv6 server pools receive inbound connections from environment where IPv6 server pools receive inbound connections from
IPv4 users externally [I-D.ietf-v6ops-siit-dc]. NAT usage in other IPv4 users externally [I-D.ietf-v6ops-siit-dc]. NAT usage in other
cases may be controversial. First off, the static one-to-one mapping cases may be controversial. First off, the static one-to-one mapping
does not address the issue of IPv4 depletion. Secondly, it does not address the issue of IPv4 depletion. Secondly, it
introduces a dependency between IPv4 and IPv6 addressing. That introduces a dependency between IPv4 and IPv6 addressing. That
creates other limitations since a change of IPv4 address will cause creates other limitations since a change of IPv4 address will cause
renumbering of IPv6 addresses. renumbering of IPv6 addresses.
2.2.2. Dynamic vs. Static 2.2.2. Dynamic vs. Static
skipping to change at page 5, line 32 skipping to change at page 5, line 32
the interaction between port-range allocation and capacity impact the interaction between port-range allocation and capacity impact
are also applicable in the case of static assignment. [RFC7422] are also applicable in the case of static assignment. [RFC7422]
describes a deterministic algorithm to assign a port range for an describes a deterministic algorithm to assign a port range for an
internal IP address pool in a sequence. internal IP address pool in a sequence.
2.2.3. Centralized vs. Distributed 2.2.3. Centralized vs. Distributed
There is an increasing need to connect NAT64 with downstream There is an increasing need to connect NAT64 with downstream
NAT46-capable devices to support IPv4 users/applications on an NAT46-capable devices to support IPv4 users/applications on an
IPv6-only path. Several solutions have been proposed in this area, IPv6-only path. Several solutions have been proposed in this area,
e.g., 464xlat [RFC6877], MAP-T [I-D.ietf-softwire-map-t] and 4rd e.g., 464xlat [RFC6877], MAP-T [RFC7599] and 4rd [RFC7600]. Port
[I-D.ietf-softwire-4rd]. Port allocation can be categorized as a allocation can be categorized as a centralized assignment on NAT64 or
centralized assignment on NAT64 or as a port delegation distributed as a port delegation distributed to downstream devices (e.g, Customer
to downstream devices (e.g, Customer Edge connected with NAT64). Edge connected with NAT64).
o Centralized Assignment o Centralized Assignment
A centralized method makes port assignments once IP flows come to A centralized method makes port assignments once IP flows come to
the NAT64. The allocation policy is enforced on a centralized the NAT64. The allocation policy is enforced on a centralized
point. Either a dynamic or static port assignment is made for point. Either a dynamic or static port assignment is made for
received sessions. received sessions.
o Distributed Assignment o Distributed Assignment
NAT64 can also delegate the pre-allocated port range to customer NAT64 can also delegate the pre-allocated port range to customer
edge devices. That can be achieved through additional out-of-band edge devices. That can be achieved through additional out-of-band
provisioning signals (e.g., [I-D.ietf-pcp-port-set], provisioning signals (e.g., [I-D.ietf-pcp-port-set], [RFC7598]).
[I-D.ietf-softwire-map-dhcp]). The distributed model normally is The distributed model normally is performed A+P style [RFC6346]
performed A+P style [RFC6346] for static port assignment. The for static port assignment. The NAT64 should also hold the
NAT64 should also hold the corresponding mapping in order to corresponding mapping in order to validate port usage in the
validate port usage in the outgoing direction and route inbound outgoing direction and route inbound packets. Delegated port
packets. Delegated port ranges shift NAT64 port computations/ ranges shift NAT64 port computations/states into downstream
states into downstream devices. The detailed benefits of this devices. The detailed benefits of this approach are documented in
approach are documented in
[I-D.ietf-softwire-stateless-4v6-motivation]. [I-D.ietf-softwire-stateless-4v6-motivation].
2.3. Port Allocation Solutions 2.3. Port Allocation Solutions
2.3.1. Stateful Technologies 2.3.1. Stateful Technologies
[RFC6146] describes a process where the dynamic binding is created by [RFC6146] describes a process where the dynamic binding is created by
an outgoing packet, but it may also be created by other means such as an outgoing packet, but it may also be created by other means such as
a Port Control Protocol request (see Section 2.3.3). Looking beyond a Port Control Protocol request (see Section 2.3.3). Looking beyond
NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in
skipping to change at page 6, line 32 skipping to change at page 6, line 31
implementations to use the proposals made in individual port implementations to use the proposals made in individual port
allocation and port range allocation allocation and port range allocation
2.3.2. Stateless Technologies 2.3.2. Stateless Technologies
The port allocation solutions that are being specified at the time of The port allocation solutions that are being specified at the time of
writing of this document are all variations on the static distributed writing of this document are all variations on the static distributed
model, to minimize the amount of state that has to be held in the model, to minimize the amount of state that has to be held in the
network. That work includes: network. That work includes:
o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which o Light-weight 4over6 (LW4o6 [RFC7596]), which requires the CPE to
requires the CPE to be configured explicitly with the shared IPv4 be configured explicitly with the shared IPv4 address and port set
address and port set it will use on the WAN side of its NAT44 it will use on the WAN side of its NAT44 function. The border
function. The border router is configured with the same router is configured with the same information, reducing the state
information, reducing the state it must hold from per-session to it must hold from per-session to per-subscriber amounts.
per-subscriber amounts.
o Mapping of Address and Port with Encapsulation (MAP-E o Mapping of Address and Port with Encapsulation (MAP-E [RFC7597])
[I-D.ietf-softwire-map]) and the experimental specifications and the experimental specifications Mapping of Address and Port
Mapping of Address and Port with Translation (MAP-T with Translation (MAP-T [RFC7599]) and 4rd [RFC7600], already
[I-D.ietf-softwire-map-t]) and 4rd [I-D.ietf-softwire-4rd], mentioned. These rely on an algorithmic embedding of WAN-side
already mentioned. These rely on an algorithmic embedding of WAN- IPv4 address and assigned port set within the IPv6 prefix assigned
side IPv4 address and assigned port set within the IPv6 prefix to each CPE. Both the CPE and the border router must be
assigned to each CPE. Both the CPE and the border router must be
configured with this information. However, the algorithm is configured with this information. However, the algorithm is
designed to aggregate routing information such that the amount of designed to aggregate routing information such that the amount of
state carried by the border router is of a lower order of state carried by the border router is of a lower order of
magnitude than even the per-subscriber level. magnitude than even the per-subscriber level.
All A+P variants support a 1-1 mapping mode, where the IPv4 and IPv6 All A+P variants support a 1-1 mapping mode, where the IPv4 and IPv6
addresses assigned to a CPE are independent. This can be helpful in addresses assigned to a CPE are independent. This can be helpful in
transition, but, as with LW4o6, raises the amount of state in the transition, but, as with LW4o6, raises the amount of state in the
network back to the per-subscriber level. network back to the per-subscriber level.
skipping to change at page 9, line 30 skipping to change at page 9, line 29
o Reducing the TIME-WAIT state. It is rather common that users o Reducing the TIME-WAIT state. It is rather common that users
change video channels often. Investigations have shown that 60% change video channels often. Investigations have shown that 60%
of videos are watched for less than 20% of their duration. The of videos are watched for less than 20% of their duration. The
user's access patterns may leave a number of the TIME-WAIT states. user's access patterns may leave a number of the TIME-WAIT states.
Therefore, acceleration of TIME-WAIT state transitions could Therefore, acceleration of TIME-WAIT state transitions could
increase the efficiency of port utilization. [RFC6191] defines a increase the efficiency of port utilization. [RFC6191] defines a
mechanism for reducing TIME-WAIT state by proposing TCP timestamps mechanism for reducing TIME-WAIT state by proposing TCP timestamps
and sequence numbers. and sequence numbers.
[I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying [I-D.ietf-tsvwg-behave-requirements-update] recommended applying
[RFC6191] and PAWS (Protect Against Wrapped Sequence numbers, [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers,
described in [RFC1323]) to NAT. This may also be a way to improve described in [RFC1323]) to NAT. This may also be a way to improve
port utilization. port utilization.
o Another possibility is to use Address-Dependent Mapping or Address o Another possibility is to use Address-Dependent Mapping or Address
and Port-Dependent Mapping [RFC4787] to increase port utilization. and Port-Dependent Mapping [RFC4787] to increase port utilization.
This feature has already been implemented on a vendor-specific This feature has already been implemented on a vendor-specific
basis. However, it should be noted that REQ-7 and REQ-12 in basis. However, it should be noted that REQ-7 and REQ-12 in
[RFC6888] may reduce the incentive to use anything but the [RFC6888] may reduce the incentive to use anything but the
Address-Independent Mapping behaviour recommended by [RFC4787]. Address-Independent Mapping behaviour recommended by [RFC4787].
skipping to change at page 14, line 30 skipping to change at page 14, line 26
author to continue this work. author to continue this work.
The authors of draft-tsou-behave-natx4-log-reduction have their own The authors of draft-tsou-behave-natx4-log-reduction have their own
thanks to give. Mohamed Boucadair reviewed the initial document and thanks to give. Mohamed Boucadair reviewed the initial document and
provided useful comments to improve it. Reinaldo Penno, Joel provided useful comments to improve it. Reinaldo Penno, Joel
Jaeggli, and Dan Wing provided comments on the subsequent version Jaeggli, and Dan Wing provided comments on the subsequent version
that resulted in major revisions. Serafim Petsis provided that resulted in major revisions. Serafim Petsis provided
encouragement to publication after a hiatus of two years. encouragement to publication after a hiatus of two years.
The present version of the document benefited from further comments The present version of the document benefited from further comments
by Lee Howard and Mohamed Boucadair. by Lee Howard, Mohamed Boucadair and Alberto Leiva.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>. <http://www.rfc-editor.org/info/rfc6056>.
skipping to change at page 15, line 19 skipping to change at page 15, line 14
7.2. Informative References 7.2. Informative References
[I-D.ietf-behave-syslog-nat-logging] [I-D.ietf-behave-syslog-nat-logging]
Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
Format for NAT Logging (Work in Progress)", January 2014. Format for NAT Logging (Work in Progress)", January 2014.
[I-D.ietf-pcp-port-set] [I-D.ietf-pcp-port-set]
Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
and S. Perrault, "Port Control Protocol (PCP) Extension and S. Perrault, "Port Control Protocol (PCP) Extension
for Port Set Allocation (Work in Progress)", November for Port Set Allocation (Work in Progress)", October 2015.
2014.
[I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd) (Work in Progress)", December 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP) (Work in Progress)", March 2015.
[I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Farrer, I., Perrault,
S., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
configuration of Softwire Address and Port Mapped Clients
(Work in Progress)", March 2015.
[I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T) (Work in progress)", December 2014.
[I-D.ietf-softwire-stateless-4v6-motivation] [I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions (Expired work Stateless IPv4 over IPv6 Migration Solutions (Expired work
in Progress)", November 2012. in Progress)", November 2012.
[I-D.ietf-v6ops-siit-dc] [I-D.ietf-tsvwg-behave-requirements-update]
Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for Penno, R., Perrault, S., Boucadair, M., Kamiset, S., and
IPv6 Data Centre Environments (Work in progress)",
December 2014.
[I-D.penno-behave-rfc4787-5382-5508-bis]
Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and
K. Naito, "Network Address Translation (NAT) Behavioral K. Naito, "Network Address Translation (NAT) Behavioral
Requirements Updates (expired Work in Progress)", January Requirements Updates (Work in Progress)", November 2015.
2013.
[I_D.ietf-softwire-lw4over6] [I-D.ietf-v6ops-siit-dc]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
Farrer, "Lightweight 4over6: An Extension to the DS-Lite IPv6 Data Centre Environments (Work in progress)", October
Architecture (Work in Progress)", November 2014. 2015.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <http://www.rfc-editor.org/info/rfc1323>. 1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>. 2007, <http://www.rfc-editor.org/info/rfc4787>.
skipping to change at page 17, line 43 skipping to change at page 17, line 11
Deployment Options and Experience", RFC 7269, Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014, DOI 10.17487/RFC7269, June 2014,
<http://www.rfc-editor.org/info/rfc7269>. <http://www.rfc-editor.org/info/rfc7269>.
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments", RFC 7422, Logging in Carrier-Grade NAT Deployments", RFC 7422,
DOI 10.17487/RFC7422, December 2014, DOI 10.17487/RFC7422, December 2014,
<http://www.rfc-editor.org/info/rfc7422>. <http://www.rfc-editor.org/info/rfc7422>.
[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>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[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>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
and M. Chen, "IPv4 Residual Deployment via IPv6 - A
Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
July 2015, <http://www.rfc-editor.org/info/rfc7600>.
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
53A,Xibianmennei Ave., 29, Jinrong Avenue
Xuanwu District, Xicheng District,
Beijing 100053 Beijing 100033
P.R. China China
Email: phdgang@gmail.com Email: phdgang@gmail.com, chengang@chinamobile.com
Weibo Li Weibo Li
China Telecom China Telecom
109, Zhongshan Ave. West, Tianhe District 109, Zhongshan Ave. West, Tianhe District
Guangzhou 510630 Guangzhou 510630
P.R. China P.R. China
Email: mweiboli@gmail.com Email: mweiboli@gmail.com
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
 End of changes. 21 change blocks. 
76 lines changed or deleted 72 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/