Subject: RE: RFC 1812 (IP Unnumbered)

From: vishwas <[email-masked]>
Date: Mon, 14 Dec 98 12:25:00 PST

> 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

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.

[vishu]

True,
OK now how shall applications over IP like DVMRP and PIM behave over   
these IP unnumbered interfaces...?

---

From: Art Berggreen <[email-masked]>
Date: Mon, 14 Dec 1998 08:24:15 -0800 (PST)

>knowledge of IP addresses only.

Actually RIP works just fine with unnumbered interfaces.  In essence, a
RIP update states "you can reach the following set of IP prefixes by
sending through me".  If you receive the update on a numbered interface,
you need to remember both the interface and the next-hop IP address. If
you receive it on an unnumbered interface, all you need to remember is
the interface.  In RIP-V1 it was common to use the subnet mask of numbered
interfaces to derive the subnet mask of other subnets of the same base
network.  With RIP-V2 the subnet mask is carried and proper support for
CIDR is available.

Art

---

From: vishwas <[email-masked]>
Date: Tue, 22 Dec 98 17:16:00 PST

Hi Alan,
 I am working on 2.0.0 Linux Kernel. Using routed (RIP v1) for routing.
It clearly sysy in the man page,
    "Hosts acting as internetwork routers gratuitously supply their   
routing
     tables every 30 seconds to all directly connected hosts and   
networks.
     The response is sent to the broadcast address on nets capable of   
that
     function, to the destination address on point-to-point links, and to   
the
     router's own address on other networks".

This implies that for RIP it should know the IP address of the other end   
of the router.
So I am unable to test IP unnumbered on CISCO - Linux

My set up,

              unnumbered               sl0
eth0---| CISCO |---------P2P------------| Linux |----eth0

So, I am not clear what exactly need to be done in IP and RIP to have   
route exchange without explicitly assigning an IP addres to P2P link on   
either side.

Thanks for ur time.

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 . . .

 -----Original Message-----
From: Fred Baker [SMTP:[email-masked]]
Sent: Thursday, December 10, 1998 9:55 PM
To: vishwas
Cc: [email-masked]'; [email-masked]'
Subject: Re: RFC 1812 (IP Unnumbered)

At 06:03 PM 12/10/98 -0800, vishwas wrote:
>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.

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.

With that basis, let's look at your question:
>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".

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.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 22 Dec 1998 09:09:58 -0700 (MST)

> From: vishwas <[email-masked]>
> To: "'Fred Baker'" <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         "'Alan Cox'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>

> ...

Both the 4.4BSD-Lite `routed` derived from Sam Leffler's early 1980's
original, and my rewrite of that code for RIPv2 & IRDP that is in FreeBSD,
NetBSD, OpenBSD, and elsewhere, handle unnumbered point to point (including
SLIP and PPP) links just fine.  Those words quoted above from a man page
are similar to the words in that rewrite, so perhaps Linux is using one
of those versions of `routed` or something related.  For 10 or 15 years,
I have personally known of many systems using unnumbered point-to-point
links with `routed`.

The BSD IP code requires that every network interface have an assigned IP
address for the local side of broadcast-capable interfaces and for the
remote or destination side of point-to-point links.  I think there are
reasons why that is an unfortunate design choice, but being unable to deal
with unnumbered point-to-point links is not one of those reasons, because
the BSD IP code and `routed` work just fine with unnumbered links.

As Fred Baker said, it is trivial to deal an unnumbered point-to-point
link in this scenario:

	       unnumbered               sl0
 eth0---| CISCO |---------P2P------------| BSD |----eth0

You simply tell the BSD kernel that the destination IP the point-to-point
link (IFF_POINTOPOINT bit set) is any of the IP addresses of the CISCO.
In this example, the Cisco must have at least one IP address, its eth0 IP
address.  `routed` will use the sioctl(2) to obtain that IP address, and
do the right thing.   I have not looked to see if Linux is the same, but
I suspect it is quite similar.

Vernon Schryver    [email-masked]