A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Friday, June 24th. +++ Site Multihoming by IPv6 Intermediation (shim6) ============================================== Current Status: Proposed Working Group Internet Area Director(s): Mark Townsley <townsley at cisco.com> Margaret Wasserman <margaret at thingmagic.com> Internet Area Advisor: TBD WG Chair(s): TBD Technical Advisor(s): TBD Secretary(ies): TBD Mailing List: shim6 at psg.com To Subscribe: shim6-request at psg.com Archive: TBD Description: For the purposes of redundancy, load sharing, operational policy or cost, a site may be multi-homed, with the site's network having connections to multiple IP service providers. The current Internet routing infrastructure permits multi-homing using provider independent addressing, and adapts to changes in the availability of these connections. However if the site uses multiple provider-assigned address prefixes for every host within the site, host application associations cannot use alternate paths, such as for surviving the changes or for creating new associations, when one or more of the site's address prefixes becomes unreachable. This working group will produce specifications for an IPv6-based site multi-homing solution that inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider-assigned IP address prefixes and switch between them without upsetting transport protocols or applications. The work will be based on the architecture developed by the IETF multi6 working group. The shim6 working group is to complete the required protocol developments and the architecture and security analysis of the required protocols. Requirements for the solution are: o The approach must handle re-homing both existing communication and being able to establish new communication when one or more of the addresses is unreachable. o IPv6 NAT devices are assumed not to exist, or not to present an obstacle about which the shim6 solution needs to be concerned. o Only IPv6 is considered. o Changes in the addresses that are used below the shim will be invisible to the upper layers, which will see a fixed address (termed Upper Layer Identifier or ULID). o ULIDs will be actual IP addresses, permitting existing applications to continue to work unchanged, and permitting application referrals to work, as long as the IP Addresses are available. o The solution should assume ingress filtering may be applied at network boundaries. o The solution must allow the global routing system to scale even if there is a very large number of multi-homed sites. This implies that re-homing not be visible to the routing system. o Compatibility will remain for existing mobility mechanisms. It will be possible to use Mobile IPv6 on a node that also supports Shim6. However, any optimizations or advanced configurations are out of scope for shim6. o The approach is to provide an optimized way to handle a static set of addresses, while also providing a way to securely handle dynamic changes in the set of addresses. The dynamic changes might be useful for future combinations of multi-homing and IP mobility, but the working group will not take on such mobility capabilities directly. o The specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet. The background documents to be considered by the WG include: RFC 3582 draft-ietf-multi6-architecture-04.txt draft-ietf-multi6-things-to-think-about-01.txt draft-ietf-multi6-multihoming-threats-03.txt The input documents that the WG will use as the basis for its design are: draft-huston-l3shim-arch-00.txt draft-ietf-multi6-functional-dec-00.txt draft-ietf-multi6-l3shim-00.txt draft-ietf-multi6-failure-detection-00.txt draft-ietf-multi6-hba-00.txt draft-ietf-multi6-app-refer-00.txt In addition to the network layer shim solution, the shim6 WG is specifically chartered to work on: o Solutions for site exit router selection that work when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This site exit router selection and the associated address selection process should work whether or not the peer site supports the shim6 protocol. o Solutions to establish new communications after an outage has occurred that do not require shim support from the non-multihomed end of the communication. The Working Group will explore whether such solutions are also useful when both ends support the shim. o The possible impact of the use of multiple locators at both ends on congestion control, traffic engineering, and QoS will be analysed in conjunction with the Transport Area. o The relationships between Upper Layer Identifiers (ULIDs) and unique local addresses. o ICMP error demuxing for locator failure discovery. o If necessary, develop and specify formats and structure for: - Cryptographically protected locators - Carrying the flow label across the shim layer defined in the multi6 architecture. The shim6 WG is to publish, as standards track RFC's, specifications with enough details to allow fully interoperable implementations. Milestones AUG 05 First draft of architectural document AUG 05 First draft of protocol document AUG 05 First draft on cryptographic locators, if required AUG 05 First draft on multi-homing triggers description AUG 05 First draft on applicability statement document OCT 05 WG last-call on architectural document OCT 05 WG last-call on applicability statement document FEB 06 WG last-call on protocol document FEB 06 WG last-call on cryptographic locators, if required FEB 06 Submit completed architectural document to IESG FEB 06 Submit applicability statement document to IESG APR 06 WG last-call on multihoming triggers description APR 06 Submit document on cryptographic locators to the IESG, if required APR 06 Submit protocol document to the IESG JUN 06 Submit draft on multihoming triggers description to the IESG _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
