[radvd-devel-l] Wildcard Interface Addresses

[Norman Rasmussen]

On Feb 11, 2008 3:22 PM, Pekka Savola <pekkas at netcore.fi> wrote:

> On Mon, 11 Feb 2008, Norman Rasmussen wrote:
> > This says that Vista expects unsolicited RA's over it's ppp link:
> >
> http://blogs.technet.com/rrasblog/archive/2006/12/15/vista-how-pppv6-support-works.aspx
>
> I don't see the word "unsolicited" in this article.  As a matter of
> fact, to the countrary -- in 4) and 5) it says that Vista will send a
> Router Solicitation, and the router will respond with an RA (i.e., a
> solicited advertisement).  So "UnicastOnly" should work OK with Vista
> as well.
>

My mistake, I now have UnicastOnly enabled.  I have to send a SIGHUP to
radvd in ipv6-up otherwise it doesn't detect the new interface quick enough
for Vista to send it's 2 solicitations before giving up.


> AFAIR, radvd will not re-advertise the RA, however, so Vista might
> forget the prefix/route information transmitted in the original RA
> after a while if it doesn't re-send the RS.
>
> So, while UnicastOnly should work at least initially, there might be
> problems after the RA's lifetimes expire.
>

Untested, we will see.  I have openswan problems that cause the tunnel to
collapse after 60 minutes, so I doubt that will be an issue for now.


> On the other hand, you could just try adding BROADCAST and MULTICAST
> flags on the interface and see if it works, or alternatively just
> ignore radvd's warning about possibly needing UnicastOnly (if it's
> working fine).


I was getting two syslog lines every 10 seconds :-)


> > I was advertising fe80::/64 and 2001:618:400:6f39::/64. radvd wasn't
> > transmitting the RA unless I disabled UnicastOnly, then the new 1.1version
> > complains when I enabled it, and the interface doesn't support
> broadcast.  I
> > need a unsolicited unicast option :-)
>
> I'd remove fe80::/64 because it's ignored on the recipient side
> anyway.  But it's probably not causing problems.
>

blegh, fec0::/64


> Are you saying that with 1.0 there is no complaint but with 1.1 there
> is?  I don't think there were code changes here, so if you think this
> is the case, I'd like to see some debug log (e.g., radvd with
> arguments like '-d 5 -m stderr')
>

1.0 wasn't complaining that ppp3 couldn't support broadcast, 1.1 is
complaing (for good reason)

The status at the moment is:

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.

-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.litech.org/pipermail/radvd-devel-l/attachments/20080211/bb43d325/attachment.htm