draft-ietf-v6ops-nat64-experience-05.txt   draft-ietf-v6ops-nat64-experience-06.txt 
Internet Engineering Task Force G. Chen Internet Engineering Task Force G. Chen
Internet-Draft Z. Cao Internet-Draft Z. Cao
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: June 12, 2014 C. Xie Expires: June 21, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
December 9, 2013 December 18, 2013
NAT64 Operational Experience NAT64 Operational Experience
draft-ietf-v6ops-nat64-experience-05 draft-ietf-v6ops-nat64-experience-06
Abstract Abstract
This document summarizes NAT64 function deployment scenarios and This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document. NAT64 server Front End (NAT64-FE) are considered in this document.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 June 12, 2014. This Internet-Draft will expire on June 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Testing Results of Application Behavior . . . . . . 19 Appendix A. Testing Results of Application Behavior . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet IPv6 is the only sustainable solution for numbering nodes on Internet
due to the IPv4 depletion. Network operators have to deploy due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding IPv6-only networks in order to meet the needs of the expanding
internet without available IPv4 addresses. internet without available IPv4 addresses.
Single stack IPv6 network deployment can simplify network's Single stack IPv6 network deployment can simplify network's
provisioning. Some justifications have been described in 464xlat provisioning. Some justifications have been described in 464xlat
skipping to change at page 11, line 32 skipping to change at page 11, line 32
6.1. Service Reachability 6.1. Service Reachability
NAT64 is providing a translation capability between IPv6 and IPv4 NAT64 is providing a translation capability between IPv6 and IPv4
end-nodes. In order to provide the reachability between two IP end-nodes. In order to provide the reachability between two IP
address families, NAT64-CGN has to implement appropriate application address families, NAT64-CGN has to implement appropriate application
aware functions, i.e. Application Layer Gateway (ALG), where address aware functions, i.e. Application Layer Gateway (ALG), where address
translation is not itself sufficient and security mechanisms do not translation is not itself sufficient and security mechanisms do not
render it infeasible. Most NAT64-CGNs mainly provide FTP- render it infeasible. Most NAT64-CGNs mainly provide FTP-
ALG[RFC6384]. NAT64-FEs may have functional richness on Load ALG[RFC6384]. NAT64-FEs may have functional richness on Load
Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have
been supported. It should be noted that ALGs may impact the been supported. Those application protocols exchange IP address and
performance on a NAT64 box to some extent. ISPs as well as content port parameters within control session, for example the "Via" filed
providers might choose to avoid situations where the imposition of an in a HTTP header, "Transport" field in a RTSP SETUP message and
ALG might be required. At the same time, it is also important to "Received: " header in a SMTP message. ALG functions will detect
remind customers and application developers that IPv6 end-to-end those fields and make IP address translations. It should be noted
usage does not require ALG imposition and therefore results in a that ALGs may impact the performance on a NAT64 box to some extent.
better overall user experience. ISPs as well as content providers might choose to avoid situations
where the imposition of an ALG might be required. At the same time,
it is also important to remind customers and application developers
that IPv6 end-to-end usage does not require ALG imposition and
therefore results in a better overall user experience.
The service reachability is also subject to the IPv6 support in the The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports. below table to verify the IPv6 supports. The experiences of some
applications are still align with [RFC6586]. It has been found there
are some software issues to support IPv6 at this time. The software
could benefit from 464xlat[RFC6877] to be able to access IPv6
networks without requiring software upgrades. A SIP based voice call
has been tested in LTE mobile environment as specified in [IR.92].
The voice call is failed due to the lack of NAT64 traversal when an
IPv6 SIP user agent communicates with an IPv4 SIP user agent. In
order to address the failure, Interactive Connectivity Establishment
(ICE) described in [RFC5245]is recommended to be supported for the
SIP IPv6 transition. [RFC6157] describes both signaling and media
layer process, which should be followed. In addition, it may be
worth to notice that ICE is not only useful for NAT traversal, but
also firewall[RFC6092] traversal in native IPv6 deployment.
Table 1: The tested applications Different IPsec modes for VPN services have been tested, including
+----------------+----------------------------------------------------+ IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive
| APPs | Results and Found Issues | since the destination host detects the IP header changes and
+----------------+----------------------------------------------------+ invalidate the packets. For the IPsec-ESP mode, the failure happens
| Webservices |Mostly pass, some failure cases due to IPv4 Literals| because the function of NAT-Traversal in the IKE[RFC3947] is missed
+----------------+----------------------------------------------------+ on the NAT64 gateway. NAT64 can't update the TCP/UDP checksum, which
|Instance Message|Mostly fail, softwares don't support IPv6 | is encrypted. The destination host is failed to validate the
+----------------+----------------------------------------------------+ received packets.
| Games |Mostly pass for web-based games and mostly fail for |
| |standalone games due to software supports |
+----------------+----------------------------------------------------+
| P2P |Mostly fail, tracker is unable to support IPv6 peer |
| |or some software can't use IPv6 connections |
+----------------+----------------------------------------------------+
| FTP | Pass |
+----------------+----------------------------------------------------+
| Email | Pass |
+----------------+----------------------------------------------------+
| VoIP | Fail, due to the lack of SIP-ALG support on NAT64 |
+----------------+----------------------------------------------------+
| VPN | Fail, due to incapability of IPsec verification |
+----------------+----------------------------------------------------+
The experiences of some applications are still align with [RFC6586]. Table 1: The tested applications
In addition, we tested several P2P softwares including BitTorrent, +----------------+----------------------------------------------------+
Thunder, PPS TV and eMule. Some failures happened because local | APPs | Results and Found Issues |.
tracker servers don't setup with IPv6 extension patch or software +----------------+----------------------------------------------------+
can't support IPv6. For VoIP services, we mainly tested Voice over | Webservice |Mostly pass, some failure cases due to IPv4 Literals|
LTE services[IR.92], which is the major solution for voice in the +----------------+----------------------------------------------------+
fourth generation communication ages. NAT64 is testified with some |Instant Message |Mostly fail, software can't support IPv6 |
issues of SIP-ALG supports. In regard to the widespread applications +----------------+----------------------------------------------------+
of VoLTE in the near future, SIP-ALG is of great value to be | Games |Mostly pass for web-based games; mostly fail for |
implemented on NAT64-CGN. | |standalone games due to the lack of IPv6 support in |
| |software |
+----------------+----------------------------------------------------+
| SIP-VoIP |Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+
| IPsec-VPN |Fail, the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+
| P2P |Mostly fail, software can't support IPv6 |
+----------------+----------------------------------------------------+
| FTP |Pass |
+----------------+----------------------------------------------------+
| Email |Pass |
+----------------+----------------------------------------------------+
6.2. Resource Reservation 6.2. Resource Reservation
Session status normally is managed by a static timer. For example, Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP the value of the "established connection idle-timeout" for TCP
sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 sessions must not be less than 2 hours 4 minutes[RFC5382] and 5
minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe
significantly consumed by largely inactive users. The NAT translator significantly consumed by largely inactive users. The NAT translator
and other customers would suffer from service degradation due to port and other customers would suffer from service degradation due to port
consummation by other subscribers using the same NAT64 device. A consummation by other subscribers using the same NAT64 device. A
skipping to change at page 14, line 4 skipping to change at page 14, line 18
IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB
smaller than 1280 bytes. Such an operational consideration is hard smaller than 1280 bytes. Such an operational consideration is hard
to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged.
However, it's a feasible approach in NAT64-FE cases, since a IPv4 However, it's a feasible approach in NAT64-FE cases, since a IPv4
network NAT64-FE connected is rather well-organized and operated by a network NAT64-FE connected is rather well-organized and operated by a
IDC operator or content provider. Therefore, the MTU of IPv4 network IDC operator or content provider. Therefore, the MTU of IPv4 network
in NAT64-FE case are strongly recommended to set to more than 1260 in NAT64-FE case are strongly recommended to set to more than 1260
bytes. bytes.
8. ULA Usages 8. ULA Usages
Unique Local Addresses (ULAs) are defined in [RFC4193] to be Unique Local Addresses (ULAs) are defined in [RFC4193] to be
renumbered within a network site for local communications. Operators renumbered within a network site for local communications. Operators
may use ULAs as NAT64 prefixes to provide site-local IPv6 may use ULAs as NAT64 prefixes to provide site-local IPv6
connectivity. Those ULA prefixes are stripped when the packets going connectivity. Those ULA prefixes are stripped when the packets going
to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site.
The use of ULAs could help in identifying the translation The use of ULAs could help in identifying the translation
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided traffic.[I-D.ietf-v6ops-ula-usage-recommendations] provides further
further guidance for the ULAs usages. guidance for the ULAs usages.
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is
only assigned with an IPv6 address and connected to NAT64-CGN, when only assigned with an IPv6 address and connected to NAT64-CGN, when
connect to an IPv4 service, it would receive AAAA record generated by connect to an IPv4 service, it would receive AAAA record generated by
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will
be selected as the source address to the ULA destination address. be selected as the source address to the ULA destination address.
When the host has both IPv4 and IPv6 address, it would initiate both When the host has both IPv4 and IPv6 address, it would initiate both
A and AAAA record lookup, then both original A record and A and AAAA record lookup, then both original A record and
DNS64-generated AAAA record would be received. A host, which is DNS64-generated AAAA record would be received. A host, which is
compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4
skipping to change at page 16, line 4 skipping to change at page 16, line 22
QiBo Niu QiBo Niu
ZTE ZTE
50,RuanJian Road. 50,RuanJian Road.
YuHua District, YuHua District,
Nan Jing 210012 Nan Jing 210012
P.R.China P.R.China
Email: niu.qibo@zte.com.cn Email: niu.qibo@zte.com.cn
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-appsawg-http-forwarded] [I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress), draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012. October 2012.
[I-D.wing-dhc-dns-reconfigure]
Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6
Dynamic Reconfiguration", draft-wing-dhc-dns-
reconfigure-02 (work in progress), September 2013.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and Diameter", Aboba, "Carrying Location Objects in RADIUS and Diameter",
RFC 5580, August 2009. RFC 5580, August 2009.
skipping to change at page 17, line 17 skipping to change at page 17, line 40
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)", RFC
6157, April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011. for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
skipping to change at page 19, line 8 skipping to change at page 19, line 32
[I-D.ietf-v6ops-ula-usage-recommendations] [I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of Liu, B., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-01 (work in progress), October 2013. recommendations-01 (work in progress), October 2013.
[I-D.kaliwoda-sunset4-dual-ipv6-coexist] [I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Kaliwoda, A. and D. Binet, "Co-existence of both dual- Kaliwoda, A. and D. Binet, "Co-existence of both dual-
stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
ipv6-coexist-01 (work in progress), October 2012. ipv6-coexist-01 (work in progress), October 2012.
[I-D.wing-dhc-dns-reconfigure]
Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6
Dynamic Reconfiguration", draft-wing-dhc-dns-
reconfigure-02 (work in progress), September 2013.
[IR.92] Global System for Mobile Communications Association [IR.92] Global System for Mobile Communications Association
(GSMA), , "IMS Profile for Voice and SMS Version 7.0", (GSMA), , "IMS Profile for Voice and SMS Version 7.0",
March 2013. March 2013.
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010. Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[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, January
2011. 2011.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January
2011.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011. 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011. IPv4 Address Shortage", RFC 6346, August 2011.
 End of changes. 20 change blocks. 
56 lines changed or deleted 91 lines changed or added

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