It seems pretty obvious that you handle DNS addresses just the way you
do today. You configure the client (either directly, or via DHCP, or
...) with the I/L pairs of the DNS servers. Since DNS transactions are
short, the client simply uses each one as a server individually, and
does not try any address agility or other fancy techniques.
Yes, this should be written down. But it is not hard, nor complicated,
and it certainly doesn't lead to recursion.
It does mean that, just as today, if the DNS server one is using gets
renumbered, the configuration information has to get changed. Well, it
is pretty hard not to need that anyway. For any mapping system, the
mapping data requester has to avoid using the mapping system to find the
mapping system.
Yours,
Joel
PS: If you and Tony want to relax the 500 word limit, I am happy to add
a small discussion of the need for more clarity on this issue. But
given the word limit, I felt I needed to focus on things that had more
impact.
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.
Lixia
On Jan 11, 2010, at 5:54 AM, Joel M. Halpern wrote:
Below is a 500 word critique of ILNP that Yakov Rekhter and I have put
together. I appreciated the comments that other folks sent about
ILNP. I apologize for not being able to adequately capture all the
concerns that were expressed to me.
Yours,
Joel M. Halpern
The primary issue for ILNP is how the deployment incentives and
benefits line up with the RRG goal of reducing the rate of growth of
entries and churn in the core routing table. If a site is currently
using PI space, it can only stop advertising that space when the
entire site is ILNP capable. This needs at least clear elucidation of
the incentives for ILNP which are not related to routing scaling, in
order for there to be a path for this to address the RRG needs.
Similarly, the incentives for upgrading hosts need to align with the
value for those hosts.
A closely related question is whether this mechanism actually
addresses the sites need for PI addresses. Assuming ILNP is deployed,
the site does achieve flexible, resilient, communication using all of
its Internet connections. While the proposal address the host updates
when the host learns of provider changes, there are other aspects of
provider change that are not addressed. This includes renumbering
router, subnets, and certain servers. (It is presumed that most
servers, once the entire site has moved to ILNP, will not be concerned
if their locator changes. However, some servers must have known
locators, such as the DNS server.) The issues described in
draft-carpenter-renum-needs-work-04 will be ameliorated, but not
resolved. To be able to adopt this proposal, and have sites use it,
we need to address these issues. When a site changes points of
attachment only a small amount of DNS provisioning should be required.
The LP record is apparently intended to help with this. It is also
likely that the use of dynamic DNS will help this.
The ILNP mechanism is described as being suitable for use in
conjunction with mobility. This raises the question of race
conditions. To the degree that mobility concerns are valid at this
time, it is worth asking how communication can be established if a
node is sufficiently mobile that it is moving faster than the DNS
update and DNS fetch cycle can effectively propagate changes.
This proposal does presume that all communication using this mechanism
is tied to DNS names. while it is true that most communication does
start from a DNS name, it is not the case that all exchanges have this
property. Some communication initiation and referral can be done with
an explicit I/L pair. This does appear to require some extensions to
the existing mechanism (for both sides adding locators). In general,
some additional clarity on the assumptions regarding DNS, particularly
for low end devices, would seem appropriate.
One issue that this proposal shares with many others is the question
of how to determine which locator pairs (local and remote) are
actually functional. This is an issue both for initial communications
establishment, and for robustly maintaining communication. While it
is likely that a combination of monitoring of traffic (in the host,
where this is tractable), coupled with other active measures, can
address this. ICMP is clearly insufficient.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg