[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Charter v4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, last update with changes proposed by John.
I only have two positives by Marcelo and John. I assume that means that
everyone things that we are ready for the BOF in MPLS? Here silence
will assumed to be consent :-)
- - kurtis -
Site-multiHoming by IPv6 interMediation (shim6)
Description of Working Group:
The shim6 WG is to produce specifications for an 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 fully 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/AwUBQhXC+6arNKXTPFCVEQKs4gCfWfW27UseNYVTdIODE48DBUpQQMYAnj9b
iAWVPvWFMPIVW0LuyUIMAJ2g
=zL2J
-----END PGP SIGNATURE-----