Subject: roadmap

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Feb 2003 06:56:50 +0100

I  finally submitted a roadmap document as discussed in Atlanta. It's 
called draft-kurtis-multi6-roadmap-00.txt. While waiting for 
publication it can be found at 
http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt.

I wrote most of it last night so it is lacking references and most 
likely spelling..:)

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Feb 2003 08:52:05 +0200 (EET)

> http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt.

Doesn't exist for v4, and on v6:

sampo2 ~> dig any www.kurtis.pp.se
[...]
;; ANSWER SECTION:
www.kurtis.pp.se.	86357	IN	AAAA	2001:670:87:3001::6
www.kurtis.pp.se.	86357	IN	A	195.43.225.69

$ traceroute6 2001:670:87:3001::6
traceroute to 2001:670:87:3001::6 (2001:670:87:3001::6) from 
2001:670:86:3001::1, 30 hops max, 16 byte packets
 1  netcore-gw.ipv6.netcore.fi (2001:670:86:3001::)  13.285 ms  11.78 ms  9.86 ms
 2  * * *
 3  * *

sampo2 ~> traceroute6 2001:670:87:3001::6
traceroute to 2001:670:87:3001::6 (2001:670:87:3001::6) from 
2001:708:10:10::1:157, 30 hops max, 16 byte packets
 1  ws-6gw.ipv6.csc.fi (2001:708:10:10::1)  0.331 ms  0.236 ms  0.205 ms
 2  cscv6-t30-csc-ws.ipv6.funet.fi (2001:708:0:f010::1)  2.234 ms  1.973 ms  2.079 ms
 3  6net-p31-cscv6.ipv6.funet.fi (2001:708:0:f000::102:1)  2.067 ms  1.863 ms  1.918 ms
 4  v6-a202-cscv6.ipv6.funet.fi (2001:708:0:f000::101:1)  2.253 ms  2.114 ms  2.078 ms
 5  r3-AT1-0-4-KQ1.Hel.FI.KPNQwest.net (2001:670:40::1)  4.018 ms  4.8 ms  5 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * *

 $ traceroute6 2001:670:87:3001::6
traceroute6 to 2001:670:87:3001::6 (2001:670:87:3001::6) from 2002:d436:1c91::1, 30 hops max, 12 byte packets
 1  2002:3eec:20cb::1  41.465 ms  24.951 ms  24.494 ms
 2  * * *
 3  * * *
 4  * * *

.. luckily enough, site multihomin in v6 is not the one of our biggest 
problems at the moment... :-/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Feb 2003 08:03:07 +0100

This should be with a -00 at the end...

- kurtis -

On måndag, feb 24, 2003, at 06:56 Europe/Stockholm, Kurt Erik Lindqvist

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Feb 2003 08:04:52 +0100

> Doesn't exist for v4, and on v6:

It does for v4, but with the -00 at the end...
> problems at the moment... :-/

:)

I need to talk to my upstream...:(

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Feb 2003 09:24:04 +0100 (CET)

> I wrote most of it last night so it is lacking references and most

And how about this:

  "The current amount of AS numbers available are limited by the 32-bit
   field of AS-number in the BGP specification.  However, there is a
   proposal in the IDR working group of the IETF to increase this field
   to 64-bits.  This would increase the amount of ASes available, and
   therefor the potential amount of routes in the global routing table."

I don't think recognizing the 16 bit AS number space as a limit on
multihoming is a good thing to do. There are many ways to do it without
an AS number.

  "One way of achieving multihoming that exists already today is to use
   multiple addresses on the end hosts."

This doesn't work so it shouldn't be presented in this way. Also, for
future multihoming solutions it is important to know how having multiple
addresses is handled; there are many different ways.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Feb 2003 09:30:04 +0100

> multihoming is a good thing to do. There are many ways to do it without

There is. But it will still limited the growth somewhat.

> addresses is handled; there are many different ways.

Send text! :)

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Feb 2003 11:59:06 +0100 (CET)

> > future multihoming solutions it is important to know how having
> > multiple addresses is handled; there are many different ways.

> Send text! :)

Don't think I won't! I have to do some programming work so I was looking
for a way to procrastinate anyway...

Here is some text. The trouble is that it doesn't fit into your
classification, and I see no way to make this happen.

A way to make multihoming very scalable without taxing the routing
system is to use address space from each ISP the multihomed network is
connected to, rather than (semi-)independent address space. This allows
for full scale provider-based aggregation and full scale multihoming
benefits at the same time. There are basically four ways to accomplish
this:

1. Multi-address aware applications. These exist today. The DNS and
email both take several destination addresses for many operations and
cycle through them one by one until a working address is found. This is
traditionally used to fall back from one host to another, but this
mechanism is also usable for falling back from one address to another
address tied to the same host. However, this mechanism doesn't provide
any way to switch from one address to another during a session. This
makes it unusable for applications with long-lived sessions. But for
applications that typically use short transactions which can simply be
repeated after failure, this mechanism can work very well. One
application that uses short transactions most of the time is the world
wide web.

2. Multi-address aware transport protocols. At this time, there is SCTP.
There are several proof-of-concept modifications to TCP to accomplish
the same thing. This could probably be more interoperable than switching
to a new transport protocol.

3. Failure repair with tunnels or extension headers. It has been
observed that Mobile IP offers functionality that can be used here,
although there are also elements missing that would be required for a
usable multihoming solution based on MIP.

4. Two-space systems, where there are addresses (or names that don't
look like addresses) used for the identifaction of the endpoints taking
part in the communication and different addresses used to route packets.
Solutions that separate the identifier and locator functions marry
portable address space to full aggregation within the routing system.
There must always be a locator as the destination address (for
forwarding) and a locator as the source address (so ICMP messages can be
sent back) in each packet. The identifiers may be carried explicitly or
they may be implied and be found by looking up the locators and possibly
session-identifying information in a mapping table. However, as explicit
identifiers aren't protected by even the low level of security provided
by return routability, it is impossible to use them they way they are
found in a packet. Rather than trying to authenticate the identifier in
the packet and incur even more per-packet overhead, it seems logical to
use implicit identifiers.

Mechanisms 1 and 2 (mostly) can simply use the DNS to find additional
addresses. Mechanism 4 and maybe 3 as well need a more extensive mapping
or negotiation mechanism to discover all the information needed to
operate. Another difference between 1 and 2 on the one hand and 3 and 4
on the other hand is that it may be possible to implement 3 and/or 4 on
a proxy multihoming processing box. This could have important deployment
advantages.

Iljitsch

---

From: Shane Kerr <[email-masked]>
Date: Mon, 24 Feb 2003 17:34:55 +0100

First, let me say that this draft is the best thing ever written.  I'm
trying to decide whether to throw out the Bible or Code Complete to
make room for it on my shelf.  ;)

On 2003-02-24 09:24:04 +0100, Iljitsch van Beijnum wrote:
> 
>   "One way of achieving multihoming that exists already today is to
>   use multiple addresses on the end hosts."
> 
> This doesn't work so it shouldn't be presented in this way. 

It doesn't work, except for where it does, like DNS and SMTP.

> Also, for future multihoming solutions it is important to know how
> having multiple addresses is handled; there are many different ways.

I thought the draft was appropriately free of details.  How do you
mean exactly?

-- 
Shane Kerr
RIPE NCC

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Feb 2003 19:03:24 +0100 (CET)

> It doesn't work, except for where it does, like DNS and SMTP.

It only works to a usable degree when you do source-address dependent
routing.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Feb 2003 14:53:19 +0100

> Don't think I won't! I have to do some programming work so I was 

good!

> classification, and I see no way to make this happen.

Why don't you think this would fit as text under the Addressing 
solutions paragraph?

Best regards,

- kurtis