Skip to main content

Shim6: Level 3 Multihoming Shim Protocol for IPv6
draft-ietf-shim6-proto-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    shim6 mailing list <shim6@psg.com>, 
    shim6 chair <shim6-chairs@tools.ietf.org>
Subject: Protocol Action: 'Shim6: Level 3 Multihoming Shim 
         Protocol for IPv6' to Proposed Standard 

The IESG has approved the following document:

- 'Shim6: Level 3 Multihoming Shim Protocol for IPv6 '
   <draft-ietf-shim6-proto-12.txt> as a Proposed Standard

This document is the product of the Site Multihoming by IPv6 
Intermediation Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-12.txt

Ballot Text

Technical Summary
 
  This document defines the Shim6 protocol, a layer 3 shim for IPv6
  that provides locator agility below the transport protocols. Shim6
  provides IPv6 hosts in a multihomed site with failover and load
  sharing properties, without assuming that a multihomed site will
  have a provider independent IPv6 address prefix which is announced
  in the global IPv6 routing table.  Shim6-enabled hosts in a
  multihomed site will use the Shim6 protocol specified in this
  document to setup state with peer hosts, so that the state can
  later be used to failover to a different locator pair, should the
  original pair stop working, while preserving the integrity of
  active transport layer sessions.
 
Working Group Summary
 
   The document has extensively reviewed by the Working Group. The
   Working Group consensus was to recommend publication of this
   document as a Proposed Standard.
         
Document Quality

   Jari Arkko has reviewed this specification for the IESG.

   There are known implementations of this specification, and there
   have been no implementation experiences that have implied any
   further revision to this specification is required.

   Additional note:

   The document is being passed to the IESG as part of a set of three
   documents that the Working Group has determined by consensus in
   the WG Last Calls has requested to be published as Proposed
   Standards. The Document Shepherd is aware that there have been
   suggestions to publish initially as Experimental, and notes that
   the Working Group Last Call specifically noted the intended
   request to publish as a Proposed Standard, and this request is
   based on that Working Group consensus position.
         
   The specification meets all the criteria of section 4.1.1 of RFC
   2026, in that the specification is stable, has resolved design
   choices, is believed to be well understood and has received
   considerable community interest. The specification has no known
   technical omissions.
         
   In addition, there are a number of implementations of the
   specification, but little in the way of operational experience,
   interoperability between implementations and interaction with
   application behavior to report on at this stage.

Note to RFC Editor
 
  Please change in Section 17, IANA Considerations,
  by adding this line to the
  Shim6 Error Code registry table:

  |  5-19  |  Allocated using Standards action  |

  In Section 22.4, please insert two new paragraphs
  after the paragraph that starts with "Another 
  option":

   In general, SHIM6 was expected to work between pairs of hosts
   that have no prior arrangement, security association, or
   common trusted third party. And it was also seen as undesirable
   to have to turn on per-packet AH/ESP just for the multihoming
   to occur. However, Shim6 should work and  have an additional
   level of security where two hosts choose to use IPsec.

   Another design alternative would have employed some form 
   of opportunistic or Better-Than-Nothing-Security (BTNS)
   IPsec to perform these tasks with IPsec instead. 
   Essentially, HIP in opportunistic mode is very similar 
   to SHIM6, except that HIP uses IPsec, employs 
   per-packet ESP, and introduces another set of 
   identifiers.

RFC Editor Note