Date:	Wed, 9 Jan 2008 21:26:53 +0100
From:	Karsten Keil <kkeil@...e.de>
To:	netdev@...r.kernel.org
Subject: Re: Linux IPv6 DAD not full conform to RFC 4862 ?

On Wed, Jan 09, 2008 at 11:17:48AM -0500, Neil Horman wrote:
> On Wed, Jan 09, 2008 at 04:36:56PM +0100, Karsten Keil wrote:
> > Hi,
> > 
> > I tried to run the 1.5.0 Beta2  TAHI Selftest on recent Linux kernel.
> > It fails in the Stateless Address Autoconfiguration section with
> > 6 tests.
> > These tests are for Duplicate Address Detection (DAD).
> > They are detect for the Link Local Address a duplicate address on the
> > network. It seems that our current behavior is to log an message and
> > do not assign this address.
> > 
> > But the RFC 4862 says:
> > 
> > 5.4.5.  When Duplicate Address Detection Fails
> > 
> >    A tentative address that is determined to be a duplicate as described
> >    above MUST NOT be assigned to an interface, and the node SHOULD log a
> >    system management error.
> > 
> >    If the address is a link-local address formed from an interface
> >    identifier based on the hardware address, which is supposed to be
> >    uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
> >    operation on the interface SHOULD be disabled.  By disabling IP
> >    operation, the node will then:
> > 
> >    -  not send any IP packets from the interface,
> > 
> >    -  silently drop any IP packets received on the interface, and
> > 
> >    -  not forward any IP packets to the interface (when acting as a
> >       router or processing a packet with a Routing header).
> > 
> >    In this case, the IP address duplication probably means duplicate
> >    hardware addresses are in use, and trying to recover from it by
> >    configuring another IP address will not result in a usable network.
> >    In fact, it probably makes things worse by creating problems that are
> >    harder to diagnose than just disabling network operation on the
> >    interface; the user will see a partially working network where some
> >    things work, and other things do not.
> > 
> >    On the other hand, if the duplicate link-local address is not formed
> >    from an interface identifier based on the hardware address, which is
> >    supposed to be uniquely assigned, IP operation on the interface MAY
> >    be continued.
> > 
> > 
> > So I think we should disable the interface now, if DAD fails on a
> > hardware based LLA.
> > 
> 
> Not sure I agree with that.  I assume that by disable, you mean that we should
> clear the IFF_UP flag?  If we do that, and another ip address is assigned to
> that interface, then your proposal would discontinue the functionality of those
> already established addresses, which would be bad.  I could see a DOS scenario
> comming out of that as well.  Simply send ndisc na's for a recently advertised
> address, and you could prevent network communication for an entire system.
> 
> Reading the section you reference, we do follow all the MUST requirements, and
> we log an error.  Given that the disable section is a SHOULD, I think we can at
> least be somewhat more restrictive in our implementation.  Perhaps we should
> just disable the interface iff the failed address is link-local AND there are no
> other functional address assigned to the interface.

I agree here, but it seems that currently the IPv6 Logo Committee thinks
that it has to be disable the interface to get the IPv6 ready Logo in
future. I already claim that on a discussion at the TAHI users list.


So far I remember a SHOULD in RFC has to interpreted as "You should
implement that in this way, exceptions are only acceptable for a good
reason". Maybe the DOS scenario is such a good reason.

-- 
Karsten Keil
SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists