New version of charter text
Kurt Erik Lindqvist <kurtis@kurtis.pp.se> Wed, 26 January 2005 12:20 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Wed, 26 Jan 2005 12:18:54 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <9F766F98-6F94-11D9-AF27-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: New version of charter text
Date: Wed, 26 Jan 2005 13:20:10 +0100
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, please find below a new version of the charter text. And my apologies for this taking some time. Some notes, - - I tried to address Pekka's concerns with TE, and someone in a mail proposed an applicability document. I can't find that mail now so I am not sure they referred to the same issue, but I would think that documenting what uses you get from shim6 under what conditions would address Pekka's comment. There is probably more that needs to be documented in the same way. - - I included Marcelo's proposed work item on communication establishment. - - I changed the reference to a state machine to John's proposed text on "multihoming triggers" that better referred to what I had originally through. I read Brian as still disagreeing (and I think I do to) on separating the statemachine from the protocol spec, but we seem to be the only two arguing for that :-) - - I moved the timeline for the protocol document a bit further away as per Erik's comment. I hope that should cover most of what has been discussed. - - kurtis - - ---- Site multiHoming by IPv6 interMediation (shim6) Description of Working Group: The shim6 WG is to produce specfifications 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-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 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 docuement 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 seperate draft. 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 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. However, the WG will consider developing methods for the shim6 level to handle transport layer signalling to the shim6 layer as in scope. [What other topics are explicitly in/out of scope?] 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 multihoimg 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/AwUBQfeLAaarNKXTPFCVEQK8agCgl5mYm6RZ7wensMPMjXXhY3uQx0AAoOJe eNPFzAkch34CwHSYK3TlvNsx =4QmB -----END PGP SIGNATURE-----
- Re: New version of charter text Scott W Brim
- Re: New version of charter text Kurt Erik Lindqvist
- RE: New version of charter text john.loughney
- Re: New version of charter text Erik Nordmark
- Re: New version of charter text Erik Nordmark
- Re: New version of charter text Kurt Erik Lindqvist
- Re: New version of charter text marcelo bagnulo braun
- Re: New version of charter text Brian E Carpenter
- RE: New version of charter text john.loughney
- Re: New version of charter text Erik Nordmark
- Re: New version of charter text Erik Nordmark
- Re: New version of charter text Kurt Erik Lindqvist
- Re: New version of charter text Kurt Erik Lindqvist
- Re: New version of charter text Kurt Erik Lindqvist
- Re: New version of charter text Pekka Savola
- Re: New version of charter text marcelo bagnulo braun
- New version of charter text Kurt Erik Lindqvist
- Re: New version of charter text marcelo bagnulo braun
- Re: New version of charter text Pasi Sarolahti