Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Aug 2014 17:29:53 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        fernando@gont.com.ar
Cc:        freebsd-net@freebsd.org
Subject:   Re: Routing IPv6 packets towards oneself with routing sockets?
Message-ID:  <20140819.172953.436878206817123055.hrs@allbsd.org>
In-Reply-To: <53E5B71D.2030500@gont.com.ar>
References:  <53E35DA7.4020800@gont.com.ar> <20140808.053757.1725805140861121363.hrs@allbsd.org> <53E5B71D.2030500@gont.com.ar>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Aug_19_17_29_53_2014_045)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Fernando Gont <fernando@gont.com.ar> wrote
  in <53E5B71D.2030500@gont.com.ar>:

fe> >  Although your code assumes RTA_GATEWAY eventually returns the
fe> >  outgoing interface, it is not always true.  RTA_IFP should be used if
fe> >  you want to look up it instead of looking up gateways until AF_LINK
fe> >  is obtained.  Certainly RTA_GATEWAY returns AF_LINK and you can check
fe> >  sdl_index in it, but the index number is not always the same as the
fe> >  actual outgoing interface (one of the examples is a host route).
fe>
fe> Just curious: what's the meaning of the AF_LINK I was reading?

 Sorry for the delay.  AF_LINK with (sdl_nlen == sdl_alen == sdl_slen
 == 0) in RTA_GATEWAY was used to create a clone route.  Let's
 consider a situation that there are a IPv4 node (node A) with
 192.168.0.1/24 on its em0 and another node (node B) with
 192.168.0.2/24 on the same link.  If node A is running FreeBSD 8.0 or
 later, an output of "netstat -nrf inet" on node A will be something
 like this:

  Destination        Gateway            Flags    Netif Expire
  192.168.0.0/24     link#2             U        em0
  192.168.0.1        link#2             UHS      lo0

 but it was the following on an older FreeBSD (and other
 4.3BSD-derived implementations to which UNPv1 refers):

  Destination        Gateway            Flags    Refs  Use  Netif Expire
  192.168.0.0/24     link#2             UC          2    0  em0
  192.168.0.1        xx:xx:xx:xx:xx:xx  UHLW        0    0  lo0
  192.168.0.2        yy:yy:yy:yy:yy:yy  UHLW        0    0  em0

 A primary difference is that FreeBSD 8.0 and later do not directly
 have L2 address information in the routing table.  Instead, FreeBSD
 now has L2 address translation table and routing table separately.

 In the old routing table, a host route on the same net
 (e.g. 192.168.0.2) was dynamically created and its MAC address was
 added to the routing table by issuing ARP request.  More
 specifically, when node A attempts to look up a route for
 192.168.0.3, for example, an AF_LINK route with empty L2 address in
 RTA_GATEWAY matches first via the entry 192.168.0.0/24 bacause it is
 the most specific at the moment.  Then the sdl_index in RTA_GATEWAY
 is used for ARP request, and a host route is added eventually.  NDP
 works in the same way for IPv6.

 In the new implementation, a route with empty L2 address means which
 L2 address table (separated in per-interface and per-AF basis) should
 be referred.  A host route is usually used only as loopback route,
 and in its RTA_GATEWAY it just has empty L2 address with if_index
 where the address is configured.

 So, in both cases checking AF_LINK in RTA_GATEWAY is not reliable to
 know the actual outgoing interface.

-- Hiroki

----Security_Multipart(Tue_Aug_19_17_29_53_2014_045)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEABECAAYFAlPzCwEACgkQTyzT2CeTzy0C/QCgwWZlA00Lk0fpCM71/VQeAOTI
u1AAn0+QX3gF02MkgnhMfX0+xzTFhVPM
=VxPV
-----END PGP SIGNATURE-----

----Security_Multipart(Tue_Aug_19_17_29_53_2014_045)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140819.172953.436878206817123055.hrs>