Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments]

["Jim Fleming" <jfleming@anet.com>]

Do you use a 2002 prefix ?

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info


----- Original Message -----
From: "Alex Zinin" <azinin@nexsi.com>
To: "David Conrad" <david.conrad@nominum.com>
Cc: "Michel Py" <michel@arneill-py.sacramento.ca.us>; "J. Noel Chiappa"
<jnc@ginger.lcs.mit.edu>; "multi6" <multi6@ops.ietf.org>
Sent: Thursday, January 03, 2002 12:32 AM
Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft
comments]


>
> David,
>
> >> If you make EID (your PI address) "addressable" and expect it to be
> >> usable by the endpoint to tell its routing names, then EID needs to
> >> be routable
>
> > Not necessarily.  If you have some mechanism that maps between the EID
and
> > the locator, you can route on the locator independently of the
routability
> > of the EID.  Numerous mechanisms can be imagined which could provide
such a
> > mapping service (DNS among them).
>
> Generally yes. In fact, I would even say the routing system should
> know nothing about EIDs. This is not they case with Michel's proposal,
> though.
>
> >> Regarding the question of whether EID->routing name mapping should
> >> be done through DNS together with DN->EID mapping or through a
> >> separate packet exchange. I think it is important to keep in mind
> >> node mobility, where the node's routing name changes dynamically.
> >> The relatively static nature of [at least] today DNS does not
> >> converge well with possible dynamics of the routing name.
>
> > My feeling is that any mobility solution that relies on the variability
of
> > an EID is doomed given current name to address translation technology.
Not
> > only do you have to worry about stuff like DNS TTLs, but you must deal
with
> > the fact that applications themselves cache addresses (that is,
application
> > data structures know what an address is).
>
> Agree. That's why I think DNS should provide DN->EID mapping where
> EID should stay static regardless of the nodes's location/connectivity,
> and this is the EID->locator (routing name) mapping that should account
> for dynamic changes in it.
>
> > If, however, the EID is separated from the locator, you can vary the
locator
> > according to topology changes (be they provider driven or the fact
you've
> > roamed between one cell tower to another) without changing the bucket o'
> > bits applications have memcpy'd from the struct hostent returned by
> > gethostbyname().
>
> Agreed.
>
> > In this model, DNS TTLs become relevant (assuming the
> > locators are looked up via DNS), but that is relatively easy to deal
with.
>
> Frankly, I'm having trouble imagining a DNS-based system used to
> provide the EID->location mapping dynamic enough and scalable at
> the same time to work for mobile nodes. That's another story though...
>
> Alex.
>
>
>