Subject: new draft

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 May 2003 15:30:42 +0200

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: "Michael H. Lambert" <[email-masked]>
Date: Sun, 11 May 2003 12:30:05 -0400

Iljitsch,

A couple of comments on your draft:

1)  If I'm drawing the correct inference, it would appear that the number 
of locator addresses used by a client goes as n!, where n is the number of 
ISP prefixes.  I can easily see sites with n=5.

2)  In the case of a host with multiple interfaces, is each interface 
treated separately (both in the DNS and wrt locator addresses)?

Michael

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 May 2003 21:59:23 +0200

On zondag, mei 11, 2003, at 18:30 Europe/Amsterdam, Michael H. Lambert 

> 1)  If I'm drawing the correct inference, it would appear that the 
> number of locator addresses used by a client goes as n!, where n is 
> the number of ISP prefixes.  I can easily see sites with n=5.

A multihomed server would use n locator addresses for a single 
identifier.

A multihomed client could decide to create double prefix addresses for 
each combination of prefixes, which would make for n(n-1) addresses, or 
even double this by also creating two versions of each combination, 
with different prefixes being the identifier for each of those two 
versions. I'm not sure if I'd recommend this, though...

> treated separately (both in the DNS and wrt locator addresses)?

I don't think it matters whether n addresses are from n interfaces with 
one address each or 1 interface with n addresses. So it seems this 
solves host multihoming as well.

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 May 2003 15:57:43 +0200

Reading this draft and draft-de-launois-multi6-naros-00.txt
together, I feel that they have a lot in common - except that NAROS
uses an ad hoc protocol instead of DNS, and is explicitly linked
to TE. But they both seem to me to be the nucleus of a depolyable
solution that doesn't break much at all. Can we ignore for a moment
the DNS-vs-ad hoc question and look at the pros and cons of this
family of solutions?

   Brian

---

From: Shane Kerr <[email-masked]>
Date: Thu, 22 May 2003 16:12:38 +0200

Iljitsch,

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 May 2003 18:38:05 +0200

> 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

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.

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

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.

> as the regular address.  It seems like a great potential source of

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.

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

> isnt' psossible." overstates the case, and not really pertinent.  I

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.

> from a 3rd party in the multihomed client address.  Haven't thought

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