According to Ignatios Souvatzis:
> 
> IP version 4 point to point links, be it PPP or SLIP, be it 4.3BSD or 4.4BSD
> derived systems, semantically do not create a network of their own.
> 
Accepted, although, for example, my Novell MPR (which is admittedly 
pretty ancient, but seems built to the most rigid standards) expects 
the ppp link to be its own subnet - doesn't do unnumbered or any 
approximations thereto.

> The kernel routes by looking wether the single remote address matches, when
> it finds an interface with the POINTTOPOINT bit on.
> 
Does a point-to-point link get treated exceptionally, in this respect, 
or is this merely a generalisation of existing kernel semantics?

> This is 99% of a real unnumbered interface: you can share the IP address of
> your Ethernet as your local address.
> 
That really appealed to me, but then it is not clear from the 
documentation that I need to specify a 255.255.255.255 mask because 
otherwise pppd adopts not only the Ethernet address, but also the 
netmask (I'll SEND-PR that, if I can find a way to fix it).

> I dont know exactly what happens when you ifconfig (or the ioctl pppd does)
> a POINTTOPOINT interface to a non-FFFFFFFF netmask. Apparently, it creates
> a routing table entry with that netmask, which lateron causes trouble. I've
> witnessed this all the time since I took over the PPP FAQ. Just dont do it.
> 
Happens by itself, no cooperation from me :-)  And it does break, as 
you suggest, and it shouldn't be done.  But it is probably OK for 
numbered point-to-point links.  I do use it in Cape Town, with slightly 
odd results:

ppp0  1500  <Link>                             56200     3    65443     0     0
ppp0  1500  196.28.218.13 196.28.218.139       56200     3    65443     0     0
ppp1  576   <Link>                             17343     4    16152     0     0
ppp1  576   196.28.218.88 196.28.218.90        17343     4    16152     0     0

where 

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 196.28.218.139 --> 196.2.62.101 netmask 0xfffffffc 
ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 576
        inet 196.28.218.90 --> 196.28.218.89 netmask 0xfffffffc 

both interfaces are intended to have their own subnet, I'm not sure 
when the first one relinquished the 196.2.62.102 in favour of 
196.28.218.139 within 196.28.218.136 (!?)).  Here, the netmask is 
explicitly set and the default result is positively evil (.139 is the 
broadcast in .136/30)

Also, there's no guarantee that pppd will choose the "right" Ethernet 
interface.  We may be lucky in Cape Town that it wasn't ne1 or ne2 it 
chose as its number, after being told (Ha!  I think our ISP has changed 
parameters) to use its own.

In fact, in the first instance, we do not specify or request the IP 
numbers for the subnet, our ISP presumably specifies their end, whereas 
in the past it specified both ends.

> Regards,
> 	Ignatios

Instructive, indeed, but there are definitely defects that could be 
eliminated for the sake of the principle of least surprise.

Also, while I'm asking, I did ask once how to make sure that ppp0 was 
associated with a particular tty and ppp1 with another, and suggestions 
were made that I distractedly lost.  Is there an archive I can seek 
these responses, or does someone have a simple answer to this?

++L