[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments about the draft charter

Hi all,

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 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-solution-stilltobewritten
 draft-ietf-multi6-functional-dec-00.txt
 draft-ietf-multi6-l3shim-00.txt [to be published shortly]
 draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
 draft-ietf-multi6-hba-00.txt
 draft-ietf-multi6-app-refer-00.txt

[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 be designed
somewhat independently. Some state transitions may result from external
events such as failure detection rather than from protocol events. 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 A solution 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.


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 achieved.

o Explore how congestion control and other QoS and traffic engineering
issues may interact with the use of multiple locators at both ends.

     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
identifier formats.
[What other topics are explicitly out of scope?]


enhanced security?
i mean, it is a non goal to provide better security than current single-homed ipv6 internet

regards, marcelo


Milestones


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 required

MAR 06 Submit draft on state management to the IESG