Subject: RE: new draft

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 May 2003 13:02:08 -0400

Iljitsch,

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 will do deep dive technical review what it means to the server and
client code base but I would like to hear a few folks here agree with me
the idea is sound and folks will support the architectural principles
???????????????????  I will view it from my day jobs various stacks,
BSD, and Linux as a note.

It is critical the identification of a mobile client is very very fast
serves can take millions of hits in just one hour at the high end it
needs to be quick.

This architecturally does not break IPv6.

We will need to define a new address type for IPv6 and I think you avoid
much of the formality of that approach with your method.

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.

Nice job,
/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Sunday, May 11, 2003 9:31 AM
> To: [email-masked]
> Subject: new draft
> 
> 
> After friday's discussion I wanted to see what could be accomplished 
> without any kind of negotiation. What I came up with:
> 
http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt

- no middleboxes
- no state in routers
- bare-bones multihoming for servers is possible without any state
   in the server (the client must keep state though)
- we have to break autoconfiguration
- we need the DNS, no multihoming for severs with just IP addresses
- optional source address rewriting

Note that this is a finished draft and it's not related to the other 
one I've been working on.

Adding some negotiation to the client part should make this much more 
reasonable but the server part seems reasonably solid.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 May 2003 22:18:51 +0200

> 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.

> discussion if we believe this architecture is worth discussion.  I

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