Re: proposed text for charter
Dave Crocker <dhc2@dcrocker.net> Thu, 24 March 2005 21:22 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Thu, 24 Mar 2005 21:23:23 +0000
From: Dave Crocker <dhc2@dcrocker.net>
To: Geoff Huston <gih@apnic.net>
CC: shim6 <shim6@psg.com>
Reply-To: Dave Crocker <dcrocker@bbiw.net>
Date: Thu, 24 Mar 2005 13:22:44 -0800
Message-ID: <2005324132244.636380@BBPRIME>
Subject: Re: proposed text for charter
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Tidbits... On Fri, 25 Mar 2005 07:26:14 +1100, Geoff Huston wrote: > 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 ------------ independant > 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 [[ yes. nice clarification. ]] > 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 ----- work > 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. [[ is the last sentence really a separate bullet? if not, i don't understand how only the ingress issue can work without the other side supporting shim6. if yes, i STILL don't understand how it can work. offhand, it seems impossible. ]] > o Solutions to establish new communications after an outage has > occurred that does not requires shim support from the non-multihomed ---- do > end of the communication. The wg will explore if such solutions are -- -- working group whether > also useful when both ends support the shim. > > o Congestion control and explore how this and other QoS and ^to > traffic engineering issues may interact with the use of multiple > locators at both ends. ^(topology-specific addresses) > o The relationships between Upper Layer Identifiers (ULIDs) > and Unique Local Addresses. [[ "Unique Local Addresses" is in caps, so presumably it is a term of art, but it is not defined here. It should be. However I'm not 100% certain I know what it means. ]] > o ICMP error demuxing for locator failure discovery. [[ sounds interesting. what is it? ]] > 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 xxxxx > 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 d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
- proposed text for charter Jari Arkko
- Re: proposed text for charter Thierry Ernst
- RE: proposed text for charter john.loughney
- Re: proposed text for charter Brian E Carpenter
- Re: proposed text for charter Jari Arkko
- Re: proposed text for charter Erik Nordmark
- RE: proposed text for charter Bound, Jim
- Re: proposed text for charter Brian E Carpenter
- Re: proposed text for charter Jari Arkko
- RE: proposed text for charter Bound, Jim
- Re: proposed text for charter Thierry Ernst
- Re: proposed text for charter Iljitsch van Beijnum
- RE: proposed text for charter Bound, Jim
- RE: proposed text for charter Bound, Jim
- Re: proposed text for charter Margaret Wasserman
- Re: proposed text for charter Dave Crocker
- Re: proposed text for charter Geoff Huston
- Re: proposed text for charter avri
- Re: proposed text for charter Brian E Carpenter
- Re: proposed text for charter Dave Crocker
- Re: proposed text for charter Jari Arkko
- Re: proposed text for charter Erik Nordmark
- Re: proposed text for charter Erik Nordmark
- Re: proposed text for charter Brian E Carpenter
- RE: proposed text for charter john.loughney
- Re: proposed text for charter Erik Nordmark
- Re: proposed text for charter marcelo bagnulo braun
- Re: proposed text for charter marcelo bagnulo braun
- Re: proposed text for charter Thomas Narten
- Re: proposed text for charter Jari Arkko
- Re: proposed text for charter Thomas Narten