Subject: [rrg] ILNP Critique

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jan 2010 08:54:28 -0500

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jan 2010 09:00:55 +1300

On 2010-01-12 02:54, Joel M. Halpern wrote:
.
> address this.  ICMP is clearly insufficient.

As a side comment, RFC5534 is somewhat more than a proof of concept
that solves this problem. Although it's designed as part of shim6,
the method could be extracted.

    Brian

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Jan 2010 06:17:35 -0800

> that were expressed to me.

This has been received and incorporated.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 17 Jan 2010 21:05:59 -0800

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
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Tony Li <[email-masked]>
Date: Sun, 17 Jan 2010 23:24:15 -0800

Lixia Zhang wrote:
> 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?
> 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jan 2010 09:08:39 -0500

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:
>> 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
>>

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 21:03:31 -0800

On Jan 18, 2010, at 6:08 AM, Joel M. Halpern wrote:

> 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.

hey ietf motto is "rough consesus", so I suppose our word limit is  
also just a "rough limit" as I cannot see why 499 words vs 510 words  
would make a writing better or worse. Some text in the original  
writing could also be removed without losing much

I think here is how I see the issue:

1/ people argue all the time that every host and every application  
depend on DNS.

2/ however DNS itself cannot depend on DNS.  This translates to that  
all DNS servers must have IP addresses as defined today, i.e. no  
composition of two parts.

- All DNS authoritative servers must have their glue RRs carrying full  
IP address and stored at their parent zones; no composition.  And

- the same for DNS caching resolvers whose addresses must be the full  
length without any composition/lookup/whatever, to be configured into  
end hosts.

    Another specific detail here is that caching resolvers are
    not necessarily close to end hosts (e.g. I'm among those
    who use own resolver no matter where I go).

My earlier statement seems an accurate summary of the situation: we  
are seeing an architecture with at least two types of IP6 addresses,
   one for all DNS servers (both authoritative and resolver types),
   one for everything else.

(this picture gets me worry, as human beings are not known to always  
keep their head straight to tell what is what...)

>> 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)
>> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Jan 2010 08:08:12 -0500

With ILNP (and probably some of the other proposals that use DNS) there 
are not two kinds of addresses.
The addresses used for DNS servers are just like the ones used for the 
rest of the system.
The only difference in ILNP is that clients get thos I/L pairs directly 
rather than needing to do a DNS lookup to get the pair of fields.

Yours,
Joel

Lixia Zhang wrote:
>> ...) 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.
>>
>> 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
>>
>> But given the word limit, I felt I needed to focus on things that had 
>> more impact.
> 
> hey ietf motto is "rough consesus", so I suppose our word limit is also 
> just a "rough limit" as I cannot see why 499 words vs 510 words would 
> make a writing better or worse. Some text in the original writing could 
> also be removed without losing much
> 
> 2/ however DNS itself cannot depend on DNS.  This translates to that all 
> DNS servers must have IP addresses as defined today, i.e. no composition 
> of two parts.
> 
> My earlier statement seems an accurate summary of the situation: we are 
> seeing an architecture with at least two types of IP6 addresses,
>>> that is missing, i.e. the one Robin tried to raise a few times: how 
>>> to handle DNS server IP addresses.
>>> would imply all DNS servers for UCLA.edue that are located on campus 
>>> would have ILNP addresses, correct?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jan 2010 09:10:27 +1300

> rather than needing to do a DNS lookup to get the pair of fields.

The circularity rule [RFC1958], which iirc was drafted by Jon Postel,
actually says:

   3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

It does seem that ILNP satisfies this; I'm not sure that all the schemes
that use DNS for mapping do so.

    Brian