Re: proposed text for charter

[Margaret Wasserman <[e-mail]>]

This is coming together quite nicely.  Thanks, Jari, Erik, Dave, 
Geoff and others!

Margaret

At 7:26 AM +1100 3/25/05, Geoff Huston wrote:
>At 06:39 AM 25/03/2005, [e-mail] wrote:
>>Hi,
>>
>>While it does not offer everything I would want, I am fairly 
>>comfortable with the charter as currently proposed.
>
>I've added in milestones, background documents, and chartered work 
>items to this proposed text, and the text then looks as follows:
>
>
>For the purposes of redundancy, load sharing, operational policy or cost, a
>site may be multihomed, with the site's network having connections to
>multiple IP service providers. The current Internet routing infrastructure
>permits multihoming using provider-in dependant 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 multihoming solution that
>inserts a new sub-layer (shim) into the IP stack of end-system hosts. It
>will enable hosts on multihomed 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 rehoming 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 (called 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 multihomed 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 continue using Mobile IPv6 when using Shim6 simultaneously.
>    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 multihoming and IP mobility, but the working
>    group will not take on such mobility capabilities directly.
>
>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 works 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 solution
>        should work whether or not the peer site supports the shim6
>        protocol.
>
>      o Solutions to establish new communications after an outage has
>        occurred that does not requires shim support from the non-multihomed
>        end of the communication. The wg will explore if such solutions are
>        also useful when both ends support the shim.
>
>      o Congestion control and explore how this and other QoS and
>        traffic engineering issues may interact with the use of multiple
>        locators at both ends.
>
>      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 RFCs, specifications with
>enough details to allow fully interoperable implementations.
>
>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.
>
>Milestones
>
>MAY 05    First draft of architectural document
>MAY 05    First draft of protocol document
>MAY 05    First draft on cryptographic locators, if required
>MAY 05    First draft on multihoming triggers description
>MAY 05    First draft on applicability statement document
>
>SEP 05    WG last-call on architectural document
>SEP 05    WG last-call on applicability statement document
>
>NOV 05    WG last-call on protocol document
>NOV 05    WG last-call on cryptographic locators, if required
>NOV 05    Submit completed architectural document to IESG
>NOV 05    Submit applicability statement document to IESG
>
>JAN 06    WG last-call on multihoming triggers description
>JAN 06    Submit document on cryptographic locators to the IESG, if
>           required
>JAN 06    Submit protocol document to the IESG
>
>MAR 06    Submit draft on multihoming triggers description to the IESG
>
>
>