Thus wrote Keith Moore ([email protected]):
[...]
> - Define a single, standard, mechanism that applies regardless of which kind
> of NATs are being used, that lets applications cope. This includes things
> like finding an global transport address that's associated with an internal
> transport address, creating bindings (subject to policy) that allow incoming
> connections, maintaining bindings in stateful NATs, destroying bindings when
> they're no longer used, hooks to allow both application and host OS access to
> such functions, support for split NAT, etc. (for there to be a single
> standard mechanism it has to be more versatile than NAT66 needs)
You seem to fail to grasp that in a network where NAT is not forced on the
local network admin for lack of address space, but chosen as a vote
of no confidence regarding the hosts that are being NATted and because of
scaling problems, applications that need what you propose will go splat on
the firewall anyway. It's not for installations with a small enough number
of hosts that you'd renumber the lot with a bit of grousing on a Saturday
afternoon, it's for large and/or complex networks, and there will be
stateful firewalls as a matter of course long before there will be a need
for NAT.
In a world where even subnets are plenty, if I have a few hosts that I want
to run an app like that I can assign them their very own public /64 in their
own DMZlet. A /56 has as many subnets as a v4 /24 has addresses. A /48 has
as many subnets as a v4 /16 has addresses. Stateless prefix translation
as suggested here only uses up one /64 per inside /64, there'll still be
enough to go round. Uses will be found once one can wallow in address space :>
regards,
spz
--
[email protected] (S.P.Zeidler)
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
