Re: Two Prefixes in One Address (was: new draft)

[Shane Kerr <shane@ripe.net>]

Iljitsch,

On 2003-05-11 15:30:42 +0200, Iljitsch van Beijnum wrote:
> 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

I had a read of your draft, and it's very nice.  I have some specific
comments:

pg 3.

Why specify "no more than 1 per minute" for ICMP packets?  This seems
kind of arbritrary.

Note that if you *required* some sort of KEEPALIVE on all locators
then it could help with poor middleboxes.  :)

What does "in the absense of better knowledge" mean?  Again, if you
required some sort of KEEPALIVE, then you could build an RTT-style
mechanism into the protocol.

pg 4.

I suggest that you recommend people *not* use the identifier address
as the regular address.  It seems like a great potential source of
confusion.

pg 6. 

It might be better for a multihomed-aware but single-homed client to
use the same information for locator 1 and locator 2?  As in, "prefix
from ISP A" and "prefix from ISP B" are the same.  No special handling
would be needed on the multihomed server side then - it can merely use
the same algorithm for all clients.

pg 7. 

"Note that multihomed communication without involvement from the DNS
isnt' psossible." overstates the case, and not really pertinent.  I
suggest removing it.

pg 11.

I think there may be some security issue, in that a client can
generate packets to another client by sending a packet with the prefix
from a 3rd party in the multihomed client address.  Haven't thought
too much about this....


General comments:

This seems simple, and requires no new infrastructure.  I like the
NAROS technique also because it abstracts a lot of decision making
(too much really from the current draft, IMHO).  I'd be interested in
seeing the two work together in some way, esp. regarding server-side
traffic preferencing.

-- 
Shane Kerr
RIPE NCC