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 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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
