IPv6 broken on Fedora 20?

Hannes Frederic Sowa hannes at stressinduktion.org
Thu Dec 19 18:28:24 CET 2013


On Fri, Dec 20, 2013 at 01:47:44AM +0900, Lorenzo Colitti wrote:
> On Fri, Dec 20, 2013 at 1:34 AM, Hannes Frederic Sowa <
> hannes at stressinduktion.org> wrote:
> 
> > > > NM has a user-space RA listener.
> > > >
> > >
> > > Sigh. Why do we keep reinventing the wheel? What was wrong with the
> > > in-kernel RA implementation?
> >
> > I wondered myself and got this response:
> > http://www.spinics.net/lists/netdev/msg255581.html
> 
> 
> Hmm. It looks like the answer is:
> 
> 1. "We want to be able to send RS whenever we feel like it." They could
> have used disable_ipv6 for that, or they could have made a write to
> accept_ra cause an RS to be sent out. Failing that, an RS is not hard to
> generate - it's a multicast packet with no information in it.
> 
> 2. "The kernel doesn't give us enough information to parse RDNSS and DNSSL
> options correctly". Fair enough, though this still could have been fixed in
> the kernel.

I think this is already fixed.

> 3. The kernel doesn't give userspace any say in the process. If the sysctls
> are on, it does what the RA tells it to, and if they're off, then userspace
> doesn't see any of the advertisements. This is a better reason than the
> ones above. I was looking into fixing this using multiple routing tables.

What is your idea?

Semantics of multiple routing tables are already very complex. Think e.g.
about doing L=0 announcements and getting back redirects from a router. Which
routing table should we apply this update on? Hold state in the stack on
pings? Or just update all routing tables with new on-link information?

Same for UDP pmtu discovery.



More information about the ipv6-ops mailing list