BSD & non-/32 prefixes on p2p linkes

[Ondrej Zajicek]

On Sat, Sep 21, 2013 at 11:45:08AM +0200, Ondrej Zajicek wrote:
> On Fri, Sep 20, 2013 at 09:09:32PM +0400, Alexander V. Chernikov wrote:
> > Hello list!
> >
> > Currently bird assumes (bsd sysdep) that any prefix on p2p link is /32.
> >
> > For example:
> >
> > bird: direct1 < primary address 10.0.0.3/31 on interface gif15 added
> > bird: Ignoring bogus prefix 10.0.0.3/31 received via direct1
> > bird: direct1 > invalid 10.0.0.3/31 dev gif15
> >
> > Can we do the same for IPv4 ?
> 
> That could be done, but i wonder why ever check for IF_MULTIACCESS, is
> that relevant for IPs on BSD? Does BSD support peer addresses on
> multiaccess interfaces?

I did some tests on FreeBSD and it seems that allowed address combinations
depend on IF_MULTIACCESS:


Multiaccess iface (e.g. ethernet):
 - behavior the same for IPv4 and IPv6
 - prefix and host addresses allowed, peer addresses forbidden

PtP iface (e.g. GRE tunnel), IPv4:
 - peer addresses allowed
 - prefix addresses allowed, but require dest_address
 - host addresses forbidden
 - note that you could set peer address with dest_address the same
   as local address, which could be interpreted as host address,
   but it is question whether it should be interpreted that or
   whether it is just an error.

PtP iface (e.g. GRE tunnel), IPv6:
 - prefix, host and peer addresses are allowed


(Prefix addresses are addresses with non-max prefix, peer addresses
are pairs of local/remote IPs (IA_PEER in BIRD), host addresses
are max-prefix addresses without remote ends (kind of loopback,
IA_HOST in BIRD.)

Not sure of other BSDs, newer FreeBSDs and whether all these allowed
combinations are intentional.

I guess that in a case where IPv4 prefix addresses are used on PtP
iface, we could more or less ignore value of dest_address (it would be
parsed as broadcast address, which may or may not be OK). And we
definitely would ignore the possibility that dest_address is outside the
(non-max) prefix.


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130921/03012867/attachment-0001.asc>