[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-jiang-v6ops-incremental-cgn) 00 01 02 03 RFC 6264

Network Working Group                                        S. Jiang
Internet Draft                                                 D. Guo
Intended status: Informational            Huawei Technologies Co., Ltd
Expires: April 12, 2010                                   B. Carpenter
                                                University of Auckland
                                                      October 11, 2010

       An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
                draft-ietf-v6ops-incremental-cgn-02.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 12, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Abstract

   Global IPv6 deployment was slower than originally expected. As IPv4
   address exhaustion approaches, the IPv4 to IPv6 transition issues
   become more critical and less tractable. Host-based transition



Jiang, et al.          Expires April 12, 2011                 [Page 1]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   mechanisms used in dual stack environments are not able to meet the
   transition requirements. Most end users are not sufficiently expert
   to configure or maintain host-based transition mechanisms. Carrier-
   Grade NAT (CGN) devices with integrated transition mechanisms can
   reduce the operational change required during the IPv4 to IPv6
   migration or coexistence period.

   This document proposes an incremental CGN approach for IPv6
   transition. It can provide IPv6 access services for IPv6-enabled
   hosts and IPv4 access services for IPv4 hosts while leaving much of a
   legacy IPv4 ISP network unchanged. It is suitable for the initial
   stage of IPv4 to IPv6 migration. Unlike NAT444 based CGN alone,
   Incremental CGN also supports and encourages transition towards dual-
   stack or IPv6-only ISP networks. A smooth transition to IPv6
   deployment is also described in this document.

   An integrated configurable CGN device and an adaptive Home Gateway
   (HG) device are introduced. Both HG and CGN are re-usable devices
   during different transition periods. It avoids potential multiple
   upgrades. It enables IPv6 migration to be incrementally achieved
   according to the real user requirements.



Table of Contents

   1. Introduction................................................3
   2. An Incremental CGN Approach..................................4
      2.1. Incremental CGN Approach Overview.......................4
      2.2. Choice of tunneling technology..........................5
      2.3. Behavior of Dual-stack Home Gateway.....................6
      2.4. Behavior of Dual-stack CGN..............................6
      2.5. Impact for existing hosts and unchanged networks.........7
      2.6. IPv4/IPv6 intercommunication............................7
      2.7. Discussion.............................................7
   3. Smooth transition towards IPv6 infrastructure................8
   4. Security Considerations......................................9
   5. IANA Considerations.........................................9
   6. Acknowledgements............................................9
   7. Change Log [RFC Editor please remove].......................10
   8. References.................................................11
      8.1. Normative References...................................11
      8.2. Informative References.................................11
   Author's Addresses............................................13





Jiang, et al.          Expires April 12, 2011                 [Page 2]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010



1. Introduction

   Global IPv6 deployment did not happen as was forecast 10 years ago.
   Network providers were hesitant to take the first move while IPv4 was
   and is still working well. However, IPv4 address exhaustion is
   imminent. The dynamically-updated IPv4 Address Report [IPUSAGE] has
   analyzed this issue. It predicts early 2011 for IANA unallocated
   address pool exhaustion and middle 2012 for RIR unallocated address
   pool exhaustion. Based on this fact, the Internet industry appears to
   have reached consensus that global IPv6 deployment is inevitable and
   has to be done expediently.

   IPv4 to IPv6 transition issues therefore become more critical and
   complicated for the soon-coming global IPv6 deployment. Host-based
   transition mechanisms alone are not able to meet the requirements in
   all cases. Therefore, network supporting functions and/or new
   transition mechanisms with simple user-side operation are needed.

   Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN,
   alone compounds IPv4 operational problems, but does nothing to
   encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows
   ISPs to delay the transition, and therefore increased double
   transition costs (once to add CGN, and again to support IPv6).

   CGN deployments that integrate multiple transition mechanisms can
   simplify the operation of end user services during the IPv4 to IPv6
   migration and coexistence periods. CGNs are deployed on the network
   side and managed/maintained by professionals. On the user side, new
   Home Gateway (HG) devices may be needed too. They may be provided by
   network providers, depending on the specific business model. Dual-
   stack lite [I-D.ietf-softwire-dual-stack-lite], also called DS-Lite,
   is a CGN-based solution that supports transition, but it requires the
   ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to
   do this as the first step. Theoretically, DS-Lite can be used with
   double encapsulation (IPv4-in-IPv6-in-IPv4) but this seems even less
   likely to be accepted by an ISP and is not discussed in this
   document.

   This document proposes an incremental CGN approach for IPv6
   transition. The approach is similar to DS-Lite, but the other way
   around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling
   functions. It can provide IPv6 access services for IPv6-enabled hosts
   and IPv4 access services for IPv4 hosts, while leaving most of legacy
   IPv4 ISP networks unchanged. The deployment of this technology does
   not affect legacy IPv4 hosts with global IPv4 addresses at all. It is



Jiang, et al.          Expires April 12, 2011                 [Page 3]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   suitable for the initial stage of IPv4 to IPv6 migration. It also
   supports transition towards dual-stack or IPv6-only ISP networks.

   A smooth transition mechanism is also described in this document. It
   introduces an integrated configurable CGN device and an adaptive HG
   device. Both CGN and HG are re-usable devices during different
   transition periods. It avoid potential multiple upgrade. It enables
   IPv6 migration to be incrementally achieved according to the real
   user requirements.

2. An Incremental CGN Approach

   Most consumers remain primarily IPv4. Network providers are starting
   to provide IPv6 access services for end users. At the initial stage
   of IPv4 to IPv6 migration, IPv4 connectivity and traffic would
   continue to represent the majority of traffic for most ISP networks.
   ISPs would like to minimize the changes to their IPv4 networks.
   Switching the whole ISP network into IPv6-only would be considered as
   a radical strategy. Switching the whole ISP network to dual stack is
   less radical, but introduces operational costs and complications.
   Although some ISPs have successfully deployed dual stack networks,
   others prefer not to do this as their first step in IPv6. However,
   they currently face two urgent pressures - to compensate for an
   immediate shortage of IPv4 addresses by deploying some method of
   address sharing, and to prepare actively for the use of deployment of
   IPv6 address space and services. ISPs facing only one pressure out of
   two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
   (to provide IPv6 connectivity services). The approach described in
   this draft is intended to address both of these pressures at the same
   time by combining v4-v4 CGN with v6-over-v4 tunneling technologies.

2.1. Incremental CGN Approach Overview

   The incremental CGN approach we propose is illustrated as the
   following figure.













Jiang, et al.          Expires April 12, 2011                 [Page 4]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


                                 +-------------+
                                 |IPv6 Internet|
                                 +-------------+
                                       |
                         +-------------+----------+
     +-----+    +--+     | IPv4 ISP +--+--+       |   +--------+
     |v4/v6|----|DS|=====+==========| CGN |-------+---|  IPv4  |
     |Host |    |HG|     |  Network +-----+   |   |   |Internet|
     +-----+    +--+     +--------------------+---+   +--------+
                  _ _ _ _ _ _ _ _ _ _ _       |
                ()_6_o_4_ _t_u_n_n_e_l_()  +---------------------+
                                           | Existing IPv4 hosts |
                                           +---------------------+

    Figure 1: incremental CGN approach with IPv4 ISP network

   DS HG = Dual-Stack Home Gateway (CPE).

   As shown in the above figure, the ISP has not significantly changed
   its IPv4 network. This approach enables IPv4 hosts to access the IPv4
   Internet and IPv6 hosts to access the IPv6 Internet. A dual stack
   host is treated as an IPv4 host when it uses IPv4 access service and
   as an IPv6 host when it uses an IPv6 access service. In order to
   enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
   access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
   can be integrated with the CGN. The integration of such mechanisms is
   out of scope for this document

   Two new types of devices need to be deployed in this approach: a
   dual-stack home gateway, which may follow the requirements of
   [I-D.ietf-v6ops-ipv6-cpe-router], and a dual-stack CGN. The dual-
   stack home gateway integrates IPv4 forwarding and v6-over-v4
   tunneling functions. It may integrate v4-v4 NAT functionality, too.
   The dual-stack CGN integrates v6-over-v4 tunneling and v4-v4 CGN
   functions.

2.2. Choice of tunneling technology

   In principle, this model will work with any form of tunnel between
   the DS HG and the dual-stack CGN. However, tunnels that require
   individual configuration are clearly undesirable because of their
   operational cost. Configured tunnels based directly on [RFC4213] are
   therefore not suitable. A tunnel broker according to [RFC3053] would
   also have high operational costs.

   Modified 6RD [RFC5569, RFC5969] technology appears suitable to
   support v6-over-v4 tunneling with low operational cost. Modified GRE


Jiang, et al.          Expires April 12, 2011                 [Page 5]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   [RFC2784] with additional auto-configuration mechanism is also
   suitable to support v6-over-v4 tunneling. Other tunneling mechanisms
   such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise
   Traversal (VET) [RFC5558] are also considered. If the ISP has an
   entirely MPLS infrastructure between the HG and the dual-stack CGN,
   it would also be possible to consider a 6PE [RFC4798] tunnel directly
   over MPLS. This would, however, only be suitable for an advanced HG
   that is unlikely to be found as a consumer device, and is not further
   discussed here.

2.3. Behavior of Dual-stack Home Gateway

   When a dual-stack home gateway receives a data packet from a host, it
   firstly checks whether the packet is IPv4 or IPv6. For IPv4 data, the
   HG can directly forward it to CGN in the absence of v4-v4 NAT on the
   HG. Alternatively the HG translates packet source address from a HG-
   scope private IPv4 address into a CGN-scope private IPv4 address, and
   then forwards it towards the CGN. The HG records the v4-v4 address
   mapping information for inbound packets, just like a normal NAT
   gateway does.

   For IPv6 data, the HG needs to encapsulate the data into an IPv4
   tunnel, which has the dual-stack CGN as the other end. The HG sends
   the new IPv4 packet towards CGN.

   The HG records the mapping information between the tunnel and the
   source IPv6 address for inbound packets if HG uplinks to more than
   one CGN. Detailed considerations for the use of multiple CGNs by one
   HG are for further study.

2.4. Behavior of Dual-stack CGN

   When a dual-stack CGN receives a data packet from a dual-stack home
   gateway, it firstly checks whether the packet is a normal IPv4 packet
   or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
   translates packet source address from a CGN-scope private IPv4
   address into a public IPv4 address, and then send it to IPv4
   Internet. The CGN records the v4-v4 address mapping information for
   inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
   packet, the CGN needs to decapsulate it into the original IPv6 packet
   and then send it to IPv6 Internet. The CGN records the mapping
   information between the tunnel and the source IPv6 address for
   inbound packets.

   Depending on the deployed location of the CGN, it may use v6-over-v4
   tunnels to connect to the IPv6 Internet.


Jiang, et al.          Expires April 12, 2011                 [Page 6]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


2.5. Impact for existing hosts and unchanged networks

   This approach does not affect the unchanged networks at all. Legacy
   IPv4 ISP networks and their IPv4 devices remain in use. The existing
   IPv4 hosts, shown as the right box in Figure 1, either having global
   IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it
   is now. These hosts, if they are upgraded to become dual-stack hosts,
   can access IPv6 Internet through the IPv4 ISP network by using IPv6-
   over-IPv4 tunnel technologies.

2.6. IPv4/IPv6 intercommunication

   IPv6-only public services are not expected as long as there is
   significant IPv4-only customer base in the world, for obvious
   commercial reasons. However, IPv4/IPv6 intercommunication may become
   issues in many scenarios.

   An ISP can provide its IPv6-only customers with a network-layer
   translation service to satisfy this need. Such a service is not fully
   defined at this time, so we refer to it non-specifically as "NAT64".
   Current work in the IETF is focused on one particular proposal
   [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
   provided as a common service located at the border between the ISP
   and the IPv4 Internet, beyond the dual stack CGN from the customer's
   viewpoint. It may be integrated into CGN devices too.

   [I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a
   DS-lite solution with an additional feature to ease interconnection
   between IPv4 and IPv6 realms. Home users may encounter the problem of
   reaching legacy IPv4-only public services from IPv6-only clients.
   This problem already exists in early phases, but will become more
   serious over time.

2.7. Discussion

   For IPv4 traffic, the incremental CGN approach inherits all the
   problems of CGN address sharing techniques
   [I-D.ietf-intarea-shared-addressing-issues] (e.g., scaling, and the
   difficulty of supporting well-known ports for inbound traffic).
   Application layer problems created by double NAT are for further
   study.

   If a different technology than v4-v4 NAT is chosen for IPv4 address
   sharing, for example [I-D.ymbk-aplusp], the present approach could be
   suitably modified, for example replacing the v4-v4 NAT function by
   the A+P gateway function.



Jiang, et al.          Expires April 12, 2011                 [Page 7]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   For IPv6 traffic, a user behind the DS HG will see normal IPv6
   service. We observe that an IPv6 tunnel MTU of at least 1500 bytes
   would ensure that the mechanism does not cause excessive
   fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery
   interactions.

   For IPv6 traffic, a user behind the DS HG will see normal IPv6
   service. This, and the absence of NAT problems for IPv6, will create
   an incentive for users and application service providers to prefer
   IPv6.

   ICMP filtering [RFC4890] function may be included as part of CGN
   functions.

3. Smooth transition towards IPv6 infrastructure

   The incremental CGN approach can easily be transited from NAT444 CGN
   or 6rd. NAT444 CGN solves the public address shortage issues in the
   current IPv4 infrastructure. However, it does not contribute towards
   IPv6 deployment at all. The incremental CGN approach can inherit
   NAT444 CGN function while providing overlay IPv6 services. 6rd
   mechanisms can also transform into this incremental CGN with small
   modifications. One consideration is that home gateways also have to
   be changed correspondently.

   The incremental CGN can also easily be transited into IPv6-enabled
   infrastructure, in which the ISP network is either dual-stack or
   IPv6-only. For dual-stack ISP networks, dual-stack home gateways can
   simply switch off the v6-over-v4 function and forward both IPv6 and
   IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4
   NAT function. This approach is considered an unlikely choice, since
   we expect ISPs to choose the approach described as incremental CGN
   here because they want to avoid or are unable to complete dual-stack
   deployment completely. For IPv6-only ISP networks, the DS-Lite
   solution also needs dual-stack home gateway and CGN devices.



   The best model for the incremental CGN approach is that an integrated
   configurable CGN device and an adaptive HG device. The integrated CGN
   hardware may integrate multiple functions, include NAT444 CGN, 6rd
   router, incremental CGN, DS-Lite CGN and dual-stack forwarding. The
   HG has to integrate these correspondent functions, and be able to
   detect changes on the CGN side.

   For example, the appearance of IPv6 Route Advertisement messages or
   DHCPv6 messages can be used as a signal the availability of DS-Lite


Jiang, et al.          Expires April 12, 2011                 [Page 8]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   CGN. When an ISP decides to switch from incremental CGN to DS-Lite
   CGN, it may be that only a configuration change or a minor software
   update is needed on the CGNs. The home gateway can then detect this
   change and switch automatically to DS-Lite mode. The only impact on
   the home user will be to receive a different IPv6 prefix.

   In the smooth transition model, both CGN and HG are re-usable devices
   during different transition periods. It avoids the potential multiple
   upgrades. IPv6 migration may be incrementally achieved according to
   the real user requirements.

4. Security Considerations

   Security issues associated with NAT have been documented in [RFC2663]
   and [RFC2993].

   Further security analysis will be needed to understand double NAT
   security issues and tunnel security issues. However, since the tunnel
   proposed here exists entirely within a single ISP network, between
   the HG/CPE and the CGN, the threat model is relatively simple.
   [RFC4891] describes how to protect tunnels using IPSec, but it is not
   clear whether doing so would be an important requirement. An ISP
   could deem its infrastructure to provide adequate security without
   additional protection of the tunnels.

   The dual-stack home gateway will need to provide basic security
   functionality for IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other
   aspects are described in [RFC4864].

5. IANA Considerations

   This draft does not request any IANA action.

6. Acknowledgements

   Useful comments were made by Fred Baker, Dan Wing, Fred Templin,
   Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair,
   Shin Miyakawa, Joel Jaeggli and other members of the IETF V6OPS
   working group.









Jiang, et al.          Expires April 12, 2011                 [Page 9]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010




7. Change Log [RFC Editor please remove]

   draft-jiang-incremental-cgn-00, original version, 2009-02-27

   draft-jiang-v6ops-incremental-cgn-00, revised after comments at
   IETF74, 2009-04-23

   draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops
   mailing list, 2009-06-30

   draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be
   documented in other WGs), 2009-07-06

   draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops
   mailing list, 2009-09-24

   draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg document,
   2009-11-17

   draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops
   mailing list, 2010-06-21

   draft-ietf-v6ops-incremental-cgn-02, revised after comments at v6ops
   WGLC, 2010-10-11






















Jiang, et al.          Expires April 12, 2011                [Page 10]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010




8. References

8.1. Normative References

   [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4
             Domains without Explicit Tunnels", RFC2529, March 1999.

   [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina,
             "Generic Routing Encapsulation (GRE)", RFC 2784, March
             2000.

   [RFC5969] W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider
             Networks '6rd'", RFC5969, May 2010.

8.2. Informative References

   [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC 2663,
             August 1999.

   [RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation
             - Protocol Translation (NAT-PT)", RFC 2766, February 2000.

   [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993,
             November 2000.

   [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6
             Tunnel Broker", RFC 3053, January 2001.

   [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via
             IPv4 Clouds", RFC 3056, February 2001.

   [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms
             for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4798] J. De Clercq, D. Ooms, S. Prevost and F. Le Faucheur,
             "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
             Edge Routers (6PE)", RFC 4798, February 2007.

   [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E.
             Klein, "Local Network Protection for IPv6", RFC 4864, May
             2007.

   [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering
             ICMPv6 Messages in Firewalls", RFC 4890, May 2007.


Jiang, et al.          Expires April 12, 2011                [Page 11]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
             RFC4891, May 2007.

   [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address
             Translator - Protocol Translator (NAT-PT) to Historic
             Status", RFC 4966, July 2007.

   [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic
             Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.

   [RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558,
             February 2010.

   [RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures
             (6rd)", RFC 5569, January 2010.

   [IPUSAGE] G. Huston, IPv4 Address Report, March 2009,
             http://www.potaroo.net/tools/ipv4/index.html.

   [I-D.ietf-softwire-dual-stack-lite]
             A. Durand, "Dual-stack lite broadband deployments post IPv4
             exhaustion", draft-ietf-softwire-dual-stack-lite, work in
             progress.

   [I-D.ietf-v6ops-ipv6-cpe-router]
             H. Singh, W. Beebee, C. Donley, B. Stark and O. Troan,
             "IPv6 CPE Router Recommendations", draft-ietf-v6ops-ipv6-
             cpe-router, work in progress.

   [I-D.ietf-v6ops-cpe-simple-security]
             J. Woodyatt, "Recommended Simple Security Capabilities in
             Customer Premises Equipment for Providing Residential IPv6
             Internet Service", draft-ietf-v6ops-cpe-simple-security,
             work in progress.

   [I-D.ietf-behave-v6v4-xlate-stateful]
             M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network
             Address and Protocol Translation from IPv6 Clients to IPv4
             Servers", draft-ietf-behave-v6v4-xlate-stateful, work in
             progress.

   [I-D.ietf-intarea-shared-addressing-issues]
             M. Ford, et al, "Issues with IP Address Sharing", draft-
             ietf-intarea-shared-addressing-issues, work in progress.





Jiang, et al.          Expires April 12, 2011                [Page 12]


Internet-Draft draft-ietf-v6ops-incremental-cgn-02.txt     October 2010


   [I-D.nishitani-cgn]
             I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H.
             Ashida, "Common requirements for IP address sharing
             schemes", draft-nishitani-cgn, work in progress.

   [I-D.ymbk-aplusp]
             R. Bush, "The A+P Approach to the IPv4 Address Shortage",
             draft-ymbk-aplusp, work in progress.

   [I-D.boucadair-dslite-interco-v4v6]
             M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection
             in the Context of DS-lite Deployment", draft-boucadair-
             dslite-interco-v4v6, work in progress.



Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: shengjiang@huawei.com

   Dayong Guo
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: guoseu@huawei.com

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland, 1142
   New Zealand
   Email: brian.e.carpenter@gmail.com









Jiang, et al.          Expires April 12, 2011                [Page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/