Sorry for crossposting, but I think this is relevant both for BEHAVE
(NAT people) and RRG (routing people). Please prune the to/cc in your
replies as appropriate.
We've had some discussions about NAT66 on the BEHAVE list which were
mostly the traditional issues: people will implement it regardless, if
the IETF produces a spec at least we can avoid more brokenness than
necessery, etc.
These are all relevant arguments. But there is a reason why NAT66 may
be useful that goes beyond all of that. In 1996 Mike O'Dell came up
with an idea named 8+8 and later GSE where the top 64 bits of the IPv4
address are used for routing and the bottom for identification. This
is problematic for a number of reasons, but one aspect of this idea is
very promising: routers get to rewrite the top 64 bits of addresses.
Currently, either routers ignore the addresses and then we have no
accountability if a user with ISPs A and B sends a packet with an A
address to B, or B blocks the packet and we have accountability but no
connectivity. This is an issue that we didn't really manage to solve
with shim6, which uses the "take addresses from all ISPs" model.
Rewriting in routers would give us both connectivity AND
accountability, as well as a hint for the return path.
With some extra logic, a proxy shim6 can be built on top of this
rewriting capability that would make shim6 much more palatable to many
end-users so it may reduce the demand for PI address space and
therefore the pressure on the routing system.
So if we adopt NAT66 we will be giving up something (the idea that
referrals can work easily) but at the same time we gain a lot of
potential for the future. But only if we specify NAT66 such that it
can apply to all transports and still allow incoming sessions. If we
end up with an IPv4-style port overloading NAT66 we gain nothing and
lose a lot.
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
