> 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.
I also believe so. then my question is Does every host need a FQDN name in the future? Xiaohu XU > > 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 [EMAIL PROTECTED] 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 > -- to unsubscribe send a message to [EMAIL PROTECTED] 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
