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