Multihoming L3 Shim Approach
draft-ietf-shim6-l3shim-00
| Document | Type |
Expired Internet-Draft
(shim6 WG)
Expired & archived
|
|
|---|---|---|---|
| Authors | Erik Nordmark , Marcelo Bagnulo | ||
| Last updated | 2005-07-12 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document specifies a particular approach to IPv6 multihoming. The approach is based on using a multihoming shim placed between the IP endpoint sublayer and the IP routing sublayer, and, at least initially, using routable IP locators as the identifiers visible above the shim layer. The approach does not introduce a "stack name" type of identifier, instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address. This document does not specify the mechanism for authenticating and authorizing the "rehoming" - this is specified in the HBA document. Nor does it specify the messages used to establish multihoming state. The document does not even specify the packet format used for the data packets. Instead it discusses the issue of receive side demultiplexing and the different tradeoffs. The resolution of this issue will affect the packet format for the data packets.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)