[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Internet Engineering Task Force                                   C. Sun
Internet-Draft                                               Softbank BB
Intended status: Informational                             S. Matsushima
Expires: September 16, 2011                             Softbank Telecom
                                                                 J. Jiao
                                                             Softbank BB
                                                          March 15, 2011


                      4rd Applicability Statement
                 draft-sun-intarea-4rd-applicability-01

Abstract

   This document discusses the applicability of the IPv4 Residual
   Deployment (4rd) protocol, and an address sharing mechanism, NAT44 on
   4rd CE side, and routing optimization to provide IPv4 connectivity in
   4rd capable IPv6-only networks.

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 September 16, 2011.

Copyright Notice

   Copyright (c) 2011 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



Sun, et al.            Expires September 16, 2011               [Page 1]


Internet-Draft              4rd Applicability                 March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of 4rd  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  IPv4 Address Assignment  . . . . . . . . . . . . . . . . .  4
     3.2.  IPv4 Address Sharing . . . . . . . . . . . . . . . . . . .  5
     3.3.  Distributing NAT function to CEs . . . . . . . . . . . . .  7
     3.4.  Routing optimization to provide IPv4 connectivity  . . . .  9
     3.5.  Gateway Redundancy Considerations  . . . . . . . . . . . . 10
     3.6.  NAT Log Considerations . . . . . . . . . . . . . . . . . . 11
   4.  Constraint Considerations  . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




























Sun, et al.            Expires September 16, 2011               [Page 2]


Internet-Draft              4rd Applicability                 March 2011


1.  Introduction

   The Internet continues to grow beyond the capabilities of IPv4.  The
   tremendous success of the Internet has strained the address space,
   which is no longer sufficient to support future growth.  The IANA
   free pool of IPv4 address have been depleted already.  With its
   increase in the number of available prefixes and addresses in a
   subnet, and improvement in address management, IPv6 is the only real
   option on the table.  During the long transition period from only
   IPv4 to IPv6, the networks of Internet Service Providers (ISPs) will
   have to offer more than just IPv6 connectivity.  Both outgoing and
   incoming connections will have to be supported.

   IPv4 Residual Deployment (4rd) enables a service provider to share
   IPv4 addresses among its customers by combining the well-known
   technologies of stateless address mapping and tunneling, NAT44, and
   IPv4 in IPv6 encapsulation.

   This document discusses the applicability of the 4rd protocol, and an
   address sharing mechanism, NAT44 on 4rd CE side, and routing
   optimization to provide IPv4 connectivity in 4rd capable IPv6-only
   networks.


2.  Overview of 4rd

   If 4rd [I-D.despres-intarea-4rd] is to be actually used across a
   IPv6-only network to offer IPv4 connectivity
   [I-D.arkko-ipv6-transition-guidelines], the network must have 4rd
   Border Relay Router (BR) and 4rd Customer Edge Router (CE).

   With 4rd, we need not worry that well-known (reserved) IPv4 addresses
   (such as 000/8) are generated, because all 4rd CEs generating IPv4
   addresses are in the range of domain 4rd prefix.  (Section 3.1).  The
   4rd model is built on IPv4 over IPv6 stateless tunnels to reach 4rd
   CEs where customers will share IPv4 addresses if the CE 4rd prefix is
   longer than 32-bits (Section 3.2). 4rd differs from other solutions
   such as Dual-Stack-lite [I-D.ietf-softwire-dual-stack-lite] since the
   4rd CE is used to implement the NAT44 (Section 3.3). 4rd also can
   implement Routing Optimization to Provide IPv4 Connectivity while the
   4rd CE communicates with other 4rd CE (Section 3.4).


3.  Applicability

   In this section, we describe 4rd applicability with Figure 1 as an
   example of 4rd enabled network.  It is helpful to explain 4rd and
   underdtand 4rd applicability.



Sun, et al.            Expires September 16, 2011               [Page 3]


Internet-Draft              4rd Applicability                 March 2011


                        +------------------------+
                       /                          \
                      |       IPv4 Internet        |
                       \                          /
                        +------------------------+
                                     |
                                     |
                         +----------------------+
                         |        4rd BR        |
                         +----------------------+
                                     |
                                     |
                    + --------------------------------+
                   /                                   \
                  |        ISP's IPv6 network           |
                   \          2001:db8::/32            /
                     ---------------------------------
                     /                |              \
                    /                 |               \
                   /                  |                \
     2001:db8:cdab::/48      2001:db8:cdef::/48       2001:db8:cda1::/48
     +-----------+             +------------+           +------------+
     |  4rd CE1  |             |  4rd CE2   |   ***     |  4rd CEn   |
     +-----------+             +------------+           + -----------+

                   Figure 1: A 4rd network model example

3.1.  IPv4 Address Assignment

   [I-D.despres-intarea-4rd] specify 4rd address mapping rule.  When 4rd
   address mapping rule apply to the Figure 1, as Figure 2 shown, a 4rd
   CE1's IPv4 address, which is in the range of domain 4rd prefix, is
   generated from CE IPv6 prefix.  As the prerequisite of 4rd, Domain
   IPv6 prefix and Domain 4rd prefix must be given to all 4rd CEs and
   4rd BRs in a specified 4rd domain.  CE IPv6 prefix for all 4rd CEs in
   the specified 4rd domain must be in same Domain IPv6 prefix but must
   be unique for each 4rd CE.














Sun, et al.            Expires September 16, 2011               [Page 4]


Internet-Draft              4rd Applicability                 March 2011


          <------------ CE IPv6 prefix (max length 64) ------------>
          +-------------------------------+-------------------------+
          |     2001:db8::/32             |        0xcdab           |
          +-------------------------------+-------------------------+
          <-- Domain IPv6 prefix length --|<----CE index length---->|
                                          :            ||           :
                        Domain 4rd prefix :            \/           :
                      |<----------------->|<-- suffix-->|           |
                      +-------------------+-------------------------+
       CE 4rd prefix  | 192.0.2.0/24      |    0xcd     |  0xab     |
                      +-------------------+-------------------------+
                      |<----4rd CE1's IPv4 address----->|<--------->|
                                 192.0.2.205(0xcd)       Port-set ID

          Figure 2: An example of 4rd address mapping for 4rd CE1

   All 4rd CEs IPv4 addresses are in the range fo domain of domain 4rd
   prefix.  Figure 2 shows an example that 4rd CE1's IPv4 address how to
   be genarated.  This means that it is not necessary for 4rd operators
   to pay attention to what IPv4 address is generated by 4rd CE.  In the
   case of all 32 bits of IPv4 address is mapped to IPv6 prefix, 4rd CE
   must not generate well-known IPv4 address (such as 0/8, 127/8, etc.,
   for example) so that IPv6 prefix assignment should be taken careful
   to avoid it. 4rd is recommended to operators who do not want IPv6
   prefix assignment of which takes into account what IPv4 address
   generated from IPv6 prefix.

   As example (Figure 1) shown, the 4rd model is built on IPv4 over IPv6
   tunnels to reach 4rd CEs where up to 256 customers can share a IPv4
   addresse.  In the given example, the IPv6 ISP aggregate Domain IPv6
   prefix is 2001:db8::/32.  Out of this aggregate, a /48 CE IPv6 prefix
   for each 4rd CE is assumed to be issued, this allowing for a 16-bits
   CE index.  Since remaining bits to mapping IPv4 address is 8 bit,
   "0xab" is a part of last octet of CE1's IPv4 address.  As a result,
   192.0.2.205 is shared with 256 4rd-CEs.

3.2.  IPv4 Address Sharing

   When the CE 4rd prefix is longer than 32 bits, IPv4 address will be
   shared by muliple 4rd CEs.  As Figure 3 shown, the suffix of shared
   IPv4 address and Port-set ID are derived from CE index of CE IPv6
   prefix.  CEs have same 4rd shared IPv4 address and unique Port-set
   ID, so CEs can be identified using IPv4 address and unique Port-set
   ID.







Sun, et al.            Expires September 16, 2011               [Page 5]


Internet-Draft              4rd Applicability                 March 2011


          <------------ CE IPv6 prefix length (max 64) ------------->
          +-------------------------------+-------------------------+
          |     2001:db8::/32             |        CE index         |
          +-------------------------------+-------------------------+
          <-- Domain IPv6 Prefix length --|<----CE index length---->|
                                          :            ||           :
                        Domain 4rd prefix :            \/           :
                      |<----------------->|<-- suffix-->|           |
                      +-------------------+-------------------------+
       CE 4rd prefix  | 192.0.2.0/24      |    0xcd     |Port-set ID|
                      +-------------------+-------------------------+
                      |<---4rd shared IPv4 address----->| CE1: Oxab
                                 192.0.2.205(0xcd)        CE2: Oxef
                                                          ...  ...
                                                          CEn: Oxa1

                 Figure 3: Port-set ID generation example

   As shown in Figure 3 , the available port-set ID for IPv4 address
   sharing is derived form the remaining 8-bits, e.g. 0xab, 0xef, 0xa1
   used by 4rd CE1, 4rd CE2, 4rd CEn respectively.  With this particular
   scheme shown in the example, up to 256 4rd CEs can share the IPv4
   address.

   According to [I-D.despres-intarea-4rd],each 4rd CE has its unique
   port-ranges which is calculated based on the 4rd mapping rule with
   their Port-set ID.  The 4rd port mapping rule uses four heads, as
   shown in the Figure 4 below.  This allows 4rd CEs to avoid using well
   known (reserved) TCP/UDP ports 0-4095.






















Sun, et al.            Expires September 16, 2011               [Page 6]


Internet-Draft              4rd Applicability                 March 2011


                  <------- Port (16bit) ---------->
     Port-range a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (head=0001)  |0|0|0|1|1 0 1 0|1 0 1 1|       |    0x1AB0 - 0x1ABF
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         /  0xA  /   0xB /
     Port-range b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (head=001)   |0|0|1|1 0 1 0|1 0 1 1|         |    0x3560 - 0x356F
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       /  0xA  /  0xB  /
     Port-range c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (head=01)    |0|1|1 0 1 0|1 0 1 1|           |    0x6AC0 - 0x6AFF
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     /  0xA  /  0xB  /
     Port-range d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (head=1)     |1|1 0 1 0|1 0 1 1|             |    0xD570 - 0xD5FF
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   /  0xA  /  0xB  /
     Port-set ID  +-+-+-+-+-+-+-+-+
     (CE1,0xAB)   |1 0 1 0|1 0 1 1|
                  +-+-+-+-+-+-+-+-+

           Figure 4: Port-range calculation example for 4rd CE1

3.3.  Distributing NAT function to CEs

   Since 4rd distributes NAT44 function to the 4rd CE, the CE side NAT44
   manages user's NATed session in general of each 4rd CE unit.
   According to their own infrastructure and management systems, if ISPs
   think 4rd CE Side NAT is easier to manage than gateway side NAT, they
   can adopt the 4rd technology.

   The capex and opex costs of an ISP vary from network to network.  The
   4rd solution is an ideal fit for those where a CE based NAT solution
   is acceptable, and where investment in operating and managing of a
   centralized NAPT 44 gateway is not desired.

   For an CE IPv6 prefix of a given length, e.g. a /56 PD, as more and
   more bits are used to express the shared IPv4 address, the less bits
   are available to express the port range.  It is not 4rd specific
   issue, but a method that supports NAT Port Mapping needs to be
   devised.  For example, 256 ports can be used by 4rd CE, but access to
   host A, B, and C requires 100 ports each.  If the 4rd CE ports are
   distributed when A,B,C are accessed at the same time from the same
   4rd CE, Ports 0 - 99 are used to access host A, Ports 100 - 199 are
   used to access host B, but host C cannot be accessed because the
   remaining ports are not enough.  As Figure 5, 4rd can reuse the 4rd
   CE Port by terms of recognizing the destination addresses in order to
   reduce the aspect of this problem.  It is noted that the problem can



Sun, et al.            Expires September 16, 2011               [Page 7]


Internet-Draft              4rd Applicability                 March 2011


   not be solved if the multiple users under same 4rd CE access the same
   host (e.g. host A) exceed the number of ports.



                      -----------------------------------
                    /                                      \
                   /                IPv4 Internet            \
                  |   +--------+   +--------+   +--------+    |
                   \  | host A |   | host B |   | host C |   /
                    \ +--------+   +--------+   +--------+  /
                     --------------------------------------
                                     |
                         +---------------------+
                         |       4rd BR        |
                         +---------------------+
                                     |
                    +---------------------------------+
                   /                                   \
                  |        ISP's IPv6 network           |
                   \                                   /
                    +---------------------------------+
                                     |
             4rd CE                  |
             +--------------------------------------------------+
             |   Port number      Port number     Port number   |
             |    pool for         pool for        pool for     |
             |  +--host A --+   +--host B --+   +--host C --+   |
             |  | Port0-255 |   | Port0-255 |   | Port0-255 |   |
             |  +-----------+   +-----------+   +-----------+   |
             +--------------------------------------------------+

              Figure 5: Reuse port number on 4rd CE side NAT

   Figure 6 quantifies address sharing rates for different port range
   lengths, along with the overall number of ports available to a give
   CE.  The 4rd allows 16 bits to be used by NAPT.  In theory, one IPv4
   address can be shared by 65536 (2 to 16th power) customers.  However,
   at least 1 bit is needed for Port-range Index.  The greatest bit
   range that can be used to share address are 15 bits.











Sun, et al.            Expires September 16, 2011               [Page 8]


Internet-Draft              4rd Applicability                 March 2011


      +------------+-------------------------+---------------+------------+
      |    Port    |   User numbers that can |    # of ports |  Relative  |
      |   prefix   |    share one v4 address |  for a 4rd CE |   to a /8  |
      |   length   |                         |               |            |
      +------------+-------------------------+---------------+------------+
      |      1     |                   1 - 2 |         30720 |     /9     |
      |      2     |                   1 - 4 |         15360 |     /10    |
      |      3     |                   1 - 8 |          7680 |     /11    |
      |      4     |                  1 - 16 |          3840 |     /12    |
      |      5     |                  1 - 32 |          1920 |     /13    |
      |      6     |                  1 - 64 |           960 |     /14    |
      |      7     |                 1 - 128 |           480 |     /15    |
      |      8     |                 1 - 256 |           240 |     /16    |
      |      9     |                 1 - 512 |           120 |     /17    |
      |     10     |                1 - 1024 |            60 |     /18    |
      |     11     |                1 - 2048 |            30 |     /19    |
      |     12     |                1 - 4096 |            15 |     /20    |
      |     13     |                1 - 8192 |             7 |     /21    |
      |     14     |               1 - 16384 |             3 |     /22    |
      |     15     |               1 - 32768 |             1 |     /23    |
      +------------+-------------------------+---------------+------------+

                      Figure 6: 4rd CE available port

3.4.  Routing optimization to provide IPv4 connectivity

   Figure 7 shows that 4rd can implement IPv6 routing with direct IP
   forwarding between the two 4rd CEs.  In other words, 4rd allows
   direct packet forwarding between CEs that share a 4rd domain, without
   the need of forwarding such traffic through the gateway.

   When V4a under 4rd CE1 send packets to V4b under 4rd CE2, the packets
   need not go through the gateway (Hub&Spoke) before going to 4rd CE2,
   they can go to 4rd CE2 directly (mesh).  This section describes this
   in more detail from two perspectives: Network matching and Network
   Load.















Sun, et al.            Expires September 16, 2011               [Page 9]


Internet-Draft              4rd Applicability                 March 2011


           +------------------------+
          /        IPv4 Network       \
          \                           /
           +-------------------------+
                        |
             +---------------------+
             |  gateway (e.g. BR)  |
             +---------------------+
                        |
           +------------------------+
          /                          \         +----------------------+
         |   ISP's IPv6 access NW     | -------|       4rd CE2 (V4b)  |
          \                    [//]===/========+== >------------------+
           +-----------------[//]---+
                      |    [//]
          +---------------[//]---+
          |      4rd CE1 (V4a)   |
          +----------------------+

                                 Figure 7

   Taking network matching into account, 4rd should be chosen if the
   ISP's IPv6 network allows direct CE-CE traffic forwarding (eg: IPv6
   Flat Routing Network).

   Compared to Hub & Spoke architecture solutions, mesh architecture
   solutions can achieve a smaller network load when the 4rd CE
   communicate frequently.  If the ISP thinks that its network has
   insufficient bandwidth or it wants to lower the load imposed by IPv4
   connections, they should choose a mesh architecture solution such as
   4rd.

   Note: Softwire mesh [RFC5565] is also a mesh architecture solution,
   but it does not provide the IPv4 sharing function.  Softwire mesh can
   be adopted if IPv4 address sharing is not needed.

3.5.  Gateway Redundancy Considerations

   Since in 4rd the BR side does not implement the NAT function, the BR
   can be easily replicated.  For instance, there can be N:1 redundant
   BRs in the network.  Reliable network operation can be guaranteed
   because a failed BR can be immediately and easily replicated by any
   one of the N BRs.

   If the gateway side implements NAT, 1:1 gateway redundancy is the
   choice, and also upstream and downstream traffic from the same user
   must go through the same gateway. 4rd easily realizes load balancing
   because upstream and downstream traffic from the same user can go



Sun, et al.            Expires September 16, 2011              [Page 10]


Internet-Draft              4rd Applicability                 March 2011


   through different gateways.

3.6.  NAT Log Considerations

   4rd CE uses fixed NAT rules and IPv4 users can be directly identified
   by means of their IPv6 address, so the NAT log does not need to be
   left.  In other words, 4rd allows an operator to save on the need to
   perform NAT log collection and retention.  On the other hand, other
   solutions may achieve higher address sharing rate than 4rd.  If
   operators want to reduce NAT log with these solutions, their NATs
   have to be configured with [I-D.tsou-behave-natx4-log-reduction], or
   allocate fixed port range for NAT rules regardless of the advantage.

   It is noted that another logging necessity coming from
   [I-D.ietf-intarea-shared-addressing-issues] is described in
   [I-D.ietf-intarea-server-logging-recommendations] for Internet facing
   servers.


4.  Constraint Considerations

   This section describes the constraint on user number when addresses
   are shared.  As Section 3.3 stated, the maximum bit range that can be
   used by Port-set ID is 15 bits.  In this case, 4rd CE is restricted
   to one private port.  In fact, it is not able to provide service.  So
   the customer numbers per IPv4 address that can be shared need to be
   considered along with the ports needed by 4rd CE.

   It is noted that deriving IPv4 addresses from CE IPv6 prefix
   generated by 4rd mapping rule may lead to a low rate of IPv4 address
   sharing because it does not allow for statistical multipexing gains.
   ISPs who feel that this is not desirable and want to achieve high
   sharing rates can select centralized gateway/NAPT solutions, which
   can have a high sharing rate because allow for such statistical
   multipexing gains.


5.  Security Considerations

   The sharing of IPv4 address reduces the port selection space per 4rd
   CE, so a blind attack can be performed easily.  An attack can be
   performed if the attacker is able to correctly guess the source
   address and source port.  Address and Port Dependent Filtering (APDF)
   need be implemented in order to counter blind attack.  In APDF, not
   only source address and source port but also destination address and
   destination port need to be checked.  Even so, a blind attack that
   can be performed against TCP relies on the attacker's ability to
   guess the 5-ruple (Protocol, Source address, Destination address,



Sun, et al.            Expires September 16, 2011              [Page 11]


Internet-Draft              4rd Applicability                 March 2011


   Source Port, Destination Port).  Shared address issues
   [I-D.ietf-intarea-shared-addressing-issues] describes a method for
   the random selection of TCP Sequence Number, that reduces the ability
   of attacker to correctly guess the 5-ruple.

   DNS is one of the important protocols to use UDP.  In 4rd CE, all DNS
   reply packets should be discarded, expect for the packets from
   forward destinations.  If DNS implements Port Randomization, the
   attack success rate can be reduced.

   We describe here a method for reducing Spoofing Attack under 4rd CE.
   Using the 4rd mapping rule, the IPv4 address can be derived from IPv6
   address, so we can check the IPv4 address thus derived and the IPv4
   address in the header of received packet.  If they are same, the
   packet is forwarded, otherwise, it is dropped.


6.  Conclusions

   This document described the ability of 4rd to support the IPv6-only
   access network.  We conclude that the 4rd solution is a viable choice
   when the ISP desires a stateless IPv4 address sharing option, based
   on CE side NAT functionality, along with a high degree of freedom in
   terms of redundancy and optimal traffic forwarding. 4rd is also
   recommended to operators who do not want IPv6 prefix assignment of
   which takes into account what IPv4 address generated from IPv6
   prefix.  When only one 4rd applicable character is needed, 4rd may be
   used to only that purpose with other solutions.


7.  Acknowledgements

   The authors would like to thank Remi Despres for his enormous effort
   to work for 4rd architecture and protocol.  The authors also thank to
   people who provided encouragements concerning the 4rd approach and
   lead to consider 4rd in Japan.  In particular, we would like to thank
   Toshiya Asaba, Yoshiki Ishida, Tetsuya Innami, Ruri Hiromi, Masataka
   Mawatari, Akira Nakagawa, Tomoyuki Sahara, Taisuke Sasaki, Katsuyasu
   Toyama, Mark Townsley, Wojciech Dec, Yuji Yamazaki, have provided
   useful discussion and comments on the document and review.


8.  References

8.1.  Normative References

   [I-D.despres-intarea-4rd]
              Despres, R., Matsushima, S., Murakami, T., and O. Troan,



Sun, et al.            Expires September 16, 2011              [Page 12]


Internet-Draft              4rd Applicability                 March 2011


              "IPv4 Residual Deployment across IPv6-Service networks
              (4rd) ISP-NAT's made optional",
              draft-despres-intarea-4rd-00 (work in progress),
              March 2011.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

8.2.  Informative References

   [I-D.arkko-ipv6-transition-guidelines]
              Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment",
              draft-arkko-ipv6-transition-guidelines-14 (work in
              progress), December 2010.

   [I-D.ietf-intarea-server-logging-recommendations]
              Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
              "Logging recommendations for Internet facing servers",
              draft-ietf-intarea-server-logging-recommendations-03 (work
              in progress), February 2011.

   [I-D.ietf-intarea-shared-addressing-issues]
              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing",
              draft-ietf-intarea-shared-addressing-issues-05 (work in
              progress), March 2011.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
              in progress), March 2011.

   [I-D.tsou-behave-natx4-log-reduction]
              ZOU), T., Li, W., and T. Taylor, "Port Management To
              Reduce Logging In Large-Scale NATs",
              draft-tsou-behave-natx4-log-reduction-02 (work in
              progress), September 2010.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix



Sun, et al.            Expires September 16, 2011              [Page 13]


Internet-Draft              4rd Applicability                 March 2011


              Reserved for Documentation", RFC 3849, July 2004.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
              Reserved for Documentation", RFC 5737, January 2010.


Authors' Addresses

   Chunfa Sun
   Softbank BB
   Tokyo Shiodome Building. 22F
   1-9-1,Higashi-Shimbashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: c-sun@bb.softbank.co.jp


   Satoru Matsushima
   Softbank Telecom
   Tokyo Shiodome Building. 22F
   1-9-1,Higashi-Shimbashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: satoru.matsushima@tm.softbank.co.jp


   Jie Jiao
   Softbank BB
   Tokyo Shiodome Building. 12F
   1-9-1,Higashi-Shimbashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: j-jiao@bb.softbank.co.jp












Sun, et al.            Expires September 16, 2011              [Page 14]