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.