New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
RFC 1955
|
Document |
Type |
|
RFC - Informational
(June 1996; No errata)
|
|
Author |
|
Bob Hinden
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1955 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Hinden
Request for Comments: 1955 Ipsilon Networks, Inc.
Category: Informational June 1996
New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet@munnari.oz.au mailing list.
This memo describes a proposal made to to the Routing and Addressing
group [ROAD] January 1992 by Robert Hinden. It was originally sent
as an email message. It proposes a medium term solution to the
Internet's routing and addressing problems.
INTRODUCTION
I would like to propose a new scheme which I believe is a good medium
term solution to the routing and address problems of the internet.
It has the following positive attributes:
- No Changes to Hosts
- No Changes to Most Routers
- No New Routing Protocols
- No New Internet Protocols
- No Translation of Addresses in Packets
- Reduces the Routing Table Size in All Routers
- Uses the Current Internet Address Structure
It is not a solution good for all time, because it does impose some
size limits and does not support new internet services such as
guaranteed bandwidth, delay, etc. It does require border routers to
do additional processing, but does not require any packet
translation. I believe that this scheme will give us enough time to
put into place a long term solution (i.e. pick one or more of CLNP,
*NAT, IDPR, IDRP, Nimrod, Unified, NewIP, etc.)
Hinden Informational [Page 1]
RFC 1955 IP Encaps June 1996
This scheme is based on the ideas presented by Deborah Estrin (route
on ADs), Martha Steenstrup (encapsulation), and probably steals from
ideas put forward by Noel Chiappa, Van Jacobson , Ross Callon, Dave
Oran, and everyone else in the ROAD group.
CONTEXT
I think that we (the ROAD group) agree that in the short term we need
to make better use of the IP address space. I think we also (mostly)
agree that in the long term we need a solution that can deal with a
very large number of end points and routes, as well as support new
services such as guarantees of service, source selected routes, etc.
We do not agree on any of the details of this but do agree that we
can not figure out a long term solution before March. We do agree
that we should start working on a long term solution(s).
What this leaves is the need for a good medium term solution which
can keep the Internet going until we can design and deploy a long
term solution. The medium term solution wants to be the most "cost
effective". It should buy us the most time to develop a long term
solution and do it with as little change to the existing Internet as
possible.
I propose this scheme as a new medium term solution.
NEW SCHEME
The basic idea is that inter-domain routing be done by routing on
autonomous domains (AD). The key is how this is done. The mechanism
to do this is for the border routers to encapsulate the original IP
datagrams with another IP header. The source and destination
addresses in the new header (I will call it the AD-Header from here
on) represent the source and destination ADs.
When the first (entrance) border router receives a datagram from a
host or router without an AD-Header it looks at the source and
destination address and does a DNS lookup to get the addresses for
the AD-Header. It then adds an AD-Header and forwards the
encapsulated datagram to its proper destination AD.
The border routers would compute AD routes by running a routing
protocol between themselves. BGP or even IS-IS or OSPF for that
matter, would work fine. As you will see later, they might even be
better.
The addresses I propose to use for the AD addresses are plain old IP
addresses. A small number of Class A and Class B addresses would be
reserved for this purpose. The network number of the address would
Hinden Informational [Page 2]
RFC 1955 IP Encaps June 1996
indicate that it was an AD identifier. The local part of the address
would indicate the actual AD. This would allow for many ADs to be
supported. For example, 10 Class-A and 10 Class-B addresses could
accommodate (10*2^24 + 10*2^16) 168,427,500 ADs. We clearly don't
need that many for a long time.
Show full document text