Subject: RFC 1812 (IP Unnumbered)

From: vishwas <[email-masked]>
Date: Thu, 10 Dec 98 18:03:00 PST

Hi Fred,
 Cisco claims, "You can use the IP unnumbered feature even if the system   
on the other end of the asynchronous link does not support it. The IP   
unnumbered feature is transparent to the other end of the link because   
each system bases its routing activities on information in the routing   
updates it receives and its own interface address".

But RFC 1812 section 2.2.7 says, "An Unnumbered P2P link doesent have any   
network prefix associated with it. As a consequence, the n/w interfaces   
connected to an unnumbered P2P link do not have IP addresses".

Now my question is "If one side doesent have an IP address and One side   
does (As per CISCO), how to treat the that network, when one say I have   
an IP address and CISCO says Boss I dont have an IP address.

First of all my BASIC DOUGHT IS, When U configure a P2P link in a UNIX   
Platform, U SHOULD know who is ur PEER router. But CISCO says I cant give   
U an IP address because I have configured IP unnumbered, How to solve   
this PROBLEM.

Regards
Vishwanath S. Edavayyanamath
 --------------------------------------------------------------------------  
 ------------------------
Software Engineer, Future Software Pvt. Ltd, Chennai, India
Ph : +91-44-4330550 (335)
   _
  / /   (_)__  __ ____  __
 / /__/ / _ \/ // /\ \/ /  . . .  t h e   c h o i c e   o f   a
/____/_/_//_/\_,_/ /_/\_\              G N U   g e n e r a t i o n . . .

---

From: [email-masked] (Alan Cox)
Date: Thu, 10 Dec 1998 14:45:59 +0000 (GMT)

> an IP address and CISCO says Boss I dont have an IP address.

Its not a network. Conceptually the unnumbered link isnt there, its all
part of the same host.

> U an IP address because I have configured IP unnumbered, How to solve   

What problem. On Linux you set your address to be your lan side address
or any other public address your host has, and you add a route of

route add default dev ppp0

Alan

---

From: Andy Poling <[email-masked]>
Date: Thu, 10 Dec 1998 09:29:51 -0500 (EST)

> Its not a network. Conceptually the unnumbered link isnt there, its all

Or, to put it another way, we don't need to refer to it by an IP address for
routing purposes because we can use it's device name instead.

> route add default dev ppp0

In other words, you route whatever is on the other side of the link by
specifying to route it to the device for the interface, rather than
specifying to route it to the IP address of the interface.

How you determine what is on the other side is another story (and perhaps
that is vishwas's real question), but hopefully you have some idea.

This would work, I suspect, much better with static routes than with
something like RIP.  In fact, I think most RIP daemons are constrained to
knowledge of IP addresses only.

Note that RFC1812 admits that every router must have at least one IP
address.  As long as you first route that IP address via the device for your
PPP link (e.g. "route add rou.ter.ip.addr dev ppp9") you can then route
things to that router normally using it's single IP address.

-Andy

PS - Sorry Alan - I just thought you were a little too cryptic.  :-)

Global Auctions
http://www.globalauctions.com

---

From: Fred Baker <[email-masked]>
Date: Thu, 10 Dec 1998 08:24:39 -0800

>an IP address and CISCO says Boss I dont have an IP address.

Someone else commented that an unnumbered interface is, conceptually, an
interior interface in a distributed router. This is literally the model
implemented in AppleTalk - "Inside AppleTalk" describes it in so many
words, referring to the neighboring devices as "half routers" - and is to
be found in many papers and monographs on the subject over the past 30
years. AppleTalk, and other protocols, that use the half-router model use a
special source address on the wire which means "no address".

In the IP realm, we have no such "no" address. While this is useful input,
I think the more relevant conceptual basis is in OSPF, where unnumbered
interfaces were first directly supported and made relevant to IP. In OSPF,
the routers are still separate full-fledged routers, but there are two
sorts of interface, one which has an address which is one among a set of
addresses reachable from the interface, and on which has no unique address.
Each OSPF router advertises that it has point to point connectivity to some
number of other routers, identified by IP addresses
*or*interface*relationships*. In other words, I can identify a neighbor as
"the system whose messages, when I receive them, have this IP address" or
as "the system at the other end of this point to point link." When OSPF
builds its router lattice, then, it does so based on Router ID (which bears
an uncanny but unnecessary resemblance to an IP4 address), and connects
between those routers by considering how each system gets to its neighbors.

One might ask, then, what IP address gets placed into the destination
address of the messages OSPF exchanges on that unnumbered link. There are
two obvious alternatives - it could send it to "all OSPF routers" (e.g.,
"you, whoever you are") or it could send it to whatever address the system
over there appears to be using. Similarly, one might ask what IP address
the system places into the source address of IP messages containing OSPF
information. The answer is, of course, that it selects an address from the
set of IP addresses assigned to other interfaces on the same system. Any
system must have at least one numbered interface - even if it is a loopback
interface - just so you can talk with it.

On issue, at least at the time OSPF was developed, was the question of how
an application (OSPF) sitting on top of an operating system interface was
going to tell IP to place a message on a given interface. For embedded
systems, where the vendor controls those APIs, sprouting an interface
directive API is not difficult. But doing so on a standard operating system
whose APIs were defined by someone who potentially didn't care about OSPF's
ideas was more of an issue. OSPF made a pragmatic decision. The source
address is straightforward - by whatever means, choose among the available
IP addresses and use that one consistently. It is also straightforward to
observe what address a system on an interface is using. So place a static
route into the route table that associates that single destination address
with that interface, and from there use existing interfaces.

Having done that, there is suddenly no constraint on the IP address that a
neighboring system might use. Consider the following case:

	+-------+		+-------+
	|	|		|	|
	|   A   +------/--------|   B	|
	|	|		|	|
	+---+---+		+---+---+
	    | .1		    | .2
	/---+-----------------------+---/
		   10.1.1.0/24

Routers A and B peer across a LAN, and share an unnumbered link. Looking at
it from A's perspective, A uses the address 10.1.1.1 on the LAN, and peers
from a routing perspective with 10.1.1.2 - and connects with some number of
hosts on that transit network as well. It also has this unnumbered
interface, and the system at the far end of it is using the IP Address
10.1.1.2. So OSPF uses its "longest match" logic to distinguish between the
interface route 10.1.1/24 and a static route 10.1.1.2/32, associated with
different interfaces. This causes some interesting anomalies (unicast and
multicast messages from A to B relating to the LAN take different paths).
But it doesn't break.

>connected to an unnumbered P2P link do not have IP addresses".

Let's insert the understood word "permanent" into the sentence from 2.2.7.
On the LAN interface, the fact that 10.1.1.1 can talk to 10.1.1.2 via the
LAN derives from configuration - there is a subnet which has a network
prefix 10.1.1.0/24, and 10.1.1.2 is one of many systems in that set. But
the address used on the unnumbered interface is not a creature of
configuration, it is an observation. If the neighbor changes the address it
is using, the OSPF adjacency will fail (because one of OSPF's message
receipt edits will fail), and then come back up. In that process, the
observation will change, and we're on our way.

Suppose, then, that B doesn't support unnumbered interfaces. It requires
the p-p link to be numbered, and therefore constrains the IP address that A
uses to be in the subnet assigned to B's end of the p-p link. One way to do
that is

	+-------+		+-------+
	|	|   10.1.1.49/30|	|
	|   A   +------/--------|   B	|
	|	|		|	|
	+---+---+		+---+---+
	    | .50		    | .2
	/---+-----------------------+---/
		   10.1.1.0/24

Presumably, if A uses the source address from the LAN on the p-p interface,
B will recognize it as being within the relevant network prefix, and an
unnumbered system (A) can talk with a numbered system (B). So in this
model, both statements are simultaneously true. One cannot randomly throw
systems together that achieve the result, but the result can be engineered.
It is easier to engineer in more interesting cases like:

	+-------+		+-------+
	|	|   10.1.1.49/30|	|
	|   A   +------/--------|   B	|
	|	|		|	|
	+---+---+		+---+---+
	    | 10.1.1.50/24	    | 10.1.2.1/24
	/---+---/		/---+---/

Basically, in this picture, B thinks of A as exporting an 255.255.255.252
address prefix on the line from a larger subnet beyond it. A makes no such
assumption - it simply thinks it is using its LAN address on the line. We
now have a system engineering issue. The addresses 10.1.1.48 and 10.1.1.51
are ambiguous. If they are assigned to hosts that neighbor with A, messages
to those hosts that pass through B will be dropped as letter-bombs. So as a
system engineering issue, the administrator of the LAN 10.1.1.50/24 should
not use those addresses. Assuming that is done, the picture works.

Both statements are consistent with the architecture. It requires the
implementation of variable length prefixes, and some careful engineering.
But it does in fact work.