Re: [OPSAWG] Heads up - Plea for allocating a /8 to ISPs

> It's unfortunate that IETF wants to slow down IPv6 deployment by forcing 
> ISPs to put more resources on NAT444, but so be it.
> Barbara
[Wes] I'm not convinced by the hyperbole. NAT444 is hard and is going to take 
lots of resources regardless of what block you use for your internal range, 
and IPv6 deployment is not optional if you'd like to stay in business. There 
are lots of us in the same boat, and it's not an either/or decision. We're 
behind, and we're playing catch-up. The IETF shouldn't be the scapegoat for 
that.

Erik Kline said:
I'm not sure this logic stands up in the light of the experiences of those who 
have tried NAT444 and chosen to do something else.

[Wes] those = ? Something else = ? Are you referring to Cameron's comments 
about bagging it in favor of NAT64? I'm not aware of anyone with a legacy set 
of IPv4-only devices that they need to keep functional for some nonzero amount 
of time coming up with a magic solution that doesn't involve NAT444, changes 
on the host that aren't possible, or copious amounts of global address space 
that won't be available. If there is, I'd love to hear it. Barbara is right 
about one thing, nothing will change the fact that NAT444 is going to be 
required for legitimate business reasons, mainly that it's cheaper and quicker 
than throwing hardware at the problem to turn over your entire device pool 
rapidly instead of waiting for it to happen on an upgrade cycle.

Erik Kline said:
For those contemplating NAT444, what's wrong with NAT464?  In theory that 
middle "4" represents a single, logical administrative domain, no?

[Wes]
What's wrong with NAT464 is that NAT64 (whether there's a 4 in front of it or 
not) requires the device sitting at the boundary of the "4s" to speak IPv6. 
Trust me, I'd love to have a network full of devices that can do Native IPv6 
so that I could seriously consider NAT64 as a solution. But I don't, and I 
won't soon enough to make that a realistic solution.

That said, I am not in favor of allocating a specific block to do NAT444 with. 
It's a waste of resources. Due to the fact that we've gone from originally 
asking for a /8 to a /10, and there are folks who would need much more space 
than even one /8 for it to actually solve their problem, it simply doesn't 
help enough. Most of the intended users would still have to have multiple 
overlapping regions of this block just like they'd have to do if they used 
RFC1918, so literally the only problem this solves is the assertion that 
RFC1918 is not usable because of overlap with CPE devices that use it on their 
inside network and the risk of customer impact that generates.

Don't like that risk? I'll quote Cameron: "For the NAT444, LSN, CGN folks. 
Come on in the waters fine, pick a bogon up at the door"

Though I seriously doubt that IETF will officially sanction squatting on 
unrouted public space for internal NAT as a solution to this problem, people 
are currently (and will continue) doing this. It's ugly, risky, unholy, and 
generally "regarded as harmful" but most of the time it works. And though 
there will be financial incentive to find unused IPv4 space (thereby reducing 
the amount of Bogon available) there are plenty of legacy address holders that 
have no intention of either giving back/selling their space or making it 
visible on the Internet anytime soon.

Wes George

_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops