Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert <[e-mail]>]

On Tue, 2012-02-14 at 19:26 -0600, Pete Resnick wrote:
> On 2/14/12 2:35 PM, Randy Bush wrote:
> 
> > what silliness.  it will be used as rfc 1918 space no matter what the document
> > says.
> > [...]
> > any thought that this is not just adding to rfc 1918 is pure bs.
> >    
> 
> Of course it will be used as 1918 space. That's not the point of the text.

No support.

For the various reasons people have put forth, and my own below, this
draft should not be put through.

> The text is saying, "You could read 1918 to say that we somehow promised 
> that you would never be connected to a network run by someone other than 
> yourself and see 1918 addresses on it. That's not an entirely 
> intelligent reading, but we see how you can read it that way. So, if you 
> built yourself a device where it isn't able to deal with 1918 addresses 
> on its 'outside' interface that you were using on the 'inside' 
> interfaces, we could see how that might happen. It was not at all smart 
> of you to build your device that way, but you probably were technically 
> within spec. Now we're adding some address space to the pool. It's not 
> global and it's not routable, just the same as 1918 space. But we're 
> letting you know right now: You *will* see these addresses on networks 
> that you don't run. If you want to use this space the way that you used 
> 1918 space, peachy, but understand that if you're unable to deal with 
> these addresses duplicating ones you're using, your device is toast. 
> Deal with it."

This is 100% matched by an allocation of globally unique space from a
RIR, shared by whoever the interested parties are. 
  The IETF *need not* specify any BCP on how to improve NAT444
"CGN"-scale alone, because such action is attached with high risk of
leading to a local maximum in a plot of the state of the Internet,
rather than towards a global maximum.

Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
Transition" warns:
   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
   Scale NAT, compounds IPv4 operational problems when used alone but
   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
   NAT444 CGN allows ISPs to delay the transition and therefore causes
   double transition costs (once to add CGN and again to support IPv6).

The draft as written, makes no effort to require the RFC6264 or
equivalent approaches to a IPv6 transition, to the CGN deployments it
specifies v4 address space for. All carrot, no stick.
  I believe the state of the Internet would be much more reliably
improved by the RIRs each having (for the purpose of being able to serve
their own users) one /10 special allocation for this purpose, which they
can assign to multiple users upon demonstrating, under contract, they
are transitioning to IPv6 according to 6264, or equivalent.

As written there is no effort to mitigate the risk mentioned in the
quote above, and I can't support a draft that will hurt the Internet and
neither should you.

Best,
Martin