Mailing list and draft charter for new multihoming BOF/WG

This is a multi-part message in MIME format.
--------------040300090505060009050907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

As promised, Kurtis and I have drafted a charter for the proposed
WG to standardize the IPv6 multihoming shim layer.

The (perhaps temporary) mailing list is [email protected]

Join by sending a message to [email protected] containing
one line:
  subscribe shim6
and respond as necessary to the confirmation message.

The draft charter is attached. Please DO NOT discuss it on this
(multi6) list - if you want to discuss it, please join the shim6
list and discuss it there.

Be aware that if you reply to this message, your reply will be sent
to the shim6 list. It would be a good idea to subscribe first!

We will request a shim6 BOF at the next IETF, and also start the
process of forming at WG. But first, we need your comments on
the draft charter.

Regards

     Brian and Kurtis

P.S.

The final three multi6 deliverables were submitted to the IESG today.
That's
  draft-ietf-multi6-v4-multihoming-03
  draft-ietf-multi6-architecture-03.txt
  draft-ietf-multi6-things-to-think-about-01.txt





--------------040300090505060009050907
Content-Type: unknown/exe;
 name="draft-shim6-charter-20050111.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-shim6-charter-20050111.txt"

Site multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specfifications for a complete IPv6 site
multihoming solutions based on the architecture developed by the IETF
multi6 WG. The multi6 WG was tasked with investigating solutions to
the site multihoming problem that will allow the global routing system to
scale. The outcome of the multi6 WG is a specific network layer shim
architecture for addressing and address handling of sites and nodes. This
includes switching to different locator addresses when connectivity changes,
but without the changes of address being visible to upper layers, which see
a fixed Upper Layer Identifier address (ULID).

The shim6 WG is to complete this work with the required protocol developments 
and complete the architecture and security analysis of the required protocols.

The background documents to be considered by the WG include:

 RFC 3582
 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-solution-stilltobewritten
 draft-ietf-multi6-functional-dec-00.txt
 draft-ietf-multi6-l3shim-00.txt [to be published shortly]
 draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
 draft-ietf-multi6-hba-00.txt
 draft-ietf-multi6-app-refer-00.txt

[Comment - We specifically omitted the IPv4 document and Geoff's
architecture analysis - we're assuming that will be replaced for
the new WG by his solution architecture.]

The shim6 WG is to submit, as standards track RFCs, specifications with
enough details to allow full interoperable implementations of the shim
layer appproach to multihoming as agreed on by the multi6 WG. These
implementations should have the ability to take advantage of
multihoming without adding to the growth of the global routing table,
by using the aggregates already announced by their upstream providers. 

Since the solution requires state to be maintained at both ends of a 
communication, the protocol specification and the state machine will be designed
somewhat independently. Some state transitions may result from external
events such as failure detection rather than from protocol events. More work
items and milestones might need to be added at a later date to
complete all implementation details needed.

In addition to the basic network layer shim solution, the shim6 WG 
is specifically chartered to do work on

     o A solution 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 Explore how congestion control and other QoS and traffic engineering
       issues may interact with the use of multiple locators at both ends.

     o Investigate relationship 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 WG will consider whether the proposed model is exposed to
any security threats in addition to those documented in
draft-ietf-multi6-multihoming-threats-03.txt. In any case,
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 WG will not consider items outside the above scope, such as
interaction with mobility, transport level solutions, or alternative 
identifier formats.
[What other topics are explicitly out of scope?]

Milestones


MAY 05    First draft of architectural and protocol document
MAY 05    First draft on cryptographic locators, if required
MAY 05    First draft on state managment

SEP 05    WG last-call on architectural/protocol document

NOV 05    Submit complete architectural/protocol document to IESG
NOV 05    WG last-call on cryptographic locators, if required

JAN 06    WG last-call on state management
JAN 06    Submit draft on cryptographic locators to the IESG, if required

MAR 06    Submit draft on state management to the IESG
--------------040300090505060009050907--