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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On donderdag, mei 22, 2003, at 16:12 Europe/Amsterdam, Shane Kerr wrote:

> > http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt
> I had a read of your draft, and it's very nice.
Thanks!

> I have some specific comments:
> Why specify "no more than 1 per minute" for ICMP packets?  This seems
> kind of arbritrary.
The value is arbitrary, of course. What I want to do is make sure 
implementers don't just keep pinging to see if the other side is up. 
That would make for way too much control traffic and there are much 
smarter ways to do this.

> Note that if you *required* some sort of KEEPALIVE on all locators
> then it could help with poor middleboxes.  :)
Too bad for the poor middleboxes, let them earn their keep.  (-:

> What does "in the absense of better knowledge" mean?
If the client knows one locator address is reachable and the other 
isn't, it should use the reachable address of course. But if it doesn't 
know, then it may as well use the last address used by the 
correspondent. This way the correspondent gets to prefer one of the 
incoming paths rather than have to depend on coin tosses elsewhere.

> Again, if you required some sort of KEEPALIVE, then you could build an 
> RTT-style
> mechanism into the protocol.
I hate keepalives. See my exchanges with the SCTP people last year.

This mechanism works at the IP layer, but I assume that if and when 
it's implemented, it will be integrated with TCP processing. Then it 
makes sense to keep RTT timing results for each virtual path. This 
could help the TCPs with choosing the best path, or even load balance 
the session over more than one path.

But even without this it should be possible to get around periodic 
keepalives by simply monitoring what's going out and what's coming in. 
When a non-ACK packet has been sent out but nothing has come back for X 
seconds, then it makes sense to send a keepalive. But not when packets 
are flowing anyway.

> I suggest that you recommend people *not* use the identifier address
> as the regular address.  It seems like a great potential source of
> confusion.
I think you're right. I had the idea that it might be possible to 
simply send packets and only bother with the multihoming thing when the 
session turns out to be long-lived, but that didn't make it in this 
draft so there is no advantage in making identifiers and the associated 
locators overlap.

> 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.
True, but then non-multihomed clients also can't use autoconfiguration. 
Just setting the top byte to 0 or something like that doesn't entirely 
break autoconfiguration.

> "Note that multihomed communication without involvement from the DNS
> isnt' psossible." overstates the case, and not really pertinent.  I
> suggest removing it.
The client needs the DNS to find locators for the server. So without 
the ability to query the DNS, multihomed communication isn't possible. 
We may be able to repair this by using something like 
"identifier+loc1+loc2+loc3" as the hostname, though.

> 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....
Shouldn't be worse than regular spoofing. However, it does give clients 
a way to get around anti-spoofing filters to some degree so I guess 
this should go in the security considerations.

Iljitsch