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

From: David Lamparter <[email-masked]>
Date: Sat, 23 Jun 2012 15:31:24 +0200

Hi,

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?

Cheers,

David

---

From: Acee Lindem <[email-masked]>
Date: Sat, 23 Jun 2012 13:17:40 -0400

David,
Nobody has ever suggested this - why do think it useful?
Thanks,
Acee 
On Jun 23, 2012, at 9:31 AM, David Lamparter wrote:

> <signature.asc>_______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Sat, 23 Jun 2012 13:24:20 -0400

David,
Nobody has ever suggested this - why do you think it useful?
Thanks,
Acee 

> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: David Lamparter <[email-masked]>
Date: Sat, 23 Jun 2012 23:00:34 +0200

> 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

---

From: Anton Smirnov <[email-masked]>
Date: Mon, 25 Jun 2012 11:48:36 +0200

Hi David,
    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.
    As for /32 mask on broadcast interface see 
draft-ietf-ospf-prefix-hiding-04.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Jun 2012 09:41:51 -0400

Hi Anton, David, 
I agree with Anton. One could possibly make it work for P2MP - however, this is more than simply an OSPF problem. 
Acee

---

From: David Lamparter <[email-masked]>
Date: Mon, 25 Jun 2012 18:02:45 +0200

Hi Acee & Anton,

[citation reordered]
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

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