Re: fwd: WG Action: Site Multihoming by IPv6 Intermediation (shim6)

[Geoff Huston <[e-mail]>]

A minor correction:

The Secretariat's  announcement omitted Thomas Narten as the other 
technical reviewer
for this working group

thanks,

   Geoff



At 10:56 AM 30/06/2005, Geoff Huston wrote:
>The following Secretariat message bounced when posted to the shim6 mailing 
>list
>
>   Geoff
>
>------------------
>
>
>A new IETF working group has been formed in the Internet Area. For additional
>information, please contact the Area Directors or the WG Chairs.
>
>+++
>
>Site Multihoming by IPv6 Intermediation (shim6)
>================================================
>
>Current Status: Active Working Group
>
>Chair(s):
>Kurt Lindqvist <[e-mail]>
>Geoff Huston <[e-mail]>
>
>Internet Area Director(s):
>Mark Townsley <[e-mail]>
>Margaret Wasserman <[e-mail]>
>
>Internet Area Advisor:
>Margaret Wasserman <[e-mail]>
>
>Technical Advisor(s):
>Dave Meyer <[e-mail]>
>
>Mailing Lists:
>General Discussion: [e-mail]
>To Subscribe: [e-mail]
>Archive:
>
>Description of Working Group:
>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.
>
>Goals and 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
>
>
>