On Mar 20, 2009, at 14:27, Brian E Carpenter wrote:
On 2009-03-21 10:01, james woodyatt wrote:
Soon, after NAT66 is approved for the standards track by IESG,
despite
the "strong recommendations" from the IAB in this draft, end-to-end
addressability in IPv6 will be the result of explicit coordination
between address realm operators rather than a reasonable
expectation of
the public Internet in general. Just as it is today with IPv4.
End-to-end in IPv6 will be a fleeting memory of what could have been.
If you mean that corporate intranets will want to be isolated from
e2e routing, I'm sure that's inevitable.
No, I mean that we may expect to see both corporate and residential
networks wanting to be insulated from e2e *addressing*, not just
routing. I predict they may come to regard address referrals being
broken by translators, except within explicitly coordinated address
realms and mediated by middleboxes (like residential gateways), as a
*feature* of NAT66 rather than an error. Certainly, some of my
colleagues already think that way.
Sure, you could say they're *blindly* copying the IPv4/NAT model, but
they don't see it that way. They think the IPv4/NAT model is better
than the IPv6 model *because* it breaks address referrals. They like
that referrals generally don't work unless you're in the same address
realm or there's an application rendezvous service somewhere mediating
address realm traversal-- *that's* a service that can usually be
blocked by default and opened only where policy allows.
But that does not, thanks
to IPv6 multi-prefix addressing, nullify global addressing in the way
that RFC1918 did. I'm sure that as time goes on, a new generation of
corporate IT managers will come to deploy IPv6 using the IPv6 model,
instead of just blindly copying the IPv4 model. Give it time.
Give it time give it time... I'd like to see the IESG tell the NAT66
proponents they should "give it time" -- let them go ask IRTF for a
new research group.
I don't expect that would go over well.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
