RFC relevance of solution

As per Relevance of the word solution, we have this rfc below:

Network Working Group R.
Request for Comments: 1955 Ipsilon Networks, Inc
Category: Informational June 1996

New Scheme for Internet Routing and Addressing (ENCAPS) for

Status of This

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list

This memo describes a proposal made to to the Routing and
group [ROAD] January 1992 by Robert Hinden. It was originally
as an email message. It proposes a medium term solution to
Internet's routing and addressing problems

I would like to propose a new scheme which I believe is a good
term solution to the routing and address problems of the internet
It has the following positive attributes

- No Changes to
- No Changes to Most
- No New Routing
- No New Internet
- No Translation of Addresses in
- Reduces the Routing Table Size in All
- Uses the Current Internet Address

It is not a solution good for all time, because it does impose
size limits and does not support new internet services such
guaranteed bandwidth, delay, etc. It does require border routers
do additional processing, but does not require any
translation. I believe that this scheme will give us enough time
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 (
on ADs), Martha Steenstrup (encapsulation), and probably steals
ideas put forward by Noel Chiappa, Van Jacobson , Ross Callon,
Oran, and everyone else in the ROAD group

I think that we (the ROAD group) agree that in the short term we
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
very large number of end points and routes, as well as support
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
can not figure out a long term solution before March. We do
that we should start working on a long term solution(s).

What this leaves is the need for a good medium term solution
can keep the Internet going until we can design and deploy a
term solution. The medium term solution wants to be the most "
effective". It should buy us the most time to develop a long
solution and do it with as little change to the existing Internet
possible

I propose this scheme as a new medium term solution

NEW

The basic idea is that inter-domain routing be done by routing
autonomous domains (AD). The key is how this is done. The
to do this is for the border routers to encapsulate the original
datagrams with another IP header. The source and
addresses in the new header (I will call it the AD-Header from
on) represent the source and destination ADs

When the first (entrance) border router receives a datagram from
host or router without an AD-Header it looks at the source
destination address and does a DNS lookup to get the addresses
the AD-Header. It then adds an AD-Header and forwards
encapsulated datagram to its proper destination AD

The border routers would compute AD routes by running a
protocol between themselves. BGP or even IS-IS or OSPF for
matter, would work fine. As you will see later, they might even
better

The addresses I propose to use for the AD addresses are plain old
addresses. A small number of Class A and Class B addresses would
reserved for this purpose. The network number of the address

Hinden Informational [Page 2]

RFC 1955 IP Encaps June 1996

indicate that it was an AD identifier. The local part of the
would indicate the actual AD. This would allow for many ADs to
supported. For example, 10 Class-A and 10 Class-B addresses
accommodate (10*2^24 + 10*2^16) 168,427,500 ADs. We clearly don'
need that many for a long time

The reason why I would chose to get more than one network number
use to represent the AD address is I would use them to organize
ADs. Let's call them commonwealths. Each commonwealth would
have to know the detail of it's own ADs

Next I would have the border routers inject these AD addresses
the Intra-AD routing of transit ADs. They would tell the
inside of the transit AD that they (the border routers) were
route to each appropriate AD network. Commonwealths that
multiple interconnects (probably the common case) could by the use
careful assignment of the AD addresses use subnetting to
reasonable routing between the commonwealths. This is where OSPF
IS-IS might be better than BGP. Also, IS-IS, with its ability
route on actual end points might be the best

The motivation behind injecting the AD addresses into the Intra-
routing of the transit ADs, is that the routers in these ADs
forward the AD-Headers without knowing that they are special.
the entrance and exit border routers are required to do
different

Finally when a AD-Header is received at the last (exit) border
it strips off the AD-Header and sends the datagram to the
destination

This scheme is based around the idea that IP addresses are
unique. I think that we will not actually run out of IP
for a long time and that we can live with the current
until we can deploy a long term solution

This scheme could be extended to not require globally unique
address. Effectively the combination of AD-Address and IP-Address
the globally unique address. To use this scheme without
unique IP-Addresses and without changing in the hosts would require
NAT mechanism in the border routers. I think it would be
to change the hosts to have them do the DNS query and add the AD
header. This could be the basis for the long term solution

Another interesting aspect of this scheme is that if we were to
the current architecture where one IP-Address is always in only
AD, to allow an IP-Address to be in more than one AD, it
provide a solution to the issue of allowing a IP entity to

Hinden Informational [Page 3]

RFC 1955 IP Encaps June 1996

service from more than one service provider

SUMMARY OF CHANGES

The DNS needs to be extended to add an AD-Address entry for
name. These will be used by the entry and exit border routers to
the AD-Addresses to use when building the AD-Headers

Border routers need to be extended to do the DNS lookup, perform AD
Header encapsulation, run an inter-AD routing algorithm using AD
Addresses, and be able to AD-Header de-encapsulation

I believe that this scheme has may advantages. These are

- Only border routers and the DNS need change. No changes
required in hosts or non-border routers

- No performance impact on datagram forwarding except at
and exit border routers

- Only a small impact on bandwidth utilization on
networks due the addition of a 20 byte IP header to
datagram

- Removes the Inter-AD routing from Intra-AD routing and as
result solves the routing load (table size and computation
problem for the foreseeable future

- The routing load on the border routers is manageable
border routers only need to know the detail of the
commonwealth they are a member of. Other commonwealths
as single addresses

- No requirement for new routing protocols to be designed
deployed

- No translation of packets from one address scheme to another

- Uses the current IP addressing structure

- It scales well even if there is on the order of one AD per
network, because the AD-Addresses can be assigned logically

Hinden Informational [Page 4]

RFC 1955 IP Encaps June 1996

It does have some disadvantages. These are (at least):

- It is not a long term solution in its initial form

- It assumes that the current IP-Addresses can remain
unique for a long time

[ROAD] Gross, P., and P. Almquist, "IESG Deliberations on
and Addressing", RFC 1380, ANS, Stanford University
November 1992.

SECURITY

Security issues are not discussed in this memo

AUTHOR'S

Robert M.
Ipsilon Networks, Inc
2191 East Bayshore
Suite 100
Palo Alto, CA 94303

EMail: hinden@ipsilon.
Phone: +1 (415) 846-4604

Hinden Informational [Page 5]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX