[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6598

Network Working Group                                            J. Weil
Internet-Draft                                         Time Warner Cable
Updates: 1918, 5735 (if approved)                           V. Kuarsingh
Intended status: BCP                               Rogers Communications
Expires: March 29, 2012                                        C. Donley
                                                               CableLabs
                                                         C. Liljenstolpe
                                                            Telstra Corp
                                                              M. Azinger
                                                 Frontier Communications
                                                      September 26, 2011


             IANA Reserved IPv4 Prefix for Shared CGN Space
             draft-weil-shared-transition-space-request-06

Abstract

   This document requests that an IPv4 /10 be reserved as Shared CGN
   Space solely to facilitate deployment of IPv4 Carrier Grade NAT (CGN)
   technologies after IPv4 exhaustion.  This document updates RFC 1918
   and RFC 5735 to reserve an additional special-use address range for
   use between a CGN and home router.

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 March 29, 2012.

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



Weil, et al.             Expires March 29, 2012                 [Page 1]


Internet-Draft          Shared CGN Space Request          September 2011


   (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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Shared CGN Space . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Address-Based Scope Detection  . . . . . . . . . . . . . .  6
   5.  Alternatives . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  RFC1918 Space  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Globally Unique Space  . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

























Weil, et al.             Expires March 29, 2012                 [Page 2]


Internet-Draft          Shared CGN Space Request          September 2011


1.  Introduction

   IPv4 address space is nearly exhausted.  Until the Internet fully
   transitions to IPv6, Service Providers will be required to offer
   continued support for legacy IPv4-only devices.  In order to
   facilitate the deployment of Carrier Grade NAT (CGN) technologies
   [RFC6264] to support such legacy IPv4-only devices and services,
   Service Providers require IPv4 address space that is separate from
   the range of IPv4 addresses used by subscribers.  This address space
   need not be unique to each provider, but needs to be outside of
   [RFC1918] space.  This document requests that an IPv4 /10 be reserved
   as Shared CGN Space solely to facilitate deployment of CGN
   technologies in Service Provider networks.  As Shared CGN Space is a
   new special-use address range between a CGN and home router, this
   document updates [RFC1918] and [RFC5735] to reflect its use.




































Weil, et al.             Expires March 29, 2012                 [Page 3]


Internet-Draft          Shared CGN Space Request          September 2011


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].














































Weil, et al.             Expires March 29, 2012                 [Page 4]


Internet-Draft          Shared CGN Space Request          September 2011


3.  Motivation

   The Internet community is rapidly consuming the remaining supply of
   unallocated IPv4 addresses.  During the transition period to IPv6, it
   is imperative that Service Providers maintain IPv4 service for
   devices and networks that are currently incapable of upgrading to
   IPv6.  In order to provide IPv4 service to customers and/or devices
   once the IPv4 address space is exhausted, many Service Providers will
   need to multiplex several subscribers behind a single IPv4 address
   using a Carrier Grade NAT (CGN) [RFC6264].  Addresses between the CGN
   and subscriber home routers need not be globally unique, only unique
   inside the CGN.  Thus, providers need sufficient non-[RFC1918]
   address space to deploy such technologies and avoid overlap with
   customer use of private address space.

   Additional applicability and analysis of Shared CGN Space is
   described in [I-D.bdgks-arin-shared-transition-space].


































Weil, et al.             Expires March 29, 2012                 [Page 5]


Internet-Draft          Shared CGN Space Request          September 2011


4.  Shared CGN Space

   This document proposes the assignment of a /10 as Shared CGN Space.
   Shared CGN Space is IPv4 address space reserved for Service Provider
   use with the purpose of facilitating CGN deployment.  The requested
   block MUST NOT be utilized for any purpose other than as "inside"
   addresses in a CGN environment (e.g., between the CGN and customer
   premises equipment (CPE)).  Network equipment manufacturers MUST NOT
   use the assigned block in default or example device configurations.

   Because Shared CGN Space addresses have no meaning outside of the
   Service Provider, routing information about Shared CGN Space networks
   MUST NOT be propagated on interdomain links, and packets with Shared
   CGN Space source or destination addresses MUST NOT be forwarded
   across such links, except where required based on business
   relationships such as hosted CGN service.  Service Providers SHOULD
   filter out routing information about Shared CGN Space networks on
   ingress links.  DNS queries for Shared CGN Space addresses MUST NOT
   be forwarded to the global DNS infrastructure.  This is done to avoid
   having to set up something similar to AS112.net for RFC 1918 private
   address space that a host has incorrectly sent for a DNS reverse-
   mapping queries on the public Internet [RFC6304].

   Shared CGN Space is expected to be used in a Service Provider
   Environment.  Shared CGN Space MUST NOT be used in network
   environments described in [RFC1918] as designed for private addresses
   - namely, for hosts that do not require access to hosts in other
   enterprises or the Internet at large, or hosts that need access to a
   limited set of outside services (e.g., E-mail, FTP, netnews, remote
   login) that can be handled by mediating gateways (e.g., application
   layer gateways).  Shared CGN Space MUST NOT be used inside a home
   router NAT.  With the exception of subscribers using bridged Internet
   access (i.e., without a home router between the subscriber and
   Service Provider networks), subscriber hosts SHOULD NOT use Shared
   CGN Space addresses.  Because CGN service requires non-overlapping
   address space on each side of the home NAT and CGN, entities misusing
   Shared CGN Space for purposes other than for CGN service, as
   described in this document, are likely to experience problems
   implementing or connecting to CGN service at such time as they
   exhaust their supply of public IPv4 addresses.

4.1.  Address-Based Scope Detection

   Some CPE router devices make assumptions about their connectivity
   scope based on their WAN-side IPv4 address.  This is particularly
   evident in their handling of 6to4 [RFC3056], [RFC3068].  As described
   in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels
   when they are configured with a [RFC1918] or [RFC5735] WAN address.



Weil, et al.             Expires March 29, 2012                 [Page 6]


Internet-Draft          Shared CGN Space Request          September 2011


   When configured with a Shared CGN Space address (or other address
   range not described in [RFC5735]), such devices may attempt to
   initiate 6to4.  Since 6to4 includes the WAN IPv4 address embedded in
   its IPv6 address, should 6to4 traffic traverse a CGN, return traffic
   could be misdirected and not reach the originating router.  Service
   Providers can mitigate this issue using a technology such as 6to4-PMT
   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel].  When the address
   range is well-defined, as with Shared CGN Space, home router vendors
   can include Shared CGN Space in their list of special-use addresses
   (e.g., [RFC5735]) and treat Shared CGN Space similarly to private
   [RFC1918] space.  When the WAN address is not well-defined, as in the
   case of Globally Unique space, it will be more difficult for home
   router vendors to mitigate against this issue.

   CGN technologies impose additional impacts on applications (see
   [RFC6269] and [I-D.donley-nat444-impacts]) that are not dependent on
   the address space between the CGN and home router.


































Weil, et al.             Expires March 29, 2012                 [Page 7]


Internet-Draft          Shared CGN Space Request          September 2011


5.  Alternatives

   As described in [RFC6319], there are two alternatives to Shared CGN
   Space, considered below:

   1.  Use private [RFC1918] address space.

   2.  Use Globally-Unique address space.

5.1.  RFC1918 Space

   In some cases, it may be possible to instead use private [RFC1918]
   address space between the CGN and CPE devices.  In situations where
   all endpoints in the network are managed by the service provider
   (including customer LAN addressing), this may be a viable option.
   However, when customers administer their own LANs or use default
   addresses assigned to CPE devices, the possibility of address
   conflict becomes a significant risk to operations.  Private [RFC1918]
   address space is not generally intended to be used for purposes which
   cross administrative domains.  Further, CGN service requires address
   space in one administrative domain that extends to leaf networks that
   are generally single-homed to the serving administrative domain.
   This usage is outside of Category 1 and Category 2, defined in
   [RFC1918] for use of private address space.

   A study of DNS traffic [v6ops-msg06187] has shown that effectively
   all of the existing private [RFC1918] address space is currently
   being used by end-sites attached to the Internet.  While individual
   network environments may vary in this regard, most Service Providers
   face the risk that their use of private address space will conflict
   with their customer end-sites.

   In the event of conflict, it is possible that the end-site CPE
   routers will fail and/or not function correctly.  While some CPE
   implementations will support overlapping addresses on the "inside"
   and "outside" interfaces, others are known to fail under such
   circumstances.  Also, the use of private [RFC1918] address space on
   interfaces and hosts often causes default behaviors on such hosts
   which may not be desirable when the endpoint is actually connected to
   the Internet.  For instance, one common home router warns customers
   against enabling NAT when it detects private [RFC1918] addresses on
   its WAN interface, and instead encourages bridge mode.  If NAT mode
   is enabled, the router turns the status light amber, indicating an
   error.







Weil, et al.             Expires March 29, 2012                 [Page 8]


Internet-Draft          Shared CGN Space Request          September 2011


5.2.  Globally Unique Space

   If Shared CGN Space is not available, the total aggregate demand for
   Globally-Unique space behind a CGN will be significantly higher than
   the /10 requested as Shared CGN Space.  In addition to use of
   significant IPv4 addresses that could otherwise be offered to
   subscribers, as described in
   [I-D.bdgks-arin-shared-transition-space], if various organizations
   use public address space to number CGN zones, it will be difficult
   for other networks/hosts to deterministically know if the endpoints
   are using Internet reachable addresses, or if they are leaking from
   behind a CGN, as described above (Section 4.1).  This situation would
   likely lead to additional technical issues during various leakage
   conditions, make it difficult to identify filter rule issues, and
   pose challenges for Content Distribution Networks (CDNs) or other
   third party providers.



































Weil, et al.             Expires March 29, 2012                 [Page 9]


Internet-Draft          Shared CGN Space Request          September 2011


6.  Security Considerations

   Similar to other [RFC5735] special use IPv4 addresses, Shared CGN
   Space as described in this document does not directly raise security
   issues.  However, the Internet does not inherently protect against
   abuse of these addresses.  Unless required for legitimate business
   needs between directly-connected Service Providers, Service Providers
   SHOULD filter incoming router advertisements for Shared CGN Space.
   Attacks have been mounted that depend on the unexpected use of
   similar special-use addresses.  However, it should also be noted that
   this address spaces may be used legitimately outside a single
   administrative domain.  Thus, network operators are encouraged to
   review this document and determine what security policies should be
   associated with this address block within their specific operating
   environments.  In many cases, Shared CGN Space will be appropriate to
   include in Ingress Filter lists [RFC3704].



































Weil, et al.             Expires March 29, 2012                [Page 10]


Internet-Draft          Shared CGN Space Request          September 2011


7.  IANA Considerations

   IANA is asked to record the allocation of an IPv4 /10 for use as
   Shared CGN Space.

   The Shared CGN Space address range is: x.x.0.0/10.  [Note to RFC
   Editor: this address range to be added before publication]












































Weil, et al.             Expires March 29, 2012                [Page 11]


Internet-Draft          Shared CGN Space Request          September 2011


8.  References

8.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
              BCP 153, RFC 5735, January 2010.

   [RFC6264]  Jiang, S., Guo, D., and B. Carpenter, "An Incremental
              Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
              June 2011.

8.2.  Informative References

   [I-D.bdgks-arin-shared-transition-space]
              Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and
              B. Schliesser, "ARIN Draft Policy 2011-5: Shared
              Transition Space",
              draft-bdgks-arin-shared-transition-space-01 (work in
              progress), July 2011.

   [I-D.donley-nat444-impacts]
              Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
              and V. Ganti, "Assessing the Impact of NAT444 on Network
              Applications", draft-donley-nat444-impacts-01 (work in
              progress), October 2010.

   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]
              Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
              Managed Tunnels",
              draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03
              (work in progress), September 2011.

   [I-D.shirasaki-nat444]
              Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work
              in progress), July 2011.

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

   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",



Weil, et al.             Expires March 29, 2012                [Page 12]


Internet-Draft          Shared CGN Space Request          September 2011


              RFC 3068, June 2001.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.

   [RFC6304]  Abley, J. and W. Maton, "AS112 Nameserver Operations",
              RFC 6304, July 2011.

   [RFC6319]  Azinger, M. and L. Vegoda, "Issues Associated with
              Designating Additional Private IPv4 Address Space",
              RFC 6319, July 2011.

   [RFC6343]  Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
              RFC 6343, August 2011.

   [v6ops-msg06187]
              WIDE, "Re: [v6ops] IETF 79 Meeting minutes - Draft",
              Nov 2010, <http://www.ietf.org/mail-archive/web/v6ops/
              current/msg06187.html>.
























Weil, et al.             Expires March 29, 2012                [Page 13]


Internet-Draft          Shared CGN Space Request          September 2011


Appendix A.  Acknowledgments

   Thanks to the following people (in alphabetical order) for their
   guidance and feedback:

      John Brzozowski

      Isaiah Connell

      Greg Davies

      Kirk Erichsen

      Wes George

      Tony Hain

      Philip Matthews

      John Pomeroy

      Barbara Stark

      Jean-Francois Tremblay

      Leo Vegoda

      Steven Wright

      Ikuhei Yamagata





















Weil, et al.             Expires March 29, 2012                [Page 14]


Internet-Draft          Shared CGN Space Request          September 2011


Authors' Addresses

   Jason Weil
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   USA

   Email: jason.weil@twcable.com


   Victor Kuarsingh
   Rogers Communications
   8200 Dixie Road
   Brampton, ON  L6T 0C1
   Canada

   Email: victor.kuarsingh@gmail.com


   Chris Donley
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: c.donley@cablelabs.com


   Christopher Liljenstolpe
   Telstra Corp
   7/242 Exhibition Street
   Melbourne, VIC  316
   Australia

   Phone: +61 3 8647 6389
   Email: cdl@asgaard.org


   Marla Azinger
   Frontier Communications
   Vancouver, WA
   USA

   Phone: +1.360.513.2293
   Email: marla.azinger@frontiercorp.com





Weil, et al.             Expires March 29, 2012                [Page 15]


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