[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: 5735 (if approved)                                 V. Kuarsingh
Intended status: BCP                               Rogers Communications
Expires: April 5, 2012                                         C. Donley
                                                               CableLabs
                                                         C. Liljenstolpe
                                                            Telstra Corp
                                                              M. Azinger
                                                 Frontier Communications
                                                         October 3, 2011


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

Abstract

   This document requests the allocation of an IPv4 /10 address block to
   be used as Shared Carrier Grade Network (CGN) Space.  Service
   Providers will use Shared CGN Space to number the interfaces that
   connect CGN devices to Customer Premise Equipment (CPE).  As this
   document proposes the allocation of an additional special-use IPv4
   address block, it updates RFC 5735.

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 5, 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



Weil, et al.              Expires April 5, 2012                 [Page 1]


Internet-Draft          Shared CGN Space Request            October 2011


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Alternatives to Shared CGN Space . . . . . . . . . . . . . . .  5
   4.  Use of Shared CGN Space  . . . . . . . . . . . . . . . . . . .  6
   5.  Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Empirical Data . . . . . . . . . . . . . . . . . . . . . .  8
   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 April 5, 2012                 [Page 2]


Internet-Draft          Shared CGN Space Request            October 2011


1.  Introduction

   IPv4 address space is nearly exhausted.  However, ISPs must continue
   to support IPv4 growth until IPv6 is fully deployed.  To that end,
   many ISPs will deploy Carrier Grade NAT (CGN) [RFC6264].  In order to
   effectively deploy CGN, ISPs require a new IPv4 /10 address block.
   This address block will be called the Shared Carrier Grade Network
   (CGN) Space and will be used to number the interfaces that connect
   CGN devices to CPE.

   Shared CGN Space is distinct from [RFC1918] address space.  Like
   [RFC1918] space, Shared CGN Space must be unique to the network but
   need not be globally unique.  Unlike [RFC1918] address space, Shared
   CGN Space is not available for any purpose other than numbering the
   interfaces that connect a CGN to CPE.  Additional applicability and
   analysis of Shared CGN Space is described in
   [I-D.bdgks-arin-shared-transition-space].

   This document requests the allocation of an IPv4 /10 address block to
   be used as Shared Carrier Grade Network (CGN) Space.  As this
   document proposes the allocation of an additional special-use IPv4
   address block, it updates [RFC5735].





























Weil, et al.              Expires April 5, 2012                 [Page 3]


Internet-Draft          Shared CGN Space Request            October 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 April 5, 2012                 [Page 4]


Internet-Draft          Shared CGN Space Request            October 2011


3.  Alternatives to Shared CGN Space

   The interfaces that connect CGN devices to CPE might conceivably be
   numbered from any of the following address spaces:

   o  legitimately assigned globally unique address space

   o  usurped globally unique address space (i.e., squat space)

   o  [RFC1918] space

   o  Shared CGN Space

   A Service Provider can number the interfaces in question from
   legitimately assigned globally unique address space.  While this
   solution poses the fewest problems, it is impractical because
   globally unique IPv4 address space is in short supply.  While the
   Regional Internet Registries (RIR) have enough address space to
   allocate a single /10 to be shared by all Service Providers, they do
   not have enough address space to make a unique assignment to each
   Service Provider.

   Service Providers MUST NOT number the interfaces in question from
   usurped globally unique address space (i.e., squat space).  If a
   Service Provider leaks advertisements for squat space into the global
   Internet, the legitimate owners of that address space may be
   adversely impacted, as would those wishing to communicate with them.
   Even if the Service Provider did not leak advertisements for squat
   space, the Service Provider and its subscribers might lose
   connectivity to the legitimate owner of that address space.

   A Service Provider can number the interfaces in question from
   [RFC1918] space if either of the following conditions are true:

   o  The Service Provider knows that the CPE/NAT works correctly when
      the same [RFC1918] address block is used both on its inside and
      outside interfaces.

   o  The Service Provider knows that the [RFC1918] address block that
      it uses to number interfaces between the CGN and CPE is not used
      on the subscriber side of the CPE.

   Unless at least one of the conditions above is true, the Service
   Provider cannot safely use [RFC1918] address space and must resort to
   Shared CGN Space.  This is typically the case in an unmanaged
   service, where subscribers provide their own CPE and number their own
   internal network.




Weil, et al.              Expires April 5, 2012                 [Page 5]


Internet-Draft          Shared CGN Space Request            October 2011


4.  Use of Shared CGN Space

   Shared CGN Space is IPv4 address space reserved for Service Provider
   use with the purpose of facilitating CGN deployment.  Specifically:

   o  Shared CGN Space MUST NOT be utilized for any purpose other than
      as "inside" addresses in a CGN environment (e.g., between the CGN
      and CPE).

   o  Network equipment manufacturers MUST NOT use Shared CGN Space in
      default or example device configurations.

   o  Shared CGN Space MUST NOT be used on the customer premise side of
      a subscriber NAT device.

   Because Shared CGN Space addresses have no meaning outside of the
   Service Provider, routing information about Shared CGN Space networks
   MUST NOT be propagated across Service Provider boundaries.  Service
   Providers MUST filter incoming advertisements regarding Shared CGN
   Space.  One exception to the above proscription against exchanging
   routes for Shared CGN Space is in the case of a defined business
   relationship between two Service Providers (e.g., for hosted CGN
   service).

   Packets with Shared CGN Space source or destination addresses MUST
   NOT be forwarded across Service Provider boundaries.  Service
   Providers MUST filter such packets on ingress links.  As above, one
   exception to the above proscriptions is in the case of business
   relationships such as hosted CGN service.

   When running a single DNS infrastructure, Service Providers MUST NOT
   include Shared CGN Space in zone files.  When running a split DNS
   infrastructure, Service Providers MUST NOT include Shared CGN Space
   in external-facing zone files.

   Reverse DNS queries for Shared CGN Space addresses MUST NOT be
   forwarded to the global DNS infrastructure.  DNS Providers SHOULD
   filter requests for Shared CGN Space reverse DNS queries on recursive
   nameservers.  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].

   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



Weil, et al.              Expires April 5, 2012                 [Page 6]


Internet-Draft          Shared CGN Space Request            October 2011


   addresses.


















































Weil, et al.              Expires April 5, 2012                 [Page 7]


Internet-Draft          Shared CGN Space Request            October 2011


5.  Risk

5.1.  Analysis

   Some existing applications discover the outside address of their
   local CPE, determine whether the address is reserved for special-use,
   and behave differently based on that determination.  If a new IPv4
   address block is reserved for special-use and that block is used to
   number CPE outside interfaces, some of the above-mentioned
   applications may fail.

   For example, assume that an application requires its peer (or some
   other device) to initiate an incoming connection directly with its
   CPE outside address.  That application discovers the outside address
   of its CPE and determines whether that address is reserved for
   special-use.  If the address is reserved for special-use, the
   application rightly concludes the that address is not reachable from
   the global Internet and behaves in one manner.  If the address is not
   reserved for special-use, the application assumes that the address is
   reachable from the global Internet and behaves in another manner.

   While the assumption that a non-special-use address is reachable from
   the global Internet is generally safe, it is not always true (e.g.,
   when the CPE outside interface is numbered from globally unique
   address space but that address is not advertised to the global
   Internet as when it is behind a CGN).  Such an assumption could cause
   certain applications to behave incorrectly in those cases.

5.2.  Empirical Data

   As described in [RFC6269] and [I-D.donley-nat444-impacts], CGNs offer
   a reasonable quality of experience for many basic services including
   web, email, and Instant Messaging.  This is true regardless of
   whether the address range between the CGN and CPE is globally unique,
   Shared CGN Space, or [RFC1918] space.  However, CGNs do adversely
   impact some advanced services, in particular:

   1.  Console gaming - some games fail when two subscribers using the
       same outside public IPv4 address try to connect to each other.

   2.  Video streaming - performance is impacted when using one of
       several popular video streaming technologies to deliver multiple
       video streams to users behind particular CPE routers.

   3.  Peer-to-peer - some peer-to-peer applications cannot seed content
       due to the inability to open incoming ports through the CGN.
       Likewise, some SIP client implementations cannot receive incoming
       calls unless they first initiate outgoing traffic or open an



Weil, et al.              Expires April 5, 2012                 [Page 8]


Internet-Draft          Shared CGN Space Request            October 2011


       incoming port through the CGN using [I-D.ietf-pcp-base] or
       similar mechanism.

   4.  Geo-location - geo-location systems identify the location of the
       CGN server, not the end host.

   5.  Simultaneous logins - some websites (particularly banking and
       social networking websites) restrict the number of simultaneous
       logins per outside public IPv4 address.

   6.  6to4 - 6to4 requires globally reachable addresses, and will not
       work in networks that employ addresses with limited topological
       span such as those employing CGNs.

   Based on testing documented in [I-D.donley-nat444-impacts], the CGN
   impacts on 1-5 are comparable regardless of whether globally unique,
   Shared CGN Space, or [RFC1918] addresses are used.  There is,
   however, a difference between the three alternatives in the treatment
   of 6to4.

   As described in [RFC6343], CPE routers do not attempt to initialize
   6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN
   addresses.  When configured with globally unique or Shared CGN Space
   addresses, such devices may attempt to initiate 6to4, which would
   fail.  Service Providers can mitigate this issue using 6to4-PMT
   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or blocking the
   route to 192.88.99.1 and generating an IPv4 'destination unreachable'
   message [RFC6343].  When the address range is well-defined, as with
   Shared CGN Space, CPE router vendors can include Shared CGN Space in
   their list of special-use addresses (e.g., [RFC5735]) and treat
   Shared CGN Space similarly to [RFC1918] space.  When the CGN-CPE
   address range is not well-defined, as in the case of globally unique
   space, it will be more difficult for CPE router vendors to mitigate
   against this issue.

   Thus, when comparing the use of [RFC1918] and Shared CGN Space,
   Shared CGN Space poses an additional impact on 6to4 connectivity,
   which can be mitigated by Service Provider or CPE router vendor
   action.  On the other hand, the use of [RFC1918] address space poses
   more of a challenge viz-a-viz Shared CGN Space when the subscriber
   and Service Provider use overlapping [RFC1918] space, which will be
   outside the Service Provider's control in the case of unmanaged
   service.  Service Providers have indicated that it is more
   challenging to mitigate the possibility of overlapping [RFC1918]
   address space on both sides of the CPE router than it is to mitigate
   the 6to4 impacts of Shared CGN Space.





Weil, et al.              Expires April 5, 2012                 [Page 9]


Internet-Draft          Shared CGN Space Request            October 2011


6.  Security Considerations

   Similar to other [RFC5735] special use IPv4 addresses, Shared CGN
   Space does not directly raise security issues.  However, the Internet
   does not inherently protect against abuse of these addresses.
   Attacks have been mounted that depend on the unexpected use of
   similar special-use addresses.  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 and should consider including Shared CGN Space in
   Ingress Filter lists [RFC3704] unless their Internet service
   incorporates a CGN.

   To mitigate against potential misuse of Shared CGN Space, except
   where required for hosted CGN service or similar business
   relationship,

   o  Routing information about Shared CGN Space networks MUST NOT be
      propagated across Service Provider boundaries.  Service Providers
      MUST filter incoming advertisements regarding Shared CGN Space.

   o  Packets with Shared CGN Space source or destination addresses MUST
      NOT be forwarded across Service Provider boundaries.  Service
      Providers MUST filter such packets on ingress links.

   o  Service Providers MUST NOT include Shared CGN Space in external-
      facing DNS zone files.

   o  Reverse DNS queries for Shared CGN Space addresses MUST NOT be
      forwarded to the global DNS infrastructure.

   o  DNS Providers SHOULD filter requests for Shared CGN Space reverse
      DNS queries on recursive nameservers.


















Weil, et al.              Expires April 5, 2012                [Page 10]


Internet-Draft          Shared CGN Space Request            October 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 April 5, 2012                [Page 11]


Internet-Draft          Shared CGN Space Request            October 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.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-13 (work in progress), July 2011.

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



Weil, et al.              Expires April 5, 2012                [Page 12]


Internet-Draft          Shared CGN Space Request            October 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",
              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.

























Weil, et al.              Expires April 5, 2012                [Page 13]


Internet-Draft          Shared CGN Space Request            October 2011


Appendix A.  Acknowledgments

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

      Stan Barber

      John Brzozowski

      Isaiah Connell

      Greg Davies

      Owen DeLong

      Kirk Erichsen

      Wes George

      Chris Grundemann

      Tony Hain

      Philip Matthews

      John Pomeroy

      Barbara Stark

      Jean-Francois Tremblay

      Leo Vegoda

      Steven Wright

      Ikuhei Yamagata















Weil, et al.              Expires April 5, 2012                [Page 14]


Internet-Draft          Shared CGN Space Request            October 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 April 5, 2012                [Page 15]


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