Site Multihoming by IPv6 Intermediation (shim6)

Last Modified: 2008-04-23

Additional information is available at tools.ietf.org/wg/shim6

Chair(s):

  • Kurt Lindqvist <kurtis@kurtis.pp.se>

  • Geoff Huston <gih@apnic.net>

    Internet Area Director(s):

  • Ralph Droms <rdroms@cisco.com>
  • Jari Arkko <jari.arkko@piuha.net>

    Internet Area Advisor:

  • Jari Arkko <jari.arkko@piuha.net>

    Technical Advisor(s):

  • Thomas Narten <narten@us.ibm.com>

    Mailing Lists:

    General Discussion: shim6@psg.com
    To Subscribe: shim6-request@psg.com
    Archive: http://ops.ietf.org/lists/shim6/

    Description of Working Group:

    For the purposes of redundancy, load sharing, operational policy or
    cost, a site may be multi-homed, with the site's network having
    connections to multiple IP service providers. The current Internet
    routing infrastructure permits multi-homing using provider independent
    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 multi-homing solution that
    inserts a new sub-layer (shim) into the IP stack of end-system hosts.
    It will enable hosts on multi-homed 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 re-homing 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 (termed
    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 multi-homed 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 use Mobile IPv6 on a node that also supports Shim6.
    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 multi-homing and IP mobility, but the
    working group will not take on such mobility capabilities directly.

    o 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 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 work 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 site
    exit router selection and the associated address selection
    process should work whether or not the peer site supports
    the shim6 protocol.

    o Solutions to establish new communications after an outage has
    occurred that do not require shim support from the
    non-multihomed end of the communication. The Working Group will
    explore whether such solutions are also useful when both ends
    support the shim.

    o The possible impact of the use of multiple locators at both ends
    on congestion control, traffic engineering, and QoS will be analysed
    in conjunction with the Transport Area.

    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 RFC's, specifications
    with enough details to allow fully interoperable implementations.

    Goals and Milestones:

    Done  First draft of architectural document
    Done  First draft of protocol document
    Done  First draft on cryptographic locators, if required
    Done  First draft on multi-homing triggers description
    Done  First draft on applicability statement document
    Done  WG last-call on protocol document
    Done  WG last-call on cryptographic locators, if required
    Done  WG last-call on multihoming triggers description
    Done  Submit document on cryptographic locators to the IESG, if required
    Done  Submit protocol document to the IESG
    Done  Submit draft on multihoming triggers description to the IESG
    Oct 2007  WG last-call on architectural document
    Oct 2007  WG last-call on applicability statement document
    Dec 2007  Submit completed architectural document to IESG
    Dec 2007  Submit applicability statement document to IESG

    Internet-Drafts:

    Socket Application Program Interface (API) for Multihoming Shim (85266 bytes)

    Request For Comments:

    Shim6: Level 3 Multihoming Shim Protocol for IPv6 (RFC 5533) (299931 bytes)
    Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming (RFC 5534) (88152 bytes)
    Hash-Based Addresses (HBA) (RFC 5535) (63994 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.