Hi, On 2010/06/02, at 2:36, Ole Troan wrote:
> 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.) 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. > 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. What Ole mentioned was an example of the need of different capability of multihoming. The word "multihoming" itself may be misleading, though. >> 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. 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. >> 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. 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: arif...@nttv6.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
