Lixia Zhang wrote:
I'm late catching up email.
This critique is clearly written, though I do see one important issue
that is missing, i.e. the one Robin tried to raise a few times: how to
handle DNS server IP addresses.
Let me try an example here: say that UCLA implemented ILNP, that would
imply all DNS servers for UCLA.edue that are located on campus would
have ILNP addresses, correct?
But UCLA.edu also needs to put its NS RRs and glue RRs (IP addresses for
NS RRs) on .edu servers, and I assume these glue RRs must be treated as
traditional 16-byte IP6 addresses? (i.e. they are not subject to further
interpretation/composition, a DNS resolver gets a glue RR and uses it
directly to reach the DNS server)
Then are we talking about an architecture with two types of IP6 addresses?
My personal view is that this is not details, it shows that the design
has a recursion: we need DNS to get IP addresses; we need IP addresses
to reach DNS servers.
Perhaps some clarification is necessary, but the basics are quite sane:
All systems would get IPv6 addresses. This is absolutely necessary for
backward compatibility.
ILNP nodes would ALSO get I and L records.
DNS delegations today already (necessarily) do delegations on an address
(not FQDN) basis to avoid just this recursion. Clearly, this already
works for IPv4. It allegedly works for IPv6, tho I can't vouch for
that. ;-) ILNP does not change this model significantly. Perhaps the
only thing that would be useful is to have an API knob (socket option)
that allows an application (i.e., DNS) to bypass ILNP and operate in
legacy v6 mode.
Is this clear enough?
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
