[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: Does every host need a FQDN name in the future?//re:[RRG] draft-rja-ilnp-intro-01.txt
- To: email@example.com
- Subject: [RRG] Re: Does every host need a FQDN name in the future?//re:[RRG] draft-rja-ilnp-intro-01.txt
- From: Steven Blake <firstname.lastname@example.org>
- Date: Wed, 06 Aug 2008 10:00:51 -0400
- User-agent: RoundCube Webmail/0.1
On Wed, 6 Aug 2008 11:20:26 +0200 Iljitsch van Beijnum <email@example.com>
> On 6 aug 2008, at 8:11, Tony Li wrote:
> > It's not clear to me that you ever have to do a pure identifier to
locator lookup. This is especially true since locators are only locally
> Locators are only locally unique? Isn't the whole point of a locator to
get you where you want to be, not to a location which may or may not be the
> one you wanted to be but with the same name as the one where you want to
I'm not sure what Tony has in mind with "locally unique" locators. Maybe
he is thinking of the case where a site uses localized addressing (e.g.,
and re-writes source locators on the site border router?
> In my opinion, non-unique identifiers are not really any better than a
locator/identifier overload like we have today. Maybe it can be made to
> but you're forever stuck with accommodating this limitation.
There's no way to enforce global uniqueness of the I bits, even if you
wanted to. The best you can do is not provide any incentives to hijack
> Case in point: shim6. It doesn't support setting up sessions if you don't
have a working locator because it can't do an identifier-to-locator lookup.
> > Thus, you always need to have a locator identifier pair before
starting a lookup, presumably to determine alternate locators. Once you
have the first
> > pair, you could do a reverse lookup to determine a name (and any name
will do) and then do a forward lookup to determine the locator set.
> In other words: the FQDN is the real identifier and the value in the
bottom 64 bits of the address field is meaningless.
The FQDN is the rendezvous identifier, the I field is the invariant
identifier for a host between a set of (possibly dynamic) locators. You
possibly engineer things so that the I field did not have to be constant
across a set of locators a host is reachable by, but that would be really
> Note that reliably providing reverse lookup DNS service with IPv6 isn't
to unsubscribe send a message to firstname.lastname@example.org 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