Subject: [rrg] ILNP critique 4

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Jan 2010 00:56:24 +1100

Short version:  This is my fourth critique of ILNP.
                The third points to the previous two:

    http://www.irtf.org/pipermail/rrg/2009-January/000701.html

Hi Joel,

I just read the IDs at: http://ilnp.cs.st-andrews.ac.uk/ which are
all different from the latest versions at the IETF site.

Further to my point 2, here are some more thoughts on ILNP and the
extra traffic, work, delays etc. it involves - and why this is
unacceptable since there are going to be billions of hosts, probably
the majority, linked by slow, flaky and expensive wireless links.

Following that some further general critiques of ILNP, as best I can
understand it from these IDs.

DNS lookups involve a global query server network, so these lookups
may be slow and unreliable. They may also involve multiple exchanges
with various servers in order to find the authoritative server.

DNS servers can presumably be on ILNP addresses - that is, they are
on ILNP-using hosts which are found via their FQDN, which is then
(via a further DNS lookup . . .) turned into an Identifier and
Locator (or multiple Identifiers and Locators, each with a priority,
enabling one of each to be chosen).

If DNS servers are not allowed to be on ILNP addresses, this would be
a major constraint on the usefulness of this type of address space.
If end-user networks can't run their own DNS servers, but must use
servers run by ISPs on conventional IPv6 addresses, then this would
be a reason to prefer some other solution which does not have this
constraint.

This text, on page 12 of draft-rja-ilnp-intro-03 seems to confirm
that DNS servers may be on ILNP addresses, rather than ordinary IPv6
addresses:

   it is preferable to deploy the DNS server function on nodes that
   have longer TTL values, rather than on nodes that have shorter TTL
   values.

So the initial action of sending a user packet to another host looks
potentially complex.  The starting point is presumably an FQDN, which
is used for a DNS lookup.  If the host has to do this itself, without
an external resolver, then it may have to do such lookups for
multiple DNS servers until it gets an authoritative one.  Each such
lookup may involve other lookups just in order to communicate with a
DNS server.

Let's say there are two hosts:

  Host 1:   FQDN ABC     Locator XX  Identifier AA

  Host 2:   FQDN DEF     Locator YY  Identifier DD

ABC initiates a communication with DEF and DEF responds:

   ABC does a DNS lookup using DEF as a key, and receives DD and YY.

   (However, this may take a while, and involve multiple DNS lookups,
    plus DNS lookups of DNS servers in order to be able to do each
    such lookup.)

   ABC sends (from its 128 bit address XXAA) a traffic packet to DEF
   (addressed to the 128 bit address YYDD) and this initial traffic
   packet has a destination option containing a nonce which ABC
   generates specifically for this communication session with DEF.

   The nonce could be 32 bits, but 96 bits would be more secure.

   DEF receives this, and does a reverse lookup on AA - it can't
   just send something back to XXAA on the assumption that XX
   is the correct Locator for the host whose Identifier is AA.  So
   it does a reverse lookup on AA - which involves potentially
   multiple DNS lookups until an authoritative answer can be found.
   This is especially true with long IPv6 addresses which will
   involve going through a lot of levels of delegation.

   The reply contains XX and ABC.

   Now, DEF can send a traffic packet back to ABC.  It does so,
   appending an option header containing its own nonce, generated
   purely for this particular session with ABC.

See how each end has to do DNS lookups - slow, unreliable and on a
global query server network - before it can send user data to a host
it has not previously communicated with?

This stuff is frequently going to be done over slow, unreliable and
costly wireless links - because ILNP mandates that every host on the
newly structured Net will perform these tasks.

These items of information returned from DNS lookups have very short
TTL times.  The IDs don't specify how short - seconds or tens of
seconds - I have no idea.  They need to be short - ideally zero TTL -
because it is possible, at any time, that one or both hosts would
have a different locator.

As long as the hosts keep sending data to the addresses they
discovered in the above exchange, things will be OK until one of them
moves to a new locator.  Then, it should send out ICMP Locator Update
messages to all the hosts it might be expecting packets from.  This
could be a large number of hosts.  This message must contain in a
destination option the nonce originally sent by this host in the
initial traffic packets to each of these other hosts.

What if this ICMP Locator Update message does not arrive?

Traffic packets should contain the nonce destination option for a
certain amount of time in an effort to ensure that at least one of
these packets is received.  In draft-rja-ilnp-nonce-02, page 6, para
2, a time of 1 minute is mentioned.

So mobile hosts need to keep sending and receiving these destination
options for a minute or so.  This is a significant bandwidth burden,
especially for VoIP.

The burden of sending ICMP Locator Update messages to a bunch of
remote hosts is particularly a problem for hosts on wireless
networks.  What if the wireless link is flaky and these packets are
dropped in the link?  There's no way the host could sense this, so in
an effort to robustly communicate with all the other hosts, it would
have to send out several such packets, to each of its correspondent
hosts, spaced out by a few seconds, every time it changed its
locator.  This could be a frequent event in this approach to mobility.

Also, whenever a locator is added or lost, the host has to do a
secure DNS update to the DNS server which is the master for the
reverse mapping of its Identifier and I think the server (if it is
different) which is the master for the domain of its FQDN.  I am not
sure how this works when a host has multiple FQDNs.

As noted in draft-rja-ilnp-intro-03 page 13, TTLs for these DNS
replies must be very short, at least for the records of mobile hosts:

   short DNS TTL values are assigned to particular DNS records
   to ensure that the ubiquitous DNS caching resolvers do not
   cache volatile values (e.g. Locator records of a mobile node)
   and consequently return stale information to new requestors.

So any host communicating with a mobile host (I am using "host" and
"node" interchangeably here) is going to be burdened with frequent
DNS lookups - maybe every few or ten seconds, or is it every minute?
 There is no guidance in these IDs about actual times.

If host MMM is on a wireless link (expensive, slow and flaky) then
for every host it is communicating with which is mobile, then MMM
needs to perform these frequent DNS lookups.

This is a serious burden if MMM is itself on a wireless link.

Here are some other more general problems I perceive.

As best I understand it, secure DNS updates involve the host having a
secret key of some kind which is capable of authorising changes in
some DNS server.  This seems like a good target for an attack - if an
attacker could find this secret, such as by installing malware, then
they could wrest this identity from the proper host.  Perhaps the
secret would also enable changing DNS entries for other hosts in the
same domain.

The inclusion of Destination Options on all traffic packets for a
minute or so after the start of a session and after any change in
Locator is more than a burden on bandwidth.  It presents difficulties
with the host's stack telling its applications the maximum packet
length they can send.  I guess there would need to be a new API for
this, to enable the stack to dynamically alter the packet lengths it
accepts from applications, since applications themselves would not
want or need to know about the Locator change or the 1 minute time-out.

The purpose of the LP record in draft-rja-ilnp-dns-02 is not at all
clear.  The LP record is another FQDN, and there is no indication in
the data format diagram of where the length is specified.

The purpose is discussed on page 7 of draft-rja-ilnp-intro-03.  I
have a rough idea of what it is supposed to do, but I think this
section is quite hard to understand.

There are three kinds of record returned from a DNS query:

  One or more 64 bit Locators, each with a priority.
  One or more 64 bit Identifiers, each with a priority.
  Zero or multiple LP records, each a FQDN, each with a priority.

I could find no guidance on what a host is supposed to do with these
multiple records and their priorities.

Presumably the host would use the record with the numerically lower
priority, or choose arbitrarily between two records with the same
priority.

But what is the purpose of different priority levels?

Is the host so somehow determine that the most prioritised Locator,
Identifier or LP FQDN is somehow non-functional, and then to choose
the next most prioritized?   I think this proposal is far from being
properly described.

In draft-rja-ilnp-intro-03, page 10, there is mention of
split-horizon DNS servers.  I think this sort of thing should be avoided.

What is the relationship between multiple Identifiers and multiple
Locators?  I understand one physical host having one Identifier and
one or more Locators.  But how could a single host have two Identifiers?

Maybe the multiple Identifiers means that for a given FQDN there are
multiple physical hosts - as is done in today's usage of DNS, by
returning multiple IP addresses.  That's fine - but how does the
querying host decide which of these Locators belongs with each
separate Identifier?  Surely it would be too restrictive to mandate
that all these Identifiers had to be reachable via a common set of
Locators.  One of the purposes of having multiple physical hosts is
to put them in different data centres, where they will have different
locators - so that if one doesn't work, the application can try
another.

The general principle of using short caching times as a solution to
mobility, where the mobile devices could gain a new physical address
at any moment, strikes me as completely unscalable.  The DNS servers
for these mobile devices are going to get a hammering - and so hosts
themselves and resolvers must continually be doing these lookups as
long as communication is with a mobile host.

Also, the summary includes mention of an IPv4 version of ILNP.  I
recall debating this on the RRG in the past and deciding that it
wouldn't work.  The whole of ILNP relies on splitting the 128 bit
IPv6 address into two 64 bit sections.  Nothing of the sort can work
on IPv4.  There's no mention of an IPv4 version of ILNP in the four
IDs at: http://ilnp.cs.st-andrews.ac.uk/ .

 - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Jan 2010 11:35:54 -0500

Sorry, I don't see any sensible way to fold these into the critique we 
are writing.

To be specific, almost all communication currently depends upon DNS, and 
DNS is sufficiently responsive and reliable that people use it.  They 
often have to perform multiple lookups (although the human being does 
not realize that.)  As such, claiming that DNS "may be slow and 
unreliable" does not seem grounded in the facts, and I am not willing to 
include that.

The destination option affect on size / MTU is something stacks deal 
with quite happily today.

I would agree that the DNS document needs some improvement.  I believe 
Ran is working on that.  I do not believe that such clarity issues are a 
fundamental issue to be raised in a critique.  If, once the engineering 
beagn, the engineers decided that only one I record was allowed, that 
would not change the architecture being proposed.  The LP records are an 
optimization.  One I think the engineering requires, and which will 
require better explanation, but again not architectural in itself. 
(There is an architectural issue that may or may not be addressed by LP, 
which is in the critique, that renumbering has got to be practical.)

Yours,
Joel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Jan 2010 12:49:24 +1100

Hi Joel,

Thanks for your response.  Here's the shortest complete statement I
can think of about how ILNP would degrade performance in general, and
how this would be worse when one or both hosts are on slow or
unreliable links.

This involves some points which were not in my previous message -
about the DNS server having to do potentially multiple DNS lookups in
order to reply, and how each such lookup could itself involve more
DNS lookups . . . which themselves involve more DNS lookups.

  Today, two hosts can perform an initial exchange of application
  packets without the need to send any other packets or perform any
  kind of DNS or mapping lookup.  So the total time for the
  exchange is the RTT between the two hosts.

  Before two ILNP hosts can complete an initial exchange of
  application packets, the first host must perform a DNS lookup
  before sending its packet, and the second must do the same before
  sending its response.  Since DNS is a global system, and since
  response and query packets can be lost, this typically involves
  significant delays, even for hosts with fast, low-latency links to
  the DFZ.

  The DNS lookups themselves - whether performed by the host or
  by a nearby and better-connected resolver - may involve multiple
  queries to different servers in order to find an authoritative
  server.  This is exacerbated by the requirement to keep TTLs
  very short for any lookup concerning a mobile ILNP host.

  The total delay in receiving the DNS response is further
  increased by some or many of the DNS servers being on ILNP
  addresses - being identified by a FQDN and so requiring a DNS
  lookup to find the Identifier and Locator, just in order to
  send the query to the server.  Furthermore, if the querier
  is on an ILNP address, the DNS server cannot reply without
  also performing a DNS lookup (which itself may involve multiple
  DNS servers and further sets of DNS lookups in order to be able
  to send queries to these DNS servers).

  This burden of DNS lookup activity and the delays it imposes on
  any initial packet exchange would be a serious disincentive to
  the adoption of ILNP.

  These DNS lookup delays are significantly worsened for any
  host which is on a wireless link - such as a 3G link with
  cost, latency and reliability problems.

  In the future mobile hosts with 3G wireless links are likely to
  comprise a significant proportion of all hosts - probably the
  majority.  The performance degradation due to these DNS lookups
  over wireless links is a serious disincentive to adoption, as is
  the very high load placed on the global DNS system by the short
  RTT for all records concerning these billions of mobile hosts.

This won't fit in your 500 word critique, but at least it is here as
part of the RRG discussion.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Jan 2010 14:27:44 +1100

Hi Joel,

Further to my previous message, my concern about these recursive DNS
lookups is probably reduced by what I expect a DNS server would do
when returning a reference to a second DNS server which is more
authoritative: including the Locator and Identifier records of the
second server along with the FQDN which properly identifies the
second server.

Still, as far as I know, whenever a DNS server replies to a querier
(a sending host or its resolver) it has not recently sent a packet
to, it needs to perform a DNS lookup on that querier.  As far as I
can tell, this would be a reverse lookup of the Identifier part of
the source address in the query packet.  This would give it the FQDN,
which it probably doesn't need, but would also give multiple Locators
by which the querier could be reached.

In the case of the querier being a mobile host, the DNS server will
need to perform a reverse lookup even if it recently sent a packet to
this host, because the TTL on DNS records for mobile hosts will be
"very short".

When the mobile host sends a query to a resolver, the resolver will
be doing this stuff with one or more other DNS servers.  But when the
resolver needs to send the response back to the mobile host, it will
likewise typically need to do a reverse lookup on that host's
Identifier, because any cached reverse lookup records will have a
"very short" TTL.

So with ILNP, these DNS lookups keep multiplying like the Sorcerer's
Apprentice's brooms.

Just because DNS delay is judged to be "acceptable" in today's
Internet doesn't mean it will be with these ILNP changes.

I believe that even today's DNS delays are unacceptable when they add
to the time required to complete an exchange of initial packets.

All DNS lookups today are potentially slow or very slow due to DNS
being a global system and because they are all subject to failure and
the need for a retry if the query or response packet is lost.

I still have no idea how multiple Identifiers can be related to
multiple Locators.  ILNP has been in development for years and I
would have thought that obvious problems like this would have been
sorted out long ago.  If this is regarded as mere "engineering", then
I think the "architects" should take a greater interest in
engineering before being confident their overall structure is sound.

The solution is probably to have a set of Locators for each of the
Identifiers.

Likewise, what is the purpose of Identifiers and Locators with
priorities if the current IDs do not specify how a host is to choose
between them?  This isn't just low-level detail - it is fundamental
to the protocol design and therefore to the "architecture".

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Jan 2010 22:36:57 -0500

?  Why would the DNS Server need to perform a DNS lookup for ILNP?
The DNS server has received a request packet.  It has an ID and a 
locator.  The response will simply go back to the ID and locator pair 
the request came from.  There is no need to look up anything.

Yours,
Joel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Jan 2010 15:29:58 +1100

Hi Joel,

> the request came from.  There is no need to look up anything.

I was assuming that the DNS server performs the same process as any
other host when sent a packet from a host it has not recently
communicated with.

If DNS servers or any other hosts do not behave like this - and you
suggest that their behavior would be different - then this needs to
be clearly specified in the IDs.  I just read them and I don't recall
any statements to this effect.

I think we need to be careful about assumptions when major revisions
to the Internet protocols are being discussed.  Just because the ILNP
IDs mention DNS doesn't mean that these exchanges would be the same
as today's DNS exchanges.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Jan 2010 17:40:58 +1100

Joel wrote to me off-list that the ILNP proposal involves special
arrangements for a DNS server to respond to a requester which is
using ILNP.  These arrangements apparently involve the DNS server not
needing to do an DNS lookup before sending the reply packet.  He
didn't point to the relevant text.

This may be the case, but I was unable to find it in the four IDs and
I had a quick look at all the material linked to from:

  http://ilnp.cs.st-andrews.ac.uk/

and didn't see anything along these lines.

We can't be expected to know what a proposal involves other than by
reading the IDs and other documents.

That said, if anyone is about to read the 2.5 year old ivip-arch ID,
please hold off for a few days - I am writing a shorter, completely
revised version.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Wed, 06 Jan 2010 22:56:34 -0800

> as today's DNS exchanges.

Robin,

Your confusion here is your assumption that the host MUST do an ILNP 
lookup.  In fact, that is not required and that is the basis for 
interoperability with legacy hosts.  Thus, the DNS server need not 
perform an ILNP lookup before replying.  In fact, since it is very 
likely to be a one packet transaction, performing the lookup is simply 
unnecessary and pessimal.

Regards,
Tony

---

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

> reading the IDs and other documents.

We can be expected to use a bit of common sense tho...

Tony

---

From: $witch <[email-masked]>
Date: Thu, 07 Jan 2010 15:24:36 +0100

Hi, all

the useful proposal-report at  
http://www.ietf.org/mail-archive/web/rrg/current/msg05562.html

is a good start point to direct an (almost at all) ignorant into a  
summarization.

follow your discussion lead me to a simple observation :

it seem that there is a contradiction as expressed by

   (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all  
three).

...........

    (10) One size never fits all.

 from RFC 1925 (ok, it's a 1st april, but there is truth, inside)

or, in other therms

it is obvious that a "major" change will have a "major" impact and  
corresponding (whatever expressed) cost.

must a reader mainly care about "backward compatibility", "performances",  
"cost", "style" or what ?

and little bit different question from "constrain list for voluntary  
adoption" :

what are, if any, the underling directive from RRG about "Good, Fast,  
Cheap" balance ?

is it RRG (on behalf of internet community) major interest to have "fast"  
or "cheap" or "good"  
transition|implementation|maintenance|performance|compatibility ?

you know, RRG messages are plenty of linked details and is it not easy to  
follow all your mind and specific knowledge, don't blame me if off-topic,  
am the "dumb one" of the list......  :D

cheers

Alessandro