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: ipv6-boun...@ietf.org [ipv6-boun...@ietf.org] On Behalf Of ext Ole Troan [otr...@employees.org] 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, > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
