On Demand Tunneling For Multihoming
draft-van-beijnum-multi6-odt-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Iljitsch van Beijnum | ||
| Last updated | 2004-01-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| 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 describes a protocol to negotiate and subsequently use tunnels on demand, and the use of such tunnels to achieve scalable multihoming. The tunnels may run over either IPv4 or IPv6 transport, and the payload may consist of any upper layer protocol that can be used with IPv4 or IPv6. Tunnels are defined end-to-end, which means that a single outer or 'locator' address pair maps to a single inner or 'identifier' address pair. In order to avoid unnecessary overhead, tunneled packets (in the absence of option headers) only carry an outer header, an upper layer header and payload data. There is no inner header containing the original addresses; this information is reconstituted from the state associated with the tunnel where required. Additional mechanisms are used to provide basic security for the mapping between inner and outer addresses and to avoid unnecessary overhead and delays for short-lived sessions, and to facilitate rehoming in the event of a reachability problem. This document is a first draft, and as such doesn't contain a full protocol specification as higher-level changes are expected.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)