Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing

[David Lamparter <[e-mail]>]

Hi Acee & Anton,


[citation reordered]
> On Jun 25, 2012, at 5:48 AM, Anton Smirnov wrote:
> >    problem of unnumbered IP on broadcast interfaces has little to do 
> > with OSPF. There are certain checks and assumptions built into IPv4 
> > architecture which prevent this (say, how ARP requests are accepted and 
> > validated; check concept of proxy ARP). So before you solve this problem 
> > in OSPF you should be messing with IPv4 basics and legacies of earlier 
> > days. At this point in time this is not interesting.
On Mon, Jun 25, 2012 at 09:41:51AM -0400, Acee Lindem wrote:
> I agree with Anton. One could possibly make it work for P2MP -
> however, this is more than simply an OSPF problem. 

I agree that the behaviour on the ARP level may need proper specification, but
the desired behaviour is the very default behaviour on Linux.  I therefore
would disagree on dismissing this as not interesting.

Also, note that RFC 5309 already places most of the relevant
requirements in section 4.3 and 4.4.  Indeed I'm proposing something as
simple as the extension of RFC 5309 to networks with more than 2
routers, in either broadcast, nbma, or the new hybrid mode.
(p2mp could arguably be done as-is with creative interpretation of RFC 5309)

A considerable pool of knowledge regarding this topic exists at the
various MANET mesh routing workgroups; I would not consider the basic
IPv4 and ARP architecture a major obstacle, maybe not even a minor one.


Sample unnumbered Ethernet Linux session: (note: no kernel patches have
been applied, no knobs have been tuned)

tmp0 # ip link set eth0 up
tmp0 # ip addr add 10.0.0.1/32 dev eth0
tmp0 # ip addr list eth0
97: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether ba:6a:90:38:5d:16 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/32 scope global eth0
tmp0 # ip route add 192.168.23.45 dev eth0
tmp0 # ip route list
192.168.23.45 dev eth0  scope link
tmp0 # tcpdump -es 0 -nvvli eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:36:33.379242 de:82:f4:80:e1:f9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 192.168.23.45, length 28
17:36:33.379288 ba:6a:90:38:5d:16 > de:82:f4:80:e1:f9, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.1 is-at ba:6a:90:38:5d:16, length 28
17:36:33.379301 de:82:f4:80:e1:f9 > ba:6a:90:38:5d:16, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.23.45 > 10.0.0.1: ICMP echo request, id 52688, seq 1, length 64
17:36:33.379365 ba:6a:90:38:5d:16 > de:82:f4:80:e1:f9, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 54708, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.23.45: ICMP echo reply, id 52688, seq 1, length 64
[...]

tmp1 # ip link set eth0 up
tmp1 # ip addr add 192.168.23.45/32 dev eth0
tmp1 # ip route add 10.0.0.1 dev eth0
tmp1 # ping -c 2 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_req=1 ttl=64 time=0.194 ms
64 bytes from 10.0.0.1: icmp_req=2 ttl=64 time=0.100 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.100/0.147/0.194/0.047 ms
tmp1 # ip neigh list
10.0.0.1 dev eth0 lladdr ba:6a:90:38:5d:16 REACHABLE

> >    As for /32 mask on broadcast interface see 
> > draft-ietf-ospf-prefix-hiding-04.

Hm, this is only remotely related, though it may make things more
complicated with this special treatment of /32 masks on network LSAs.


-David

> On 06/23/2012 11:00 PM, David Lamparter wrote:
> >> On Sat, Jun 23, 2012 at 01:17:40PM -0400, Acee Lindem wrote:
> >>> Nobody has ever suggested this - why do think it useful?
> >> 
> >> Oops - context:  Unnumbered operation on broadcast media, and on that
> >> principle reduction of both IPv4 address consumption and configuration
> >> complexity.
> >> 
> >> -David
> >> 
> >> 
> >>> On Jun 23, 2012, at 9:31 AM, David Lamparter wrote:
> >>>> out of a rather funny misunderstanding of RFC 5309, I've ended up with
> >>>> half an implementation of OSPF running in ignorance of the IP subnet
> >>>> mask on a broadcast network.  After cleaning up the misunderstanding and
> >>>> taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which
> >>>> I expected to contain a note about this, but no such thing.
> >>>> 
> >>>> The general idea would be to operate a broadcast medium with a /32
> >>>> subnet mask, possibly unnumbered, and allowing adjacencies with just
> >>>> about anything that sends a Hello (and passes auth).
> >>>> 
> >>>> The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P
> >>>> (the last would amount to RFC 5309 with the detail that the peer address
> >>>> is not known up front.)
> >>>> 
> >>>> (For OSPFv3, this is obviously not interesting since with link-local
> >>>> addresses, there is no notion of similar same-subnet restrictions.)
> >>>> 
> >>>> I haven't found anything on this - is this mode of operation already
> >>>> described somewhere?