-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, sorry for the delay. Thanks to Scott, John and Joe for providing
spell checks.
I have yet to get my head completely around what to write about the
"hints". I have made an attempt to explain it with a few more words
below, I am afraid it only got less clear :-(.
Comments are welcome, and text even more so :-)
Best regards,
- - kurtis -
- -----
Site-multiHoming by IPv6 interMediation (shim6)
Description of Working Group:
The shim6 WG is to produce specifications 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-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 full 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/AwUBQhCOLaarNKXTPFCVEQJkNwCgnNuouBRxQdFDz09RbZ3nTio7MOMAoOYz
s/xs1E5/Wpi35IH2+LI+wfSZ
=NewB
-----END PGP SIGNATURE-----