allow v6 privacy and static addresses to co-exist again

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

allow v6 privacy and static addresses to co-exist again

Stefan Sperling-8
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.

With the following in /etc/hostname.if:

  dhcp
  rtsol
  inet6 some-address 64

the netstart script will run rtsol after assigning the static address,
hence preventing privacy addresses from being formed. The only effect
of 'rtsol' in this case is an auto-configured default route.

If a privacy address is manually configured first and a static address
second, the interface initially has both. But the static address prevents
creation of new addresses during RA reception. When the privacy address
becomes deprecated a fresh address is not added, breaking autoconfprivacy.

So using privacy addresses for outgoing connections and static addresses
for incoming connections is no longer possible. Do we want to support
this use case? It used to work ever since privacy addresses were introduced.

The diff below makes static addresses prevent SLAAC addresses in the
no-privacy case but allows static and privacy addresses to co-exist.

Because we create SLAAC addresses alongside privacy addresses, this
effectively reverts the default behaviour to what it was before
Simon's change. With the hostname.if snippet above we get:

 - auto-configured default route
 - SLAAC address
 - privacy addresses (rotating over time)
 - a static address

Those who prefer traditional inet6 behaviour can use:

  dhcp
  -autoconfprivacy
  rtsol

This results in:

 - auto-configured default route
 - SLAAC address

Or:

  dhcp
  -autoconfprivacy
  rtsol
  inet6 some-address 64

This results in:

 - auto-configured default route
 - a static address

ok?

Index: nd6_rtr.c
===================================================================
RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v
retrieving revision 1.62
diff -u -p -r1.62 nd6_rtr.c
--- nd6_rtr.c 28 Aug 2012 20:32:02 -0000 1.62
+++ nd6_rtr.c 2 Sep 2012 11:33:44 -0000
@@ -1275,7 +1275,8 @@ prelist_update(struct nd_prefix *new, st
  }
 
  if ((!autoconf || ((ifp->if_xflags & IFXF_INET6_NOPRIVACY) == 0 &&
-    !tempaddr_preferred)) && new->ndpr_vltime != 0 && !statique) {
+    !tempaddr_preferred)) && new->ndpr_vltime != 0 &&
+    !((ifp->if_xflags & IFXF_INET6_NOPRIVACY) && statique)) {
  /*
  * There is no SLAAC address and/or there is no preferred RFC
  * 4941 temporary address. And the valid prefix lifetime is

Reply | Threaded
Open this post in threaded view
|

Re: allow v6 privacy and static addresses to co-exist again

Simon Perreault-2
Le 2012-09-02 08:05, Stefan Sperling a écrit :

> Simon's recent commit to prevent SLAAC address formation when
> a static address is already configured has a side-effect for
> autoconfprivacy users.
>
> With the following in /etc/hostname.if:
>
>    dhcp
>    rtsol
>    inet6 some-address 64
>
> the netstart script will run rtsol after assigning the static address,
> hence preventing privacy addresses from being formed. The only effect
> of 'rtsol' in this case is an auto-configured default route.
>
> If a privacy address is manually configured first and a static address
> second, the interface initially has both. But the static address prevents
> creation of new addresses during RA reception. When the privacy address
> becomes deprecated a fresh address is not added, breaking autoconfprivacy.
>
> So using privacy addresses for outgoing connections and static addresses
> for incoming connections is no longer possible. Do we want to support
> this use case? It used to work ever since privacy addresses were introduced.
>
> The diff below makes static addresses prevent SLAAC addresses in the
> no-privacy case but allows static and privacy addresses to co-exist.
>
> Because we create SLAAC addresses alongside privacy addresses, this
> effectively reverts the default behaviour to what it was before
> Simon's change. With the hostname.if snippet above we get:
>
>   - auto-configured default route
>   - SLAAC address
>   - privacy addresses (rotating over time)
>   - a static address
>
> Those who prefer traditional inet6 behaviour can use:
>
>    dhcp
>    -autoconfprivacy
>    rtsol
>
> This results in:
>
>   - auto-configured default route
>   - SLAAC address
>
> Or:
>
>    dhcp
>    -autoconfprivacy
>    rtsol
>    inet6 some-address 64
>
> This results in:
>
>   - auto-configured default route
>   - a static address
>
> ok?

This makes sense, ok.

Please note the last comment in the comment at the top that says:

>         /*
>          * 5.5.3 (d). If the prefix advertised does not match the prefix of an
>          * address already in the list, and the Valid Lifetime is not 0,
>          * form an address.  Note that even a manually configured address
>          * should reject autoconfiguration of a new address.
>          */

This is no longer true. This comment is an excerpt from RFC 2462 which
was obsoleted by RFC 4862. The text was modified to say:

>     d)  If the prefix advertised is not equal to the prefix of an
>       address configured by stateless autoconfiguration already in the
>       list of addresses  [...]

So this change is not only good, it fits with the intent of the new RFC.

You might want to tweak the comments to reflect that.

Simon


>
> Index: nd6_rtr.c
> ===================================================================
> RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 nd6_rtr.c
> --- nd6_rtr.c 28 Aug 2012 20:32:02 -0000 1.62
> +++ nd6_rtr.c 2 Sep 2012 11:33:44 -0000
> @@ -1275,7 +1275,8 @@ prelist_update(struct nd_prefix *new, st
>   }
>
>   if ((!autoconf || ((ifp->if_xflags & IFXF_INET6_NOPRIVACY) == 0 &&
> -    !tempaddr_preferred)) && new->ndpr_vltime != 0 && !statique) {
> +    !tempaddr_preferred)) && new->ndpr_vltime != 0 &&
> +    !((ifp->if_xflags & IFXF_INET6_NOPRIVACY) && statique)) {
>   /*
>   * There is no SLAAC address and/or there is no preferred RFC
>   * 4941 temporary address. And the valid prefix lifetime is