Browse Prior Art Database

Minimal Encapsulation within IP (RFC2004)

IP.com Disclosure Number: IPCOM000002558D
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 5 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Perkins: AUTHOR

Abstract

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may be serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 26% of the total text.

Network Working Group C. Perkins

Request for Comments: 2004 IBM

Category: Standards Track October 1996

Minimal Encapsulation within IP

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document specifies a method by which an IP datagram may be

encapsulated (carried as payload) within an IP datagram, with less

overhead than "conventional" IP encapsulation that adds a second IP

header to each encapsulated datagram. Encapsulation is suggested as

a means to alter the normal IP routing for datagrams, by delivering

them to an intermediate destination that would otherwise not be

selected by the (network part of the) IP Destination Address field in

the original IP header. Encapsulation may be serve a variety of

purposes, such as delivery of a datagram to a mobile node using

Mobile IP.

1. Introduction

This document specifies a method by which an IP datagram may be

encapsulated (carried as payload) within an IP datagram, with less

overhead than "conventional" IP encapsulation [4] that adds a second

IP header to each encapsulated datagram. Encapsulation is suggested

as a means to alter the normal IP routing for datagrams, by

delivering them to an intermediate destination that would otherwise

not be selected by the (network part of the) IP Destination Address

field in the original IP header. The process of encapsulation and

decapsulation of a datagram is frequently referred to as "tunneling"

the datagram, and the encapsulator and decapsulator are then

considered to be the the "endpoints" of the tunnel; the encapsulator

node is refered to as the "entry point" of the tunnel, and the

decapsulator node is refered to as the "exit point" of the tunnel.

2. Motivation

The Mobile IP working group has specified the use of encapsulation as

a way to deliver packets from a mobile node's "home network" to an

agent that can deliver datagrams locally by conventional means to the

mobile node at its current location away from home [5]. The use of

encapsulation may also be indicated whenever the source (or an

intermediate router) of an IP datagram must influence the route by

which a datagram is to be delivered to its ultimate destination.

Other possible applications of encapsulation include multicasting,

preferential billing, choice of routes with selected security

attributes, and general policy routing.

See [4] for a discussion concerning the advantages of encapsulation

versus use of the IP loose source routing option. Using IP headers

to encapsul...