Skip to contentSkip to conversation

New: IPv6 SLAAC address preferred over static one as source address

Bugme-new Andrew Morton 3 participants 4 messages Feb 7, 2011 – Mar 30, 2011 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Andrew Morton

author
#1 lore raw
In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 47 lines · On Mon, 7 Feb 2011 16:15:16 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=28512

           Summary: IPv6 SLAAC address preferred over static one as source
                    address
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.36
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV6
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No

Linux IPv6 source address selection rules are described here:
http://www.davidc.net/networking/ipv6-source-address-selection-linux

In case of a tie, "Linux chooses to use the latest address added".

A very common tie is where a host has a SLAAC (Stateless address auto-configuration) address as well as one or more statically assigned ones in the same /64. The SLAAC address will almost always be the most recently "added" one, as it is renewed with every Router Advertisement on the network, and there will be a tie for all other rules.

As a consequence, the kernel chooses this address by default for outgoing connections. This is usually not the preferred scenario; the static address will more likely have proper reverse DNS, be configured in ACL's, etc.

This has been discussed on the ipv6-ops mailing list ([email protected]), and a better suggestion for a tie-breaker came
out: the preferred lifetime of the address.

SLAAC addresses will have a limited preferred lifetime (as defined by the router), static addresses will usually have an unlimited preferred lifetime (0). So it makes a lot of sense to take this preferred lifetime into account for source address selection (how is it otherwise "preferred"?).

This could be added as rule #9 before using the most recently added as a final tie breaker?

Geert

maintainer
#2 lore raw

From: Andrew Morton <[email protected]>
Date: Mon, 7 Feb 2011 15:20:48 -0800

Quoted 4 lines
Quoted 4 lines

SLAAC addresses will have a limited preferred lifetime (as defined by the router), static addresses will usually have an unlimited preferred lifetime (0). So it makes a lot of sense to take this preferred lifetime into account for source address selection (how is it otherwise "preferred"?).

This is debatable.

One could just as easily say that an address with a shorter preferred lifetime has been revalidated more recently, and therefore is more likely to be uptodate, valid, and lead to a usable path.

I think the lack of specification for the final tie-breaker in the RFC was intentional :-)

The specification has to address this, and until the situation is more clear cut than it is now I don't see any benefit for changing Linux's behavior. Especially since there is a configuration based workaround which works for people in the short-term.

But I'm willing to be convinced, and those wanting to convince me can post a patch for review to [email protected] :-)

#3 lore raw
Quoted 5 lines · David Miller

This is debatable.

One could just as easily say that an address with a shorter preferred lifetime has been revalidated more recently, and therefore is more likely to be uptodate, valid, and lead to a usable path.

There we're at "most recent" again. In practice, this will often be a SLAAC address, which will rarely be preferred over a staticly configured one.

Quoted 7 lines

I think the lack of specification for the final tie-breaker in the RFC was intentional :-)

The specification has to address this, and until the situation is more clear cut than it is now I don't see any benefit for changing Linux's behavior. Especially since there is a configuration based workaround which works for people in the short-term.

What workaround are you referring to?

Geert

Signature · 2 lines
geert.hendrickx.be :: [email protected] :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!