[RRG] ILNP critique

[Robin Whittle <rw@firstpr.com.au>]

Hi Ran,

In "Re: Practical Proposals vs. endless theoretical discussions" you
wrote:

>   From the quoted text above, and other even less correct
> text later in your recent note, I can only believe that you
> haven't bothered to read the I-Ds about ILNP and haven't
> reviewed the presentation made (by my colleague) at Routing RG
> in Dublin.

I listened to Steve Blake's presentation and had enough of a look at
your I-D:

  http://tools.ietf.org/html/draft-rja-ilnp-intro-01

to determine that your proposal involves radical changes to IPv6.
These include changes in the API between applications and the host
stack.  So I understand that your proposal involves revising the
IPv6 protocol, host stacks, host APIs and applications.

That is why I think it is impractical.

IPv6 has been open for business for years and very few people use
it.  The IPv6 Internet is unfortunately a separate Internet from the
IPv4 Internet.  The most important thing about an Internet is that
it can be used to directly communicate with all Internet-connected
computers.  IPv6 doesn't do this.  It could, but until almost every
host has native IPv6 connectivity, it won't be of much practical
value compared to IPv4, since all users (apart from maybe some on
cellphones, or in China) will be connected to the IPv4 Internet.


You propose to solve the routing scaling problem not just be having
everyone change their ISP services, their routing systems, addresses
and host stacks and their applications to use IPv6 instead of IPv4,
but to have them further change their host stacks and applications
to something different from IPv6!

My notes from the presentation include:

  "Domain name becomes the central identifier for IP and
   network layers.

  "Mobile node must change its DNS as it moves!

  "DNS is like the home agent! or DNS points to the
   rendezvous server".

I recall a lot of discussion about the problem of ensuring 64 bit
identifiers are unique in the world.  Your proposal (page 4) does
not ensure an identifier is unique, except in the scope of a 64 bit
identifier.

This makes me think your proposal, or at least the current
nomenclature, is nonsensical.  How can it be an identifier in a
global network if it is not guaranteed to be unique?

Your introduction claims that "Map and encapsulate" is a separate
class of solution from "Identifier/Locator Split" - but this strikes
me as wrong, since for instance LISP is both.

Your proposal involves:

   . . . crisp and clear semantics for the Identifier and for
   the Locator, removing the semantically-muddled concept of the
   IP address . . .

yet removes arguably the most important thing in the Internet, the
concept of being able to uniquely identify a host, or a host's
interface.  (Yes I know NAT clobbers this . . .)

Page 6: you need to change the pseudoheader checksum algorithm - so
you need to change host stacks at both ends of any communication
involving ILNP.  I think this means that you can't support
multihoming or whatever benefits for communications with
non-upgraded hosts.  So there are almost no benefits for early
adoptors - and I predict the system would never be widely adopted.

Pages 6 and 7: ILNP does not appear to support site multihoming.
But site multihoming is the only way of doing it robustly and
efficiently.  End-user networks need a single point of control in
order that their potentially thousands of nodes keep working without
a glitch.  SHIM6 supports site multihoming - but no-one wants to
multihome this way.

Page 7:  There is an ICMP message to tell correspondents that the
current node is moving to another locator.  This needs to be
secured, so you use a nonce:

  http://tools.ietf.org/html/draft-rja-ilnp-nonce-00

in the ICMP message.  There is a reference to an I-D
"draft-rja-ilnp-icmp-00" but no such I-D exists.

How do you plan to ensure the ICMP packet gets to its destination?
You would need a secured acknowledgement packet - so it seems a bit
odd using ICMP for something like this.

The node needs to have the nonce sent by the correspondent, and the
above-mentioned I-D proposes sending a 32 bit or 96 bit nonce within
an IPv6 destination option header.  So you are adding an 8 or 16
byte destination option header to every initial packet which uses
ILNP.  If the destination host is not upgraded, it should send back
an ICMP Parameter Problem message.

So it seems that every ILNP host is required to at first send an
ILNP format packet to whichever host it is sending a packet to - at
least if it got the IP address as a referral, rather than from DNS.
 (Is it OK to have a destination option header in an ICMP packet,
such as a ping packet?)

Then if the destination is not upgraded, wait for its single ICMP
packet (which could easily be dropped) before sending the packet
again in normal IPv6 mode.  This seems to imply significant delay to
the establishment of communications with all non-upgraded hosts
uncles the application gets the address via DNS, or already knows
for some reason the destination host is or is not an ILNP host.


On page 7 you mention site multihoming, but I have no clear idea
what this would involve.  How does the site administrator tell all
the hosts in their network that they are on a different locator?
Likewise the routers in those dependent sub-networks?  How could
they reliably know what hosts and routers there are?

You mention a DNS record optimisation which will presumably somehow
make it easier for a network administrator to cause your new DNS L
records for potentially thousands of hosts to be changed without
having to send individual update commands to the DNS servers.

This takes me to:

  http://tools.ietf.org/html/draft-rja-ilnp-dns-00

Page 3 para 2 you refer to both two and four new DNS resource records.

There is no reference in this I-D to any optimisation or to
multihoming.  This is the second important reference which leads
nowhere.

You propose new DNS records for Locator and Identifier.  So DNS
servers need to be upgraded, and likewise DNS code in host stacks.

On page 10 you state that the existing BSD Sockets API can still be
used to support IP address referrals, but I don't understand this at
all, if the most significant 64 bits of the IP address could be
changed when a multihoming service interruption forces the adoption
of a new locator.


There's no mention of scalability.

I guess scalability would be achieved by allowing only ISPs to
advertise prefixes in the DFZ.  Each ISP might have dozens to
millions of end-user networks connected via the one prefix.
End-user networks then do not have any fixed addresses, other than
the collection of 64 bit identifier addresses of all their nodes.

Your draft provides no guidance on how hosts are supposed to choose
their 64 bit identifiers.  In the absence of anything to the
contrary, the set of identifiers in end-user network X may be a
random set from the 64 bit space.  Likewise, the identifiers of
end-user network Y could be a random set from the same space.

Consider ISP-A, currently connecting a million networks like X and Y
each with on average 100 nodes.

I suppose you would have the ISP hand out 64 bit identifiers to each
of its end-user networks.  Say ISP-A had a /32, this gives it 4
billion /64 prefixes to hand out to end-user networks.  Then its
routing system can look for each /64 in the destination address of
packets arriving from other ISPs and forward the packets to the
end-user network which has been assigned that /64.  There's nothing
wrong with this - I am just suggesting it is the sort of thing which
would be good to explain so people don't have to guess how your
proposal would work.  Maybe my guess is right or wrong - I can't
tell from your I-Ds.


I didn't read your I-Ds in detail until now because I tentatively
decided that your proposal was half-baked.  It only works with IPv6,
and then only by radically changing host stacks and applications -
and as currently specified, it removes the concept of a globally
unique identifier.  It has no links from the RRG wiki and has no
summary and analysis document.

I think the routing scaling problem is not so bad that it must be
solved by changing hosts, especially host applications.  Admittedly,
there are few IPv6 hosts, so host changes for IPv6 are not as
unthinkable as for IPv4.

> Similarly, I can only believe you haven't bothered
> to do a literature search and read the sundry published
> research papers on the topic.  All of these are disappointing
> in the context of an IRTF Research Group.

I shouldn't have to do a literature search or muck around trying to
find cited I-Ds which don't exist.


>   As near as I can tell, every statement you have made about
> ILNP is wrong.

Please correct them in detail, a blanket statement like this doesn't
help me or anyone else.  Please also correct any mistakes I made in
this message.

How many people do in fact understand ILNP?  If it is a small
number, don't be too hard on me for not understanding what is in
your mind.  I think your I-Ds are brief and lacking in detail.

I will respond to the rest of your message in the original thread.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg