[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
- [RRG] draft-rja-ilnp-intro-01.txt Iljitsch van Beijnum
- RE: [RRG] draft-rja-ilnp-intro-01.txt Tony Li
- Re: [RRG] draft-rja-ilnp-intro-01.txt Scott Brim
- Re: [RRG] draft-rja-ilnp-intro-01.txt Iljitsch van Beijnum
- Re: [RRG] draft-rja-ilnp-intro-01.txt Brian Dickson
- RE: [RRG] draft-rja-ilnp-intro-01.txt Tony Li
- Re: [RRG] draft-rja-ilnp-intro-01.txt Brian E Carpenter
- RE: [RRG] draft-rja-ilnp-intro-01.txt Tony Li
- Re: [RRG] draft-rja-ilnp-intro-01.txt Brian E Carpenter
- RE: [RRG] draft-rja-ilnp-intro-01.txt Noel Chiappa
- RE: [RRG] draft-rja-ilnp-intro-01.txt Noel Chiappa
- RE: [RRG] draft-rja-ilnp-intro-01.txt Tony Li
- RE: [RRG] draft-rja-ilnp-intro-01.txt Tony Li
- Re: [RRG] draft-rja-ilnp-intro-01.txt Brian E Carpenter
- RE: [RRG] draft-rja-ilnp-intro-01.txt Templin, Fred L
- Re: [RRG] draft-rja-ilnp-intro-01.txt Christian Vogt