Subject: RE: Mutli6 meeting in Vienna

From: "Christian Huitema" <[email-masked]>
Date: Thu, 15 May 2003 08:05:51 -0700

> >>> - can we break applications?
> >>
> >> if break=modify, we might be forced to.
> >>
> >>> - can we break transport protocols?
> >>
> >> see previous.
> >>
> >>> - can we break autoconfiguration?
> >>
> >> yes.
> >>
> >>> - can we break IP?
> >>
> >> yes
> >>
> >>> - can we break IPsec?
> >>
> >> isn't that transport?

I think we have to qualify "break". I would personally say "augment"
rather than "break". The basic idea should be:

1) An unmodified implementation continues working, and receives at least
the same quality of service as if the local site was not multi-homed, or
the correspondent node was not multi-homed.

2) An augmented implementation gains benefits such as survival of
sessions, or migration of associations from a low quality path to a
higher quality path.

In practice, that means that we cannot "break" transports, IP or IPSEC.
However, we should be able to augment each of them. For example, if a
transport or IPSEC gain some notion of IP-address-independent session,
then it should be possible to use several "locator pairs" between two
entities. If two hosts have been augmented to support multi-homing
adaptations, then they should be able to cooperate. If
auto-configuration is augmented to provide support for multi-homing,
then augmented implementations should take advantage of it.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 May 2003 23:04:03 +0200

On donderdag, mei 15, 2003, at 17:05 Europe/Amsterdam, Christian 
Huitema wrote:

> rather than "break".

Yes, I was very imprecise here. There are several things that can 
happen, including the requirement to change something. I think it would 
be a mistake to require both hosts and routers to change, as it pretty 
much doubles the required deployment efforts needed to get this off the 
ground. Requiring applications to change is absolutely a nonstarter as 
we'll have single homed applications for decades that way.

> The basic idea should be:

> the correspondent node was not multi-homed.

Supporting single homed correspondents is essential but I don't care 
much for single homed hosts in a multihomed site. Upgrade already. It's 
not like there is a huge installed base of stuff that isn't supported 
any more in IPv6.

> However, we should be able to augment each of them.

It would be better if we didn't have to...

> If auto-configuration is augmented to provide support for multi-homing,

It might be challenging to change autoconfiguration so it can assign an 
identifier as well as a number of locators.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 13:10:04 +0200

Iljitsch van Beijnum wrote:
...
> not like there is a huge installed base of stuff that isn't supported

Well, pretty much every operating system image shipped today includes
RFC 2460 support. So I suspect the installed (but not enabled) base
is in fact huge. At least in a large corporate network, routers and
hosts are *not* upgraded in a coordinated way. So 'upgrade already'
won't fly. We need incremental deployment; that has always been the
guiding principle for IPv6 coexistence.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 May 2003 16:24:06 +0100

> guiding principle for IPv6 coexistence.

Agreed.

My view is that there should be three thrusts to multi6 at present, 
which may be a bit more contentious.

1.  We pursue Christian's suggestion for bite by bite implementation of
    multi-addressing in SOHO-class and small networks with one or two
    routers connecting to two ISPs.   That means ingress filtering
    avoidance, etc, adding new tricks where needed (e.g. new ICMP message)
    and resuing existing tools from our toolbox where possible.  These
    may become usable within 1-2 years.

2.  We allocate suitably large enterprises /32 prefixes (as per Craig's
    suggestion), for some definition of "suitably large", out of some
    new /16 prefix.  There would only be a few thousand of these for the
    next 2-3 years, most likely.

3.  We pursue the longer-term goal of identifier-locator separation for
    multihoming (and other benefits).  This probably wouldn't lead to
    deployment for at least 2-3 years, maybe more.

With #1 we can multihome for the majority of multihomers - the home
networks, SME's and networks where multi-address methods can work and
do not (usually) need policy management (of the type Craig mentions).

With #2 we create a small swamp, but one we can fence off.  It helps remove
the perceived barrier for deployment in large enterprises or corporations.

With #3 we plan for the future, with incremental deployment of two-space
solutions being the goal.  It might include HIP as a motivator, or maybe
something like Iljitsch's recent proposal.  

I suspect #1 and #3 would not be too contentous, #2 might be :)
I'd like to see some discussion of #1 and #3 in Vienna, where probably
#1 is more "piecemeal" and #3 more "architectural".

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 May 2003 03:06:27 +0200

On vrijdag, mei 16, 2003, at 13:10 Europe/Amsterdam, Brian E Carpenter 

> is in fact huge.

I agree, the operating systems are in good shape. Applications and 
service providers are much more problematic, not to mention the DNS.

> At least in a large corporate network, routers and

Well I'm not a huge fan of what has been happening with IPv6 so far. 
Why is it that the IETF can standardize something like A6 DNS records 
that turns out undeployable (big surprise) but at the same time over 
the past 10 years fail to come up with a way for IPv6 hosts to get at a 
DNS server (note: preferably not "discover") without using stateful 
mechanisms? But then if an IPv6 host could query an IPv6 nameserver 
that IPv6 nameserver wouldn't be able to reply without going back to 
IPv4 because the root and TLD infrastructure is oblivious to v6. And 
why exactly? For a large part because we don't want to break hosts that 
can't handle packets that are bigger than half a kilobyte. That's 
right, the amount of data an average computer these days can transmit 
in 50 microseconds.

And why choose either the IPX approach where the MAC address is part of 
the address (simple) or the Appletalk approach where hosts 
automatically find a free address (keep addresses short) when you can 
do both at the same time, adding complexity to large addresses, so 
nobody gets to be happy?

People who like to be conservative when building networks don't get 
what they want from the IETF because there are too many standards and 
*way* too many drafts (and those are often implemented so they can't be 
ignored), but at the same time people who like to be at the leading 
edge don't get what they want either because it takes forever to get 
anything done and everything has to be baby steps.

I'm sure I had a point I wanted to make but it's late so it'll have to 
wait.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 May 2003 03:06:27 +0200

Iljitsch