multi6 interim meeting agenda Chairs: Brian Carpenter, Kurt Lindqvist 1.IPR reminder, logistics, agenda bashing 2.Charter review 3.draft-lear-multi6-things-to-think-about-03.txt (max 45 mins) 4.draft-nordmark-multi6-threats-01.txt (max 45 mins) 5.draft-huston-multi6-architectures-00.txt 6.Discuss impact of various categories of solutions 7.Conclusions, where next?

IPR reminder IETF rules apply today RFC 3667 and 3668 define Intellectual Property Rights rules (next slide) Other IETF reminders: –We assume you have read the drafts –Take turns at the microphone –Sign the list –Meeting minutes will be public

Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: -the IETF plenary session, -any IETF working group or portion thereof, -the IESG or any member thereof on behalf of the IESG, -the IAB or any member thereof on behalf of the IAB, -any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, -the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.

Logistics Coffee break about 10:00 Lunch break about 12:00 Coffee break about 15:00 Close about 17:00 Default lunch location: Santa Monica Center mall (food center) –Left (North) on Ocean Ave. –Right on Colorado  300 block

WG Charter (1) WG will consider how to multihome sites in IPv6. Multihoming approaches used in IPv4 can be used in IPv6, but IPv6 is an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not applicable to IPv4. IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Modest enhancements to IPv6 could still be proposed. RFC 3582 defines goals for IPv6 site multihoming. These goals are ambitious and some may conflict with others. Solution(s) may only be able to satisfy some of the goals.

WG Charter (2) Document describing how multihoming is done in IPv4, including an explanation of both the advantages and limitations of the approaches. Document outlining practical questions to be considered when evaluating proposals meeting RFC 3582 goals, including upper layer protocols. Document describing security threats to be addressed. Solicit and evaluate specific proposals (both existing and new), extract and analyse common architectural features, and select one or a small number of proposals for further development. Architectural analysis will include applications and transport layer considerations.  Development of specific solutions will require chartering of work in the appropriate Area or Areas.

This page intentionally left blank

Some questions (1) Are we reasonably happy with the threat analysis? –Adopt as WG draft? Are we reasonably happy with the “things to think about” draft? –Adopt as WG draft? Has Geoff’s analysis missed any big aspects? –Adopt as WG draft?

Some questions (2) Is modifying all transport layers to deal with multihoming realistic? –Are all transport layers equal for mh? Will applications in general deal with mh issues? –Do we believe that any applications will deal with mh issues?

Some questions (3) Is it reasonable to assume that socket state can include mh state? –Or does the necessary state have to be dissociated from sockets? Can the IP layer accurately decide when to forget mh state? –Does it matter if mh state stays too long?

Some questions (4) Is it reasonable to expect any change from the inter-domain routing system? Is it reasonable to expect any change from the intra-domain routing system? Is exit router selection by host inevitable? Is source address selection by host inevitable?

Some questions (5) Can we make a functional decomposition, e.g. –Component to establish mh session state –Component to trigger rehoming –Component to choose new address pair –Component to execute rehoming –Component to delete mh session state

Some questions (6) Can we group proposals into 3 or 4 classes and analyze them against –Goals –Things to think about –Threats –Architectural decomposition?