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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
