On 23 jul 2008, at 23:05, Dave Thaler wrote:
People that deploy v6-only networks will just hand out a DNS64 server
address as the IPv6 address all clients should use for their DNS
server.
(Don't forget that until the EDNS0 SAS option is supported, you really
don't want to give hosts with dual stack reachability synthetic AAAA
records.)
Hence Brian Carpenter's suggestion to default to v4mapped but allow
configuration to support some other prefix, which sounds reasonable.
No, this is a bad solution, because it requires that we address the
limitations of both options, and ISPs may opt for one while end-user
equipment only supports the other.
We need to pick one. If people then choose to implement administrative
overrides, that's their choice, but that means that the burden to make
it work is on those implementers/operators.
However, I would still argue strongly that we should not require
changes
to existing dual-stack nodes in order to deploy something that doesn't
break apps. (Requiring changes in IPv6-only nodes is much less bad,
although still undesirable.)
Well, for things to work well, we pretty much need updates: the EDNS0
option if we go with arbitrary translator prefixes, allowing v4mapped
addresses on the wire if we go with v4mapped.
Fortunately, all systems that we can assume to run in IPv6-only
environments in the future can download patches over the internet, so
this isn't a show stopper.
At the same time, it is of course very helpful to make sure that
unupdated systems can work reasonably well. But I don't think we
should optimize for this at the expense of having a solution that
works well on updated hosts.
For informational purposes, it might be interesting to
repeat your experiments using the range ::/96
Sure, as long as we're testing anyway. Not sure what the advantages of
using this range would be, though.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
