Subject: Re: bar-bof Multihoming with multiple prefixes without NAT66

From: Ole Troan <[email-masked]>
Date: Mon, 2 Aug 2010 12:52:41 +0200

Brian,

> Sorry I was not in Maastricht and able to attend.
> 
> Technically, it's very interesting, and is (as far as I am
> concerned) the original plan for IPv6 multihoming, as we expected
> ten years ago.
> 
> But there's a problem. As far as I can tell from formal and
> informal contacts with IT management in typical companies
> and campuses, the idea of operating multiple prefixes in parallel,
> although fundamental in IPv6 design, is highly unwelcome to such
> managers. RFC 4192 is almost unknown, typical address management
> software packages struggle to deal with even one IPv6 prefix,
> and the aversion to renumbering when changing ISPs is enormous.
> In fact there's an RFC about that too: RFC 5887. We know that
> these site IT managers, and their ISPs, and therefore the RIRs,
> are going for PI prefixes as a result of this situation.
> 
> What I don't see is how we can make the multi-prefix approach
> the preferred approach in the industry. Showing that it works
> is not going to be enough. It has to be *easy*.

the use case which triggered this is for residential deployment. where you have two independent but aware of each other service providers (one ASP, one ISP)  delivering service into the home.

the deployment will require no configuration by the network owner (aka end user).

I wouldn't tout this type of multi-homing to enterprises (just yet).
on the other hand since every network is going to be IPv4 and IPv6 multi-homed very soon now, perhaps this isn't going to be much harder. ;-)

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 2 Aug 2010 13:38:04 +0200

Hi,

And then we have our case, where a host has two or more upstream "ISPs" that are not aware of each other in any other way than knowing the host probably has Someone Else as well... Say a cellular and a WLAN hotspot (/home WLAN) provider serving the same host. Add VPN to the soup.

It happens that the cellular ISP wants some traffic to be always sent via their interface (and rest possibly via Some Other Access), rather than everything via some other interfaces. Tools would be needed to alter hosts' common "all via WLAN or cellular or VPN" current practice.

Basic case could be:
- Internet does not care much
- Corporate wants traffic for its services via VPN tunnel
- Cellular ISP wants traffic for its services via cellular interface

Cellular ISP may say:"VoIP traffic here plz, other traffic somewhere else if feasible"
Corporate may say:"email+intranet traffic here plz, other traffic somewhere else if feasible"
and thus WLAN gets the remaining "bulk" Internet traffic.

Best regards,

Teemu
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of ext Ole Troan [[email-masked]]
Sent: Monday, August 02, 2010 1:52 PM
To: Brian E Carpenter
Cc: IPv6 Mailing List WG
Subject: Re: bar-bof Multihoming with multiple prefixes without NAT66

Brian,

cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Etienne Gallet de Santerre <[email-masked]>
Date: Mon, 02 Aug 2010 15:52:01 +0200

Hi Brian,

I am a PhD student working on home networking, and especially on 
multihoming.

I agree Ole and think that multihoming will be no longer the privilege 
of industries, but will be available to home networks too.

As a home network is not be managed by an administrator in most cases, 
the solutions have to be simple and automatic.
So, these networks will have to deal with PA prefixes, renumbering, 
internal routing and so on.
Finally, if home networks have solutions to deal with it, why industries 
can't do the same?

Regards,
Etienne Gallet de Santerre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Aug 2010 08:59:00 +1200

> Finally, if home networks have solutions to deal with it, why industries

Etienne,

I believe, and hope, that we can devise solutions that work more or less
transparently for off-the-shelf home deployment, and maybe even for
small offices. (That's assuming I believe that SOHO users will have
multiple ISPs; I have my doubts about that, but never mind.) The
reason is that SOHO users in general absolutely don't care what their
address is; they may renumber every time they reboot, so why would they
care if they have two addresses? So yes, as Ole says, this is solvable.

The problem for larger corporate networks, especially multi-office
companies, is *much* harder. They don't add or change IP prefixes
easily. Please see RFC 5887. Almost all of it applies to the multi-prefix
case as well as to simple renumbering.

    Brian

>> the use case which triggered this is for residential deployment. where
>> you have two independent but aware of each other service providers
>> (one ASP, one ISP)  delivering service into the home.
>>
>> on the other hand since every network is going to be IPv4 and IPv6
>> multi-homed very soon now, perhaps this isn't going to be much harder.
>> ;-)
>>
>> cheers,
>> Ole

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Aug 2010 13:13:47 +1000

> care if they have two addresses? So yes, as Ole says, this is solvable.

We can't use the IPv4 experience as a guide here.  99.9% of home
networks are behind a NAT so they have stable internal addressing
even when the external address changes on every reboot of the NAT.
We need to ensure that there is stable internal addressing (ULA
helps here).  Addresses used to reach external servers however can
change without much worry.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Benny Amorsen <[email-masked]>
Date: Tue, 03 Aug 2010 09:52:39 +0200

Brian E Carpenter <[email-masked]> writes:

> (That's assuming I believe that SOHO users will have multiple ISPs; I
> have my doubts about that, but never mind.)

Lots of them already do. ADSL + 3G. However, the 3G is usually connected
to each individual PC and the ADSL to the Wifi router, so right now
people just shut down the 3G when Wifi is available.

It would be neat if it was possible to access the provider-specific
services on 3G while passing bulk traffic off to ADSL when at home...

/Benny

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 4 Aug 2010 07:54:46 +0900

Brian,

> is not going to be enough. It has to be *easy*.

I agree with you that the multi-prefix is really a change, just like
or more than the introduction of IPv6 itself.

In a broader sense, however, the multi-prefix is already there,
in IPv4 and IPv6 dual-stack deployment scenario.
For example, It causes a newly emerged needs for IPv4 and IPv6
address prioritization.

And, we have invested much time on the multi-prefix way by
introducing a lot of mechanisms, addresses, and deployment
scenarios.

But now, we have found several missing pieces on this way
that needs to be filled in.

If we decide not to go on this way, we have to go all the way back to
the IPv4 way and go back further, in that we need to introduce
IPv6-NAT and also IPv4-IPv6 NAT. It seems to me that this going back
spoils what IPv6 is for.

> On 2010-07-30 04:22, Arifumi Matsumoto wrote:
>> All,
>> 
>> at yesterday's bof, we had a lot of participants and good
>> discussion. I'd like to say thank you here again.
>> 
>> At the following site, you can find the presentation slides
>> of yesterday the internet-drafts, and some related documents from BBF.
>> Though the source code is not made public yet, we are thinking and
>> trying to do so. If you have interests in it, please let us know.
>> It helps a lot for publication.
>> 
>> http://wiki.github.com/otroan/IETF-Non-Congruent-Multi-homing/
>> 
>> At the yesterday's discussion, I believe we've reached better
>> understanding of the problems and some of the possible solutions.
>> 
>> On 2010/07/28, at 17:52, Arifumi Matsumoto wrote:
>> 
>>> All,
>>> 
>>> the place and time is fixed for the bar-bof.
>>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78
>>> 
>>> We welcome everyone to drop by.
>>> 
>>> 20:00-21:30
>>> Multihoming with multiple prefixes without NAT66 : Implementation of 
>>> http://tools.ietf.org/html/draft-troan-multihoming-without-nat66. Live demonstration with running codes 
>>> related drafts: 
>>>  http://tools.ietf.org/html/draft-troan-multihoming-without-nat66 
>>>  http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt 
>>>  http://tools.ietf.org/html/draft-dec-dhcpv6-route-option 
>>>  http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection  
>>> location: 0.8 Rome 
>>> Contact:  Jun-ya Kato
>>> 
>> ------------------------------------------------------------------------
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Aug 2010 10:59:05 +1200

Hi Mark,

> change without much worry.

Yes, I agree, as long as ULAs become common practice for internal
traffic. My point exactly.

    Brian