Yet anoter charter version
Kurt Erik Lindqvist <kurtis@kurtis.pp.se> Mon, 14 February 2005 11:40 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Mon, 14 Feb 2005 11:38:51 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <35058D2E-7E7D-11D9-A1E0-000A95928574@kurtis.pp.se>
Content-Type: text/plain; charset="US-ASCII"; format="fixed"
To: shim6@psg.com
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Subject: Yet anoter charter version
Date: Mon, 14 Feb 2005 12:40:20 +0100
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, sorry for the delay. Thanks to Scott, John and Joe for providing spell checks. I have yet to get my head completely around what to write about the "hints". I have made an attempt to explain it with a few more words below, I am afraid it only got less clear :-(. Comments are welcome, and text even more so :-) Best regards, - - kurtis - - ----- Site-multiHoming by IPv6 interMediation (shim6) Description of Working Group: The shim6 WG is to produce specifications for a complete IPv6 site-multihoming solution 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-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 The shim6 WG is to publish, as standards track RFCs, specifications with enough details to allow full interoperable implementations of the shim layer approach to multihoming as agreed on by the multi6 WG. These implementations will have the ability to take advantage of multihoming without adding to the growth of the global routing table by using aggregates already announced by upstream providers. Since the solution requires state to be maintained at both ends of a communication, the protocol specification document needs to contain a state machine description. Some state transitions may result from external events, however, such as failure detection rather than from protocol events. These should be documented in a separate document. Multihoming is today also often used to achieve various other features, such as traffic-engineering. The Shim6 WG should document the use of the shim6 solution in these cases in an applicability document. 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 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 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. However, the WG will consider developing methods for the shim6 level to handle transport layer events (or indicators) to the shim6 layer as in scope. These events will include any (if at all) interaction between the application layer and the shim6 layer as well as documenting what interaction is required between the transport and the application layer. How various transport layers such as SCTP and DCCP will handle a scenario with a shim6 layer under it is not in scope to start with, but should be addressed in a separate document later. Whether this is a topic for the shim6 WG or a transport area WG is left for a future IESG decision, once the shim6 solution has been more worked out. 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 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQhCOLaarNKXTPFCVEQJkNwCgnNuouBRxQdFDz09RbZ3nTio7MOMAoOYz s/xs1E5/Wpi35IH2+LI+wfSZ =NewB -----END PGP SIGNATURE-----
- Re: Yet anoter charter version Kurt Erik Lindqvist
- RE: Yet anoter charter version john.loughney
- Re: Yet anoter charter version marcelo bagnulo braun
- Yet anoter charter version Kurt Erik Lindqvist