Redundant Address Deletion when Encapsulating IPv6 in IPv6
draft-deering-ipv6-encap-addr-deletion-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Dr. Steve E. Deering , Brian Zill | ||
Last updated | 2001-11-20 | ||
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
In some potentially common uses of IPv6-in-IPv6 encapsulation ('tunneling'), a node that is performing an encapsulation or decapsulation will also be the source or destination of the packet being encapsulated. That can result in the same IPv6 address appearing in both the outer (encapsulating) and inner (encapsulated) IPv6 headers. This document specifies a method for deleting such redundant addresses from an inner header when performing an encapsulation, and restoring those addresses when decapsulating, resulting in a 16-octet (128-bit) reduction in header overhead, per address deleted.
Authors
Dr. Steve E. Deering
Brian Zill
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)