[RRG] draft-rja-ilnp-intro-01.txt

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 01 August 2008 08:29 UTC

Envelope-to: rrg-data@psg.com
Delivery-date: Fri, 01 Aug 2008 08:30:25 +0000
Message-Id: <A21C9B11-86C2-47C4-9623-7829ADBA1287@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: rrg Group <rrg@psg.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: [RRG] draft-rja-ilnp-intro-01.txt
Date: Fri, 01 Aug 2008 09:29:25 +0100

Reading the ILNP intro draft, I was already trying to remember the  
locations/identities [*] of the most damning evaluations of GSE/8+8  
when this caught my eye:

    Identifiers are unique within the context of a given
    Locator; in many cases, Identifiers might happen to be
    globally unique, but that is not a functional requirement
    for this proposal.

This means that it won't be possible to learn the locators for a given  
identifier through a lookup mechanism. So ILNP has many of the same  
limitations of shim6: at least one working (!) locator must be present  
in the DNS (or other address discovery mechanism).

Because of this and the use of dynamic DNS, basically, the FQDN is the  
real identifier while the "I" is only a fixed-size handle that  
conveniently fits in existing fields.

It also shares with shim6 the limitation that locators are exposed all  
the way to the hosts, so it's highly likely that someone will filter  
on them so it doesn't solve or avoid the renumbering problem.

    When one upstream connection
    fails, the node sends an ICMP Locator Update message to each
    existing correspondent node to remove the no-longer-valid
    Locator from the set of valid Locators.

This mechanism doesn't address the situation where there is a failure,  
but the failure isn't directly visible to the host (or router)  
connecting to the link in question. Because of switches, failures on  
the actual link are often hidden. There can also be a problem reaching  
part of the internet through a link, so the fact that one destination  
is reachable doesn't mean that another destination is reachable. So  
the only way to know for sure if a destination is reachable is to have  
specific information in the routing system, or send packets and see if  
something comes back.

Obviously sending ICMP messages over the failed link doesn't work, and  
using another link creates security issues.

Although it doesn't look that way on the surface, this is fairly  
similar to shim6 in what it does, except that shim6 is much more  
complete and backward compatible.

[*] http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd-analysis-05.txt

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