[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: proposed text for charter
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
>
>
>
>
>
>