[radvd-devel-l] Wildcard Interface Addresses

Pekka Savola pekkas at netcore.fi
Mon Feb 11 09:49:09 EST 2008


On Mon, 11 Feb 2008, Norman Rasmussen wrote:
> If I manually configure radvd with the interface that I think pppd is going
> to assign, and send a SIGHUP on ipv6-up, then radvd reloads the config, and
> responds to the Vista RA solicitation fine.  The problem is that 'magic'
> interface address.
>
> Now obviously I could write something into ipv6-up that re-writes
> radvd.confbefore it SIGHUP's it, but each ppp interface looks the
> same:
>
> interface ppp3
> {
>        AdvSendAdvert on;
>        MaxRtrAdvInterval 300;
>        AdvDefaultLifetime 3000;
>        UnicastOnly on;
>        prefix fec0::/64
>        {
>        };
>        prefix 2001:0618:0400:6f39::/64
>        {
>                AdvPreferredLifetime 1200;
>        };
> };
>
> and I might have several clients, all with exactly the same config, so it
> would make sense to roll them all into one block.

(Regarding the comment on unicastOnly and timeouts, you may want to 
run tcpdump and capture icmp6 traffic to make sure the right kind of 
periodic RA traffic is being exchanged over the link.)

The thing that I didn't understand and I don't think you explained is 
how different clients, if they connect simultanously, are going to 
work if you advertise every one of them the same prefix?

I think you'll end up in a configuration where every client must have 
its own prefix making the feature request unnecessary; the advertised 
prefix could be dynamic (relatively easy if the ppp interfaced are 
created in sequential order) or static (probably more difficult unless 
pppd allows creating differently named interfaces for each of your 
users and/or have scripting that rewrites the radvd configuration 
based on AAA database information about prefixes).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



More information about the radvd-devel-l mailing list