Re: proposed text for charter

[Geoff Huston <gih@apnic.net>]

At 06:39 AM 25/03/2005, avri@psg.com 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