On Wed, Dec 31, 2008 at 3:20 PM, Brian E Carpenter <[email protected]> wrote: >> 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.
Brian, The marketplace has made it crystal clear that any acceptable definition of multihoming requires GUID survival across multihoming events. RFC 3484 does not attempt GUID survival. Session is layer 5. What would multihoming without session survival be? Layer-6 multihoming? No points for layer-7 multihoming. >>> But people don't seem to have really absorbed that IPv6 stacks, >>> and applications updated to use them, already work with multiprefix >>> PA address assignments. >>Name three such applications. No points for layer-7 multihoming or >>applications which are obscure even within the IPv6 community. > 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. These RFCs should surely be required reading for RRG participants. Nevertheless, they do not individually or in aggregate describe an operational system. They do not support a claim that "applications updated to use IPv6 stacks already [multihome] with multiprefix PA address assignments." >>Name three such applications. No points for layer-7 multihoming or >>applications which are obscure even within the IPv6 community. > small items like Internet Explorer, Firefox, > Lotus Notes Oh really? Internet Explorer will reconnect me to the server at http://[2001:500:4:13::80]/ even after a multihoming event causes the server's address to change to http://[2001:4860:0:2001::68]/? Oh I see... IE will reconnect if *its* IPv6 address changes. No points for layer-7 multihoming. Those applications perform identically in IPv4, reconnecting with whatever network resources are available. Any problem can be solved at the application layer for a single application. Architectural solutions solve the problem at a lower layer so that it stays solved for *all* applications. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
