Re: [OPSAWG] comment on draft-weil-opsawg-provider-address-space-00.txt

Operators accept that IPv6 is the long-term answer to this problem, but in the short-term, key products DO NOT currently have sufficient IPv6 support to enable it today, or to disable IPv4 support once IPv6 is enabled.  Both protocols will have to coexist for a while, and customers will demand IPv4 service even after IPv4 space is exhausted.  We don't have the luxury today of repeating the NCP-IPv4 transition plan from 1983: NCP was completely disabled on 1/1/83, and parts of the Internet were unavailable for months afterwards.  

So where do we go from here?  The IETF has identified a number of transition/coexistence technologies that deal with users' needs to continue IPv4 support, and also allow IPv6 deployments even before all of the devices have sufficient IPv6 support.  Two promising technologies are NAT444 and 6RD (non-exhaustive list). Unfortunately, both of them require IPv4 address space between the CE router and the CGN/BR/etc. device.  This is the problem our draft is addressing.  draft-azinger-additional-private-ipv4-space-issues does a good job describing the available options and the issues with each.  Each of the options is problematic.

Of all of the bad options, we believe requesting a /8 to be shared among operators is least bad.  We can deal with the operational impacts; they are more predictable than with some of the other options.  Even 'polluted' address space is acceptable.  However, it becomes operationally difficult to have the same private space on both sides of the CE router.  So, given the prevalence of Net-10, operators need another address block of comparable size to support these deployments of NAT444 and 6RD.  We can even use 'polluted' space (e.g. 1/8, which was recently assigned to APNIC). 

Regarding the size of our request, we've spoken with a number of very large operators, even those that have exceeded a /8 on their networks, and believe that a /8 is sufficient to support NAT444 and 6RD deployments until users migrate to IPv6.

Chris

-----Original Message-----
From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Joel Jaeggli
Sent: Tuesday, August 03, 2010 5:09 PM
To: OPSAWG@ietf.org
Subject: [OPSAWG] comment on draft-weil-opsawg-provider-address-space-00.txt

I re-read the draft on me way home from the IETF an I've reached the
same conclusion that I arrived at during opsawg...

At best this proposal does not achieve it's aim. simply assigning
another prefix under the 5226 definition of private use does nothing to
address the issue of address overlap, not only is an additional /8 not
sufficient in large provider networks, but there's not reason to suspect
that additional applications of a new private prefix will not
immediately spring up.

   o  RFC1918 Overlap: Utilization of separate assignment can remove the
      challenge of [RFC1918] address overlap between the home network
      environment and the provider network.

Any alleviation of this assignment would provide is at best temporary.

   o  Removes need to use bogon/non-assigned Space: Providers can avoid
      the use of bogon and/or non-assigned space (to the local party)
      within their networks.  This type of address usage can be
      problematic to customers.

There won't be any non-assigned prefixes in the future. and the people
doing this today are living on borrowed time on the basis of bad
decisions they made in the past. holding out home of renumbering into
virgin space is essentially defering and expense into the future with an
incrementaly lower but cumulatively more expensive solution becasue and
a addtional /8 isn't large enough to preclude the need for parallel
address deployements and renumbering remains a costly exercise.

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg