Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt

From: Ray Hunter <[email-masked]>
Date: Thu, 01 Sep 2011 21:57:55 +0200

[email-masked] wrote:
> Subject:
> [v6ops] I-D Action: 
> draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
> From:
> [email-masked]
> Date:
> Wed, 31 Aug 2011 23:23:37 -0700
>
> To:
> [email-masked]
> CC:
> [email-masked]
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset="utf-8"
> Message:
> 1
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.
>
> 	Title           : IPv6 Multihoming without Network Address Translation
> 	Author(s)       : Ole Troan
>                            David Miles
>                            Satoru Matsushima
>                            Tadahisa Okimoto
>                            Dan Wing
> 	Filename        : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
> 	Pages           : 21
> 	Date            : 2011-08-31
>
>     Network Address and Port Translation (NAPT) works well for conserving
>     global addresses and addressing multihoming requirements, because an
>     IPv4 NAPT router implements three functions: source address
>     selection, next-hop resolution and optionally DNS resolution.  For
>     IPv6 hosts one approach could be the use of IPv6 NAT.  However, NAT
>     should be avoided, if at all possible, to permit transparent end-to-
>     end connectivity.  In this document, we analyze the use cases of
>     multihoming.  We also describe functional requirements and possible
>     solutions for multihoming without the use of NAT in IPv6 for hosts
>     and small IPv6 networks that would otherwise be unable to meet
>     minimum IPv6 allocation criteria.  Nevertheless, we mention that the
>     possible needs for IPv6 NAT in the transition phase to the fully
>     deployment of the proposed solutions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt
>
>    
IMHO This is very useful work for the IETF, and I think multihoming will 
be very much a requirement for IPv6, and in particular homenet.

The UK gas company has just announced today that it is rolling out smart 
meters to two million homes before the end of 2012. They will be 
equipped with GPRS for the Internet uplink and zigbee for the in-house 
communication to devices such as fridges etc. Multihoming will very 
likely become commonplace at least in Europe, as roll out of smart 
meters are the subject of an EU directive. You then have to ask whether 
you are going to treat this as a separate Internet, with home devices 
choosing to peer with just this smart meter Internet or just to another 
upstream connection in the home, or whether to use one as a backup for 
the upstream Internet link in a main/standby scenario. I think the 
consumer is going to expect that different Internet networks will 
cooperate to increase overall end to end reliability, and also to extend 
the range of e.g. zigbee around the home, which means there will be a 
need for the technology identified in this draft.

There has been some discussion on this topic on another (non IETF) list, 
and on various other drafts.

It seems to me that the problem for source and destination address 
selection, DNS server selection, and next hop selection, in a 
multi-homed environment without inter AS routing, shares a lot in common 
with the problem of selecting the "correct" address family ala Happy 
Eyeballs.

The draft doesn't mention such parallels, which rather surprises me 
given the authors.

I could certainly imagine a viable solution to simple multihoming in the 
absence of better (routing) information to be "assign all hosts a GUA 
IPv6 address from each upstream provider prefix. Each host can then try 
all combinations of DNS Server, source address, destination address, and 
next hop router, and remember/cache what worked to establish a working 
session for this source-destination pair." The policy could be used to 
handicap the order in which DNS servers and source and destination 
addresses and next hop are tested.

Invalid combinations of source address and next hop will anyway be 
filtered by the ingress filters of any good ISP or homenet egress 
filter, so that won't cause any worrisome upstream traffic, just one or 
two wasted LAN packets.

Another alternative is that ISP's will cooperate locally to "right home" 
any stray source address traffic asap into the correct upstream network 
via source address routing/policy based routing and local peering 
agreements.

Which may still leave some minimal "overhead" upstream traffic to figure 
out which destination is available via which upstream ISP network, given 
that the home devices only have a simple default route. Again replies 
from a multi-homed desinatation would also be filtered for inappropriate 
combinations of source address/ next hop. So successful sessions should 
only be built over appropriate paths.

There'd of course be a trade off between how many sessions you'd be 
prepared to kick off in parallel / wasted syn/syn acks / and session 
start up delay, versus the speed of detecting the working combination(s) 
between any source and destination pair where both the source and 
destination where multihomed. There'd also be some need to detect when 
to refresh/ age out the cache.

But none of this needs to be fundamentally different to AF selection of 
Happy Eyeballs IMVHO.

regards,
RayH

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Sep 2011 16:17:41 -0700

> -----Original Message-----
> From: Ray Hunter [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 12:58 PM
> To: [email-masked]
> Cc: Ole Troan; Dan Wing; [email-masked];
> [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-
> ipv6nat-01.txt
... 
> IMHO This is very useful work for the IETF, and I think multihoming
> will be very much a requirement for IPv6, and in particular homenet.
> 
> The UK gas company has just announced today that it is rolling out
> smart meters to two million homes before the end of 2012. They will be
> cooperate to increase overall end to end reliability, and also to
> extend the range of e.g. zigbee around the home, which means there will
> be a need for the technology identified in this draft.
> 
> There has been some discussion on this topic on another (non IETF)
> list, and on various other drafts.
> 
> selection, DNS server selection, and next hop selection, in a multi-
> homed environment without inter AS routing, shares a lot in common with
> the problem of selecting the "correct" address family ala Happy
> Eyeballs.
> 

So far, when there are multiple viable uplinks to the Internet, it
seems one of them has a limitation of some sort -- it is slower
(e.g., high latency such as 3G), more expensive (e.g., $ per KB), 
bandwidth capped (e.g., above 2GB per month the cost skyrockets).
There is some sort of hand-waving 'policy' decision involved here.
For example, if all your friends are visiting to watch the football
game, you're probably going to spend the extra $5 to use your 
high-cost backup link.  Someone else might be willing to use
whichever upstream ISP can provide the fastest connection (but
that might or might not correspond to the 'best' connection if
round-trip time doesn't correspond to bandwidth).  Someone else
might only want to use an expensive backup link in an emergency
(to call the fire department).  The policy decisions aren't 
something Happy Eyeballs can help with too much.

But, after the policy has decided that a certain interface should
be tried, a Happy Eyeballs-like mechanism can be useful.  The
document draft-chen-mif-happy-eyeballs-extension is one place this 
interaction between policy and Happy Eyeballs is discussed.  Andrew 
Yourtchenko gave a presentation at IETF81 which explains where we hope 
to separate Happy Eyeballs from the 'policy'.  Slides are
at http://www.ietf.org/proceedings/81/slides/mif-4.ppt and that
room's audio should be
http://www.ietf.org/audio/ietf81/ietf81-208ab-20110728-1256-pm.mp3

> I could certainly imagine a viable solution to simple multihoming in
> the absence of better (routing) information to be "assign all hosts a
> GUA IPv6 address from each upstream provider prefix. Each host can then
> try all combinations of DNS Server, source address, destination
> address, and next hop router, and remember/cache what worked to
> establish a working session for this source-destination pair." The
> policy could be used to handicap the order in which DNS servers and
> source and destination addresses and next hop are tested.
> 
> Another alternative is that ISP's will cooperate locally to "right
> home" any stray source address traffic asap into the correct upstream
> network via source address routing/policy based routing and local
> peering agreements.

The ISPs would have to know about each other to do that, and cooperate
to achieve that.  So far, even when they know about each other they
don't do such cooperation.

> Which may still leave some minimal "overhead" upstream traffic to
> figure out which destination is available via which upstream ISP
> network, given that the home devices only have a simple default route.
> Again replies from a multi-homed desinatation would also be filtered
> for inappropriate combinations of source address/ next hop. So
> successful sessions should only be built over appropriate paths.
> 
> start up delay, versus the speed of detecting the working
> combination(s) between any source and destination pair where both the
> source and destination where multihomed. There'd also be some need to
> detect when to refresh/ age out the cache.
> 

Agreed they are closely related.

-d