On 8 jul 2009, at 15:12, Rémi Després wrote:
The u/l bit is reserved for global use as Brian Carpenter also noted.
Well, it gets complex.
Discussing the point offline in Stockholm might be better than by
mail.
Would that be useful?
The whole point of NAT64 is to work with unmodified clients. So the
clients don't care.
The DNS64 has to stuff the IPv4 bits somewhere in the IPv6 bits.
Although it's simpler to do that at a 32 bit boundary (and a 16 bit
boundary has checksumming advantages), as far as I know all of this
happens in software and can be handled fast enough even if the rules
get more complex to have decent performance on a normal DNS server
like machine.
On the NAT64 translator side I'm a bit worried that vendors may want
to use hardware acceleration which won't be very flexible with regard
to the place in the IPv6 address where the IPv4 address appears. For
that reason, I would like to mandate that the IPv4 bits ALWAYS appear
in the bottom 32 bits of the IPv6 address. But we can leave this upto
the vendors, if they can afford to be flexible they'll be flexible and
customers that need flexibility will buy those products, if
flexibility is too expensive they won't put it in and only people who
don't care buy the products.
Especially if we assume that the vendors of DNS64s and NAT64s are
going to be the same there are no problems with updating the prefix
format so there is no need to specify one other than a reasonable
default, which would obviously be <whatever>/96 + IPv4 because that's
what existing NAT-PTs do.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
