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