why are IPv6 addresses removed on link down

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

         case NETDEV_DOWN:
         case NETDEV_UNREGISTER:
                 /*
                  *      Remove all addresses from this interface.
                  */
                 addrconf_ifdown(dev, event != NETDEV_DOWN);
                 break;

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

         case NETDEV_DOWN:
         case NETDEV_UNREGISTER:
                 /*
                  *      Remove all addresses from this interface.
                  */
                 addrconf_ifdown(dev, event != NETDEV_DOWN);
                 break;

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

Quoted 17 lines · Stephen Hemminger

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

          case NETDEV_DOWN:
          case NETDEV_UNREGISTER:
                  /*
                   *      Remove all addresses from this interface.
                   */
                  addrconf_ifdown(dev, event != NETDEV_DOWN);
                  break;

Quoted 8 lines

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

It should be no problem if the kernel would reacquire them on ifup and do proper DAD. We simply must not use them while the interface is dead (also making sure they don't get used for loopback routing).

The problem the IPv6 addresses get removed is much more a historical artifact nowadays, I think. It is part of user space API and scripts deal with that already.

Hi,

Quoted 27 lines · Hannes Frederic Sowa

Quoted 17 lines · Stephen Hemminger

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

          case NETDEV_DOWN:
          case NETDEV_UNREGISTER:
                  /*
                   *      Remove all addresses from this interface.
                   */
                  addrconf_ifdown(dev, event != NETDEV_DOWN);
                  break;

Quoted 8 lines

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

Quoted 7 lines

It should be no problem if the kernel would reacquire them on ifup and do proper DAD. We simply must not use them while the interface is dead (also making sure they don't get used for loopback routing).

The problem the IPv6 addresses get removed is much more a historical artifact nowadays, I think. It is part of user space API and scripts deal with that already.

We might have another "detached" state which essintially drops outgoing packets while link is down. Just after recovering link, we could start receiving packet from the link and perform optimistic DAD. And then, after it succeeds, we may start sending packets.

Since "detached" state is like the state just before completing Optimistic DAD, it is not so difficult to implement this extended behavior, I guess.

Quoted 43 lines · YOSHIFUJI Hideaki

Hi,

Quoted 27 lines · Hannes Frederic Sowa

Quoted 17 lines · Stephen Hemminger

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

          case NETDEV_DOWN:
          case NETDEV_UNREGISTER:
                  /*
                   *      Remove all addresses from this interface.
                   */
                  addrconf_ifdown(dev, event != NETDEV_DOWN);
                  break;

Quoted 8 lines

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

Quoted 7 lines

It should be no problem if the kernel would reacquire them on ifup and do proper DAD. We simply must not use them while the interface is dead (also making sure they don't get used for loopback routing).

The problem the IPv6 addresses get removed is much more a historical artifact nowadays, I think. It is part of user space API and scripts deal with that already.

We might have another "detached" state which essintially drops outgoing packets while link is down. Just after recovering link, we could start receiving packet from the link and perform optimistic DAD. And then, after it succeeds, we may start sending packets.

Quoted 4 lines

Since "detached" state is like the state just before completing Optimistic DAD, it is not so difficult to implement this extended behavior, I guess.

Note that node is allowed to send packets to neighbours or default routers if the node knows their link-layer addresses during Optimistic DAD.

Hi,

Quoted 44 lines · YOSHIFUJI Hideaki

Quoted 43 lines · YOSHIFUJI Hideaki

Hi,

Quoted 27 lines · Hannes Frederic Sowa

Quoted 17 lines · Stephen Hemminger

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

           case NETDEV_DOWN:
           case NETDEV_UNREGISTER:
                   /*
                    *      Remove all addresses from this interface.
                    */
                   addrconf_ifdown(dev, event != NETDEV_DOWN);
                   break;

Quoted 8 lines

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

Quoted 7 lines

It should be no problem if the kernel would reacquire them on ifup and do proper DAD. We simply must not use them while the interface is dead (also making sure they don't get used for loopback routing).

The problem the IPv6 addresses get removed is much more a historical artifact nowadays, I think. It is part of user space API and scripts deal with that already.

We might have another "detached" state which essintially drops outgoing packets while link is down. Just after recovering link, we could start receiving packet from the link and perform optimistic DAD. And then, after it succeeds, we may start sending packets.

Quoted 9 lines

Quoted 4 lines

Since "detached" state is like the state just before completing Optimistic DAD, it is not so difficult to implement this extended behavior, I guess.

Note that node is allowed to send packets to neighbours or default routers if the node knows their link-layer addresses during Optimistic DAD.

I don't think it should be a problem from internal state handling of the addresses.

I am much more concerned with scripts expecting the addresses to be flushed on interface down/up and not reacting appropriate.

Quoted 57 lines · Hannes Frederic Sowa

Hi,

Quoted 44 lines · YOSHIFUJI Hideaki

Quoted 43 lines · YOSHIFUJI Hideaki

Hi,

Quoted 27 lines · Hannes Frederic Sowa

Quoted 17 lines · Stephen Hemminger

Quoted 14 lines · On Mon, 12 Jan 2015 22:06:44 -0700 David Ahern <[email protected]> wrote:

We noticed that IPv6 addresses are removed on a link down. e.g.,
ip link set dev eth1

Looking at the code it appears to be this code path in addrconf.c:

           case NETDEV_DOWN:
           case NETDEV_UNREGISTER:
                   /*
                    *      Remove all addresses from this interface.
                    */
                   addrconf_ifdown(dev, event != NETDEV_DOWN);
                   break;

Quoted 8 lines

Quoted 5 lines

IPv4 addresses are NOT removed on a link down. Is there a particular reason IPv6 addresses are?

Thanks,
David

See RFC's which describes how IPv6 does Duplicate Address Detection. Address is not valid when link is down, since DAD is not possible.

Quoted 7 lines

It should be no problem if the kernel would reacquire them on ifup and do proper DAD. We simply must not use them while the interface is dead (also making sure they don't get used for loopback routing).

The problem the IPv6 addresses get removed is much more a historical artifact nowadays, I think. It is part of user space API and scripts deal with that already.

We might have another "detached" state which essintially drops outgoing packets while link is down. Just after recovering link, we could start receiving packet from the link and perform optimistic DAD. And then, after it succeeds, we may start sending packets.

Quoted 9 lines

Quoted 4 lines

Since "detached" state is like the state just before completing Optimistic DAD, it is not so difficult to implement this extended behavior, I guess.

Note that node is allowed to send packets to neighbours or default routers if the node knows their link-layer addresses during Optimistic DAD.

Quoted 5 lines

I don't think it should be a problem from internal state handling of the addresses.

I am much more concerned with scripts expecting the addresses to be flushed on interface down/up and not reacting appropriate.

The current code seems inconsistent: I can put an IPv6 address on a link in the down state. On a link up the address is retained. Only on a subsequent link down is it removed. If DAD or anything else is the reason for the current logic then why allow an address to be assigned in the down state? Similarly that it currently seems to work ok then it suggests the right thing is done on a link up in which case a flush is not needed.

Bottom line is there a harm in removing the flush? If there is no harm will mainline kernel take a patch to do that or is your backward compatibility concern enough to block it?

This was already discussed several times here, e.g. one patch I just found:

http://lists.openwall.net/netdev/2011/01/24/8
and
http://patchwork.ozlabs.org/patch/17558/

Albeit I hate sysctls for things like this, it might I tend to find it acceptable because it solves a problem which happened to lots of people. And I don't like the current behavior neither.

I think this can work, but we should follow up all the old discussions to not introduce any kind of new undesired behavior this time.

The current code seems inconsistent: I can put an IPv6 address on a link in the down state. On a link up the address is retained. Only on a subsequent link down is it removed. If DAD or anything else is the reason for the current logic then why allow an address to be assigned in the down state? Similarly that it currently seems to work ok then it suggests the right thing is done on a link up in which case a flush is not needed.

Bottom line is there a harm in removing the flush? If there is no harm will mainline kernel take a patch to do that or is your backward compatibility concern enough to block it?

Quoted 9 lines · David Ahern

The current code seems inconsistent: I can put an IPv6 address on a link in the down state. On a link up the address is retained. Only on a subsequent link down is it removed. If DAD or anything else is the reason for the current logic then why allow an address to be assigned in the down state? Similarly that it currently seems to work ok then it suggests the right thing is done on a link up in which case a flush is not needed.

Quoted 3 lines

Bottom line is there a harm in removing the flush? If there is no harm will mainline kernel take a patch to do that or is your backward compatibility concern enough to block it?

Does some of this have to do with the manner in which this interacts with SLAAC? I recall that there were two schools of thought for doing DAD when SLAAC is present: one says it is sufficient to just do DAD on the interface-id, the other requies DAD on the whole 128-bit IPv6 address. I'm not sure which choice linux makes.

Yes, it does have something to do with it. But I didn't understand what you meant by doing DAD on the interface-id.

If you look at the patches I just posted, only addresses which are in link-local and not in permanent state will be flushed.

I also need to do research on how to safely approach this, I don't know, yet.

Bye,
Hannes

Bottom line is there a harm in removing the flush? If there is no harm will mainline kernel take a patch to do that or is your backward compatibility concern enough to block it?

From: David Ahern <[email protected]>
Date: Tue, 13 Jan 2015 07:53:59 -0700

Quoted 3 lines

Bottom line is there a harm in removing the flush? If there is no harm will mainline kernel take a patch to do that or is your backward compatibility concern enough to block it?

Backward compatibility trumps all other concerns here, and I say is enough to block changing the behavior. One which we've had for more than a decade.