[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments about the draft charter
imho the draft looks good,
just some comments below...
Site multiHoming by IPv6 interMediation (shim6)
Description of Working Group:
The shim6 WG is to produce specfifications for a complete IPv6 site
multihoming solutions 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
scale. The outcome of the multi6 WG is a specific network layer shim
architecture for addressing and address handling of sites and nodes.
includes switching to different locator addresses when connectivity
but without the changes of address being visible to upper layers,
a fixed Upper Layer Identifier address (ULID).
The shim6 WG is to complete this work with the required protocol
and complete the architecture and security analysis of the required
The background documents to be considered by the WG include:
The input documents that the WG will use as the basis for its design
draft-ietf-multi6-l3shim-00.txt [to be published shortly]
draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
[Comment - We specifically omitted the IPv4 document and Geoff's
architecture analysis - we're assuming that will be replaced for
the new WG by his solution architecture.]
The shim6 WG is to submit, as standards track RFCs, specifications with
enough details to allow full interoperable implementations of the shim
layer appproach to multihoming as agreed on by the multi6 WG. These
implementations should have the ability to take advantage of
multihoming without adding to the growth of the global routing table,
by using the aggregates already announced by their upstream providers.
Since the solution requires state to be maintained at both ends of a
communication, the protocol specification and the state machine will
somewhat independently. Some state transitions may result from external
events such as failure detection rather than from protocol events.
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 A solution for site exit router selection that works when each
uses ingress filtering, i.e. when the chosen site exit needs to
related to the source address chosen by the host. This solution
should work whether or not the peer site supports the shim6
i would add an additional item here:
- A solution 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 solution is also
useful when both ends support the shim.
imho this is relevant becuase it would provide an incremental
deployment model to the solution. If this is not provided, it is all or
nothing approach w.r.t. to fault tolerance i.e. if the other end
support the shim, then you get all the benefits but if the other end
does not supports the shim then no additional fault tolerance is
o Explore how congestion control and other QoS and traffic
issues may interact with the use of multiple locators at both
o Investigate relationship 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
[What other topics are explicitly out of scope?]
i mean, it is a non goal to provide better security than current
single-homed ipv6 internet
MAY 05 First draft of architectural and protocol document
MAY 05 First draft on cryptographic locators, if required
MAY 05 First draft on state managment
SEP 05 WG last-call on architectural/protocol document
NOV 05 Submit complete architectural/protocol document to IESG
NOV 05 WG last-call on cryptographic locators, if required
JAN 06 WG last-call on state management
JAN 06 Submit draft on cryptographic locators to the IESG, if
MAR 06 Submit draft on state management to the IESG