FreeBSD 8 as an IPv6 router

Hiroki Sato hrs at FreeBSD.org
Wed Dec 14 00:42:25 UTC 2011


Mattia Rossi <mrossi at swin.edu.au> wrote
  in <4EE7CDBE.1090605 at swin.edu.au>:

mr> Ok, this is something I always get a bit confused with. I understand
mr> that it's the right clean thing to set up a /64 on the interface which
mr> sends router advertisements, but I also would expect by nature, that
mr> whatever prefixlength you chose on the interface, rtadvd would simply
mr> grab the lowest /64 prefix out of the configured one to send router
mr> advertisements out.
mr>
mr> The idea there is, that you might use this router for multiple
mr> subnets, and have a single default route.
mr>
mr> Now of course to do that you'd need to configure rtadvd.conf, so I
mr> guess the whole thing missing here is a bit of documentation which
mr> says, that if you don't configure rtadvd via rtadvd.conf you're not
mr> allowed to be lazy and configure any prefix on the interface and
mr> expect rtadvd to do the right thing.
mr>
mr> It seems to me, that a lot of people (including me) would expect that,
mr> so maybe some info about that wouldn't be to bad.

 I do not think it is a good idea that the rtadvd daemon automatically
 splits prefixes shorter than 64 to ones with just 64.  "Which prefix
 should be advertised" is one of things which a sysadmin must specify
 explicitly when it receives prefixes shorter than 64 via IA-PD or
 something, and it should match the actual subnet structure.  A simple
 way to do so is to assign an address onto eth0, in his example, with
 desired /64 subnet prefix from the delegated (shorter) prefix, and
 run rtadvd with no configuration file.  This is the expected
 scenario.  A /60 address assigned on eth0 does not work as a default
 router address for multiple /64 subnets anyway...

 This trouble is caused by misconfiguration of sla-len and non-/64
 prefix is assigned unexpectedly to eth0.  If all of the configuration
 were correct rtadvd.conf was not needed in the first place, and even
 if split /64 prefixes were automatically advertised by rtadvd at that
 time the situation would not got better.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20111214/72fe1d89/attachment.pgp


More information about the freebsd-net mailing list