Subject: Re: I-D Action:draft-troan-multihoming-without-nat66-00.txt

From: Ole Troan <[email-masked]>
Date: Tue, 1 Jun 2010 14:36:10 -0300

Brian,

> Picking 6man as a likely list to discuss this draft...

apologies for the delay. on holiday, but it is raining in Rio today so I might as well do email.

> 
> Three high level comments:
> 
> 1. When we did the work that led to RFC 3582, a very clear consensus
> was that transport-layer session survival was a required feature of
> any acceptable multihoming solution. That promptly blew the whole
> idea of plain multi-addressing out of the water, which is of course
> how we got to shim6. If you follow the history since then, it's
> also how we got LISP and a large part of the RRG work, including
> the recent RRG Chairs' recommendation of ILNP.
> 
> What has changed? Why would breaking transport sessions be acceptable
> now? (I realise that NAT66 based multihoming also breaks transport
> sessions, so the same question applies there.)

the model here is slightly different. what triggered this is a walled garden service delivered by one service provider in combination with another service provider delivering IPv6 Internet service.
this resulting in 2 IPv6 prefixes in the home network. I've called this "non-congruent multi-homing" as the prefixes apply in two entirely separate networks, and choosing the wrong source address would result in no connectivity.

solutions like SHIM6 wouldn't work here.

> 
> 2. Since that time, I haven't encountered any IT managers that have
> any idea in their head of deploying multiple IPv6 prefixes in parallel,
> even though it's a design feature and as far as I know works pretty
> well apart from the issues raised in this draft.
> 
> What reason do we have to believe that the multi-addressing model
> will become standard practice? Isn't the avoidance of multi-addressing
> 95% of the attraction of stateless NAT66 to IT managers?

this is deployed in home networks. hopefully IT managers wouldn't do this. we can certainly argue that it isn't pretty. walled garden services rarely are.

> 
> 3. That said, the problems that this draft tackles all seem like
> good ones to solve. But I think that tying them to NAT66-avoidance
> or even to multihoming confuses things - they are just general
> issues created by the IPv6 multi-addressing model itself.

that's certainly correct. the reason we coupled them to IPv6 NAT avoidance was to get attention. these issues have floated around and we wanted to make it clear to people that unless we solve them soon, then we will start seeing lots of deployment of IPv6 NATs.

cheers,
Ole

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 2 Jun 2010 13:30:40 +0900

Hi,

>> sessions, so the same question applies there.)

I understand that shim6 and LISP are ongoing efforts in IETF for
multihoming issue. Our motivation is that, like NAT-based multihoming
in IPv4, we need other kind of multihoming mechanism that has different
characteristics such as unilateral-ness.

As you mentioned, shim6 and LISP has session survivality as one of the
main benefits. However, such a capability is not always necessary for
every case of multihoming.

> solutions like SHIM6 wouldn't work here.

What Ole mentioned was an example of the need of different capability
of multihoming.

The word "multihoming" itself may be misleading, though.

> this is deployed in home networks. hopefully IT managers wouldn't do this. we can certainly argue that it isn't pretty. walled garden services rarely are.

I think it is chicken-and-egg.
Right now, the multi-prefix does not work nicely because of the
lacking mechanisms documented in this draft. And IMO, those people
will lead to invention of NAT for IPv6.

> that's certainly correct. the reason we coupled them to IPv6 NAT avoidance was to get attention. these issues have floated around and we wanted to make it clear to people that unless we solve them…

As I mentioned above, the word "multihoming" may mean session survival
for not a few people, so in that sense, we may need different term.

Regarding NAT66-avoidance, we believe we need these mechanisms to
avoid that.

Kindest regards,

--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 02 Jun 2010 10:08:02 +0200

>will lead to invention of NAT for IPv6.

In Section 4.2 "Next-hop selection", the draft says:
"Scenario 1: "Host" needs to support the solution for this problem"

This is not quite true. 

I'm running some code at home where when the host selects a source address and
uses a next hop that is incompatible with the prefix, the router will send a
redirect to the right router. Routers use an extension to RIPng to inform
each other about source prefixes, and which routers support them.

(For optimal performance, the host's destination cache should be changed, 
but it also works with stock IPv6 stacks).

This solves that case where you have redundant connections through differnt
ISPs. I didn't experiment with this yet, but I assume that longest prefix
matching in source address select may even provide a primitive kind of
load balancing.

I guess that in a walled guarden, if the source prefix is within the same
(shorter) prefix as all destinations, then this may also solve that problem.