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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf