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

[Chris Donley <[e-mail]>]

-----Original Message-----
From: Joel Jaeggli [mailto:[e-mail]] 
Sent: Wednesday, August 04, 2010 2:45 PM
To: Chris Donley
Cc: [e-mail]
Subject: Re: [OPSAWG] comment on draft-weil-opsawg-provider-address-space-00.txt

On 8/4/10 12:16 PM, Chris Donley wrote:
> 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.

I'm not sure for whose benefit you're explaining this, I've had dual
stack networks in operation since 2001 and I'm feeling the same ipv4
addressing pressure that you are. the fact that there will be no flag
day should be obvious to everyone on this list.

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

No, this draft is taking a /8 from the free pool and assigning it for
private use. A private use address pool already exists. and is by your
assertion not sufficient for the purpose.


[[CD]] Right.  The current private address pool is not sufficient.  Where should the new address allocations for these transition technologies come from?  A number of operators could make separate requests to the RIRs; assuming they were granted, the aggregate effect is likely to be greater than a /8.  Given the scarcity of remaining IPv4 addresses, we believe that this proposal ties up a smaller amount of address space for transition technologies, and allows a greater percentage of the remaining space to be allocated 

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

you are in fact not requesting that it be shared by operators, you are
assigning it to the pool of private use addresses. and you are hoping
that through some form of magic it will be less impactful that reusing
the existing private use addresses.

[[CD]] We know that there may be some cases where an enterprise uses >1 /8 and we run into collisions.  We expect that number to be smaller than the number of networks that use Net 10, generally.  We expect the number of operational problems to decrease accordingly (not to 0, but to a more manageable number).

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

then you draft should propose a mechanism by which operators can be
assigned use of the prefix because as it stands right now it's simply
assigned under the private use definition, which means the rest of us
are going to use it immediately.

[[CD]] We do not want to create a new enforcement mechanism to make sure that only operators are using this space. 

  We can even use 'polluted'
> space (e.g. 1/8, which was recently assigned to APNIC).

Have you looked in your routing table? 1/8 is being assigned. so you're
a little late to the party on that. Any prefix assigned to an rir from
the IANA free pool will be used, no matter how "polluted" it might be.

just a small sampling...
<<snip>>
[[CD]] I was pointing to 1 as an example of "polluted" space, not as a request to IANA.

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

And... you'd be wrong, try talking to some mobile carriers, next please.

[[CD]] So is your argument that we should request *more* /8s (e.g. the three requested in http://tools.ietf.org/html/draft-hain-1918bis-01) to accommodate such operators? 

> Chris
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Joel Jaeggli Sent:
> Tuesday, August 03, 2010 5:09 PM To: [e-mail] 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 
> [e-mail] https://www.ietf.org/mailman/listinfo/opsawg
>