RE: new draft

["Bound, Jim" <Jim.Bound@hp.com>]

On the DNS.  I support doing this with DNS.  I just want to be sure that
the DNS community has no pain with it.  I don't think they will as it is
just another record type which is far less than A6 was.
/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
> Sent: Sunday, May 11, 2003 4:19 PM
> To: Bound, Jim
> Cc: multi6@ops.ietf.org
> Subject: Re: new draft
> 
> 
> On zondag, mei 11, 2003, at 19:02 Europe/Amsterdam, Bound, Jim wrote:
> 
> > On first read architecturally I believe where you going will work.
> > Note
> > A6 records are dead and deprecated in IETF and the BIND DNS 
> code base
> > will get rid of them in the near future and remove them from 
> > exisitence.
> > Very painful to us who use BIND regarding the cost fyi.  So 
> that means
> > lets be very very careful with adding new DNS A* records 
> here folks the
> > BIND community will be very gun-shy of putting new record 
> types in for
> > IPv6 records regarding implementation.
> 
> I understand. But I see no reasonable alternative. Creating something 
> that does exactly this job but isn't DNS would be inefficient, to say 
> the least. If there is another way to infer the locators from an 
> identifier that doesn't involve a huge distributed database, I'd like 
> to hear about it as it would solve some additional stuff.
> 
> > You also traded off complexity in the host instead of using 
> some IPv6 
> > extensions to assist with the effort architecturally.  I am 
> still not 
> > convinced that trade off is completely necessary and some 
> of this can 
> > be reduced with DST Options and a New Extension Header to support
> > identification and processing for mutli6.  But that is an 
> engineering
> > discussion if we believe this architecture is worth discussion.  I
> > believe it is.
> 
> If we go down the option path we quickly end up in mobility teritory. 
> This may or may not be a bad thing.
> 
> Since options are easily forged, they must be protected 
> cryptographically. Maybe we should see if there is any synergy to be 
> found by combining all of this with IPsec.
> 
> > Nice job,
> 
> Thanks.
> 
> Iljitsch
> 
>