Hi Bill, On 2008-12-31 12:14, William Herrin wrote: > On Mon, Dec 29, 2008 at 8:01 PM, Brian E Carpenter > <[email protected]> wrote: >> "So I would hate to see either A or B declared out of bounds for this >> community." > > Hi Brian, > > Unless you correct me, I'll take this to mean that you oppose > rejecting both strategy A and B. > > >> But it is my opinion that B is a lost cause for IPv4. > > It is and it isn't. > > If you fix the layer 4/5 problem where the locator gets mixed in with > the session ID, why should the resulting protocol not be layer-3 > agnostic? You just put both protocol and locator in the guid to > locator map instead of just putting a locator there. Presto! Done. > > Such a strategy-B protocol should be able to run on any layer-3 > protocol available, which means it should coexist happily with the > IPv4 backbone for as long a transition period as necessary. So in that > sense, it isn't a lost cause for IPv4. Quite the contrary, IPv4 is > part of the deployment bridge. > > But you're correct that there's no headroom for growth in IPv4. In > that respect, strategy B is a lost cause for IPv4. But then > ultimately, so is strategy A.
Yes, but my point is that any strategy for IPv4 hosts that needs changes to IPv4 host stacks is a lost cause even in the short term. Obviously anything the needs a fresh supply of IPv4 addresses is also a lost cause too. > > >> If someone can write >> a proposal that proves that wrong, I'd be delighted. > > Feel free to take a look at the *very* early and *very* rough work at > http://bill.herrin.us/network/name/name.html, especially snrp and ltp. > I don't think it proves that IPv4 isn't a lost cause, but it does show > how a strategy-B system can be layer-3 agnostic. > > >>> Name three such applications. No points for layer-7 multihoming or >>> applications which are obscure even within the IPv6 community. >> Huh? No credit for stuff that works? > > Would it surprise you to learn that while "42" is the answer to life, > the universe and everything, it is in fact not the answer to the > multihoming problem? > > RFC 3484 addresses a problem that a complete multihoming solution > might or might not run in to. Standing alone, RFC 3484 does not > address the multihoming problem in any way shape or form. Sorry but that is simply untrue *unless* your definition of multihoming requires TCP, UDP or DCCP session survival across multihoming events. Since I spent several years chairing the debate on this in the MULTI6 WG, I don't want to rehash the arguments yet again. But where we got to is in RFC3582, RFC4177, RFC4218 and RFC4219. > >> So I think you can make your own list. > > Indeed I can. It contains zero items. Mine includes small items like Internet Explorer, Firefox, Lotus Notes, and anything written in Java. Not to say there are no glitches, of course, and that we can't make things better as deployment experience increases. Of course, this world (multi-prefix PA IPv6) is new and different from RFC4116 and in particular requires nothing from ISPs except PA assignments. Happy New Year from Auckland, where 2009 arrived 9 hours ago. Brian _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
