RE: proposed text for charter
"Bound, Jim" <jim.bound@hp.com> Sat, 26 March 2005 16:16 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Sat, 26 Mar 2005 16:16:31 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: proposed text for charter
Date: Sat, 26 Mar 2005 11:16:16 -0500
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B08AC96FA@tayexc13.americas.cpqcorp.net>
Thread-Topic: proposed text for charter
Thread-Index: AcUwsA5biPYRL4EwT4Co/CBRTS08jABbsp5A
From: "Bound, Jim" <jim.bound@hp.com>
To: Geoff Huston <gih@apnic.net>, shim6 <shim6@psg.com>
Question: Given we solve the rehoming in some manner. App switches to new address on same interface to new ISP. Does this mean the transport layer state is maintained? I assume not but want to be sure we are all on the same page. What does this mean to the user? Answer the application must restart..... I believe the answer applies if new interface is used too ergo going from 802.11 to GPRS on handheld? /jim > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On > Behalf Of Geoff Huston > Sent: Thursday, March 24, 2005 3:26 PM > To: shim6 > Subject: Re: proposed text for charter > > 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 > > > > > >
- 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