[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: new draft



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:iljitsch@muada.com] 
> Sent: Sunday, May 11, 2003 9:31 AM
> To: multi6@ops.ietf.org
> 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