Hi, Picking 6man as a likely list to discuss this draft...
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.) 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? 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. Regards Brian On 2010-05-26 01:15, [email protected] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv6 Multihoming without Network Address Translation > Author(s) : O. Troan, et al. > Filename : draft-troan-multihoming-without-nat66-00.txt > Pages : 1 > Date : 2010-05-25 > > 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 host-to- > host connectivity. In this document, we analyze the use cases of > multihoming. We also describe functional requirements 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 . > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-troan-multihoming-without-nat66-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
