IPv4 Address Flags

[Roy Marples]

Hi List

As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

This patch adds the following flags to IPv4 and mimics the IPv6
behaviour of the same flags:
IN_IFF_TENTATIVE
IN_IFF_DUPLICATED
IN_IFF_DETACHED
IN_IFF_NOTREADY (IN_IFF_TENTATIVE | IN_IFF_DUPLICATED)

ioctl SIOCGIFAFLAG_IN has been added to retrieve the flags using a ifreq
struct (ifaliasreq is probably better but then we run into compatibility
issues, also why IN_IFF_NODAD is not implemented).

ifconfig(8) has been modified to report the new flags and wait for
tentative to vanish via -w alongside the IPv6 addresses.

sysctl(8) now has these new values:
net.inet.ip.dad_count=3
net.inet.arp.debug=0

DAD is implemented according to RFC 5227.
A future patch could be made to implement address defence from the RFC,
but this is optional (although required for IPv4LL, but dhcpcd will
handle that).

It's easy to see this patch working, simply run ntpd, reboot and watch
it complain that it cannot bind to IPv4 tentative addresses.

Commentary welcome, especially on ideas of how to make IN_IFF_NODAD or
ifaliasreq work with the above.

Roy

[1] http://mail-index.netbsd.org/tech-net/2015/04/07/msg005053.html

[Dennis Ferguson]

Post by Roy Marples
As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

To tell the truth I think this is fixing the problem in the wrong
spot. I don't see a big difference between unplugging the ethernet
cable and plugging it back in, and unplugging the USB or Thunderbolt
ethernet dongle and plugging it back in, or hot-swapping the ethernet
line card out and replacing it with another. If I have active protocol
connections I would like them to survive the interface itself going
away and coming back just as much as I would like them to survive
the special case of the carrier dropping and coming back. Adding
complexity to deal only with the latter doesn't seem worth it.

I think it is better to let interface structures freely go and
come and instead address the issue higher up. A protocol session
that is bound to a local address the box no longer has should no
longer be allowed to actually send packets with that address but
otherwise should be treated like it is getting ICMP unreachables in
response to the packets it is (not) sending. If the local address
comes back it can pick up where it left off, if it doesn't it can
time out or the user can close it or it can persist doing nothing,
just like it would in the general case of the other end going
unreachable.

This seems to work no matter what it is that goes away and comes
back.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Dennis Ferguson

Post by Roy Marples
As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

To tell the truth I think this is fixing the problem in the wrong
spot. I don't see a big difference between unplugging the ethernet
cable and plugging it back in, and unplugging the USB or Thunderbolt
ethernet dongle and plugging it back in, or hot-swapping the ethernet
line card out and replacing it with another. If I have active protocol
connections I would like them to survive the interface itself going
away and coming back just as much as I would like them to survive
the special case of the carrier dropping and coming back. Adding
complexity to deal only with the latter doesn't seem worth it.
I think it is better to let interface structures freely go and
come and instead address the issue higher up. A protocol session
that is bound to a local address the box no longer has should no
longer be allowed to actually send packets with that address but
otherwise should be treated like it is getting ICMP unreachables in
response to the packets it is (not) sending. If the local address
comes back it can pick up where it left off, if it doesn't it can
time out or the user can close it or it can persist doing nothing,
just like it would in the general case of the other end going
unreachable.
This seems to work no matter what it is that goes away and comes
back.

Agreed on all points.

But this is about Duplicate Address Detection which should (in my view
anyway) be done on each address on carrier up AND when an address is
added to the interface and the carrier is up. IPv6 does this, this patch
allows IPv4 to do it too.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples
This patch adds the following flags to IPv4 and mimics the IPv6
IN_IFF_TENTATIVE
IN_IFF_DUPLICATED
IN_IFF_DETACHED
IN_IFF_NOTREADY (IN_IFF_TENTATIVE | IN_IFF_DUPLICATED)

New patch attached after making already committed adjustments to make a
few things more protocol agnostic.

Suggested by dyoung@

Roy

[Christos Zoulas]

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Wouldn't it be enough to make it a short for now? There should be
padding here?

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

I'm pretty sure the change affects a union, so it's not really an ABI
change.

Dave

[Roy Marples]

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Unless I'm missing something, that's in a union where there's already an
int so it's not an ABI change?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matt Thomas]

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Not really since that’s in a union.

No ABI change.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Apr 22, 3:42pm, ***@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: IPv4 Address Flags

| > This is an ABI change to all ifreq ioctls... If you are going to do this,=
|
| > I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get=
|
| > rid of sockaddr_big.
|
| Not really since that=E2=80=99s in a union.
|
| No ABI change.

Ah, yes!

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Matt Thomas

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Not really since that’s in a union.
No ABI change.

It is an ABI change as the offset of ifru_metric changes?

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by Matt Thomas

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Not really since that’s in a union.
No ABI change.

It is an ABI change as the offset of ifru_metric changes?

#include <net/if.h>
#include <stddef.h>
#include <stdio.h>

int main(void)
{

printf ("flags offset %lu\n", offsetof(struct ifreq, ifr_flags));
printf ("addrflags offset %lu\n", offsetof(struct ifreq, ifr_addrflags));
printf ("metric offset %lu\n", offsetof(struct ifreq, ifr_addrflags));
return 0;
}

outputs:
flags offset 16
addrflags offset 16
metric offset 16

How is this an ABI change?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Matt Thomas

Post by Christos Zoulas

diff -u -r1.188 if.h
--- sys/net/if.h 20 Apr 2015 10:19:54 -0000 1.188
+++ sys/net/if.h 22 Apr 2015 21:03:01 -0000
@@ -594,6 +594,7 @@
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
short ifru_flags;
+ int ifru_addrflags;
int ifru_metric;

This is an ABI change to all ifreq ioctls... If you are going to do this,
I'd bite the bullet and bump sockaddr_storage to 256 or 512 bytes and get
rid of sockaddr_big.

Not really since that’s in a union.
No ABI change.

It is an ABI change as the offset of ifru_metric changes?

#include <net/if.h>
#include <stddef.h>
#include <stdio.h>
int main(void)
{
printf ("flags offset %lu\n", offsetof(struct ifreq, ifr_flags));
printf ("addrflags offset %lu\n", offsetof(struct ifreq, ifr_addrflags));
printf ("metric offset %lu\n", offsetof(struct ifreq, ifr_addrflags));
return 0;
}
flags offset 16
addrflags offset 16
metric offset 16
How is this an ABI change?

New version, fixes prior copynpasta

#include <net/if.h>
#include <stddef.h>
#include <stdio.h>

int main(void)
{

printf ("flags offset %lu\n", offsetof(struct ifreq, ifr_flags));
printf ("addrflags offset %lu\n", offsetof(struct ifreq, ifr_addrflags));
printf ("metric offset %lu\n", offsetof(struct ifreq, ifr_metric));

printf ("flags offset %lu\n", offsetof(struct ifreq,
ifr_ifru.ifru_flags));
printf ("addrflags offset %lu\n", offsetof(struct ifreq,
ifr_ifru.ifru_addrflags));
printf ("metric offset %lu\n", offsetof(struct ifreq,
ifr_ifru.ifru_metric));
return 0;
}

outputs:
flags offset 16
addrflags offset 16
metric offset 16
flags offset 16
addrflags offset 16
metric offset 16

How is this an ABI change?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Dennis Ferguson

Post by Roy Marples
As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

Dropping ip addresses and connections on 'carrier down' seems pointless
to me.
You can't detect the cable being unplugged 'one switch back', so
why do you care about the local cable being unplugged.
All it does is give people an incorrect view of how fast TCP will
detect neteork outages.

Post by Dennis Ferguson
To tell the truth I think this is fixing the problem in the wrong
spot. I don't see a big difference between unplugging the ethernet
cable and plugging it back in, and unplugging the USB or Thunderbolt
ethernet dongle and plugging it back in, or hot-swapping the ethernet
line card out and replacing it with another. If I have active protocol
connections I would like them to survive the interface itself going
away and coming back just as much as I would like them to survive
the special case of the carrier dropping and coming back. Adding
complexity to deal only with the latter doesn't seem worth it.

...

On linux we've had to use a 'bond' of one interface in order to stop
USB interface interface disappearing due to electrical transients.


David

[Christos Zoulas]

Post by David Laight

Post by Dennis Ferguson

Post by Roy Marples
As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

Dropping ip addresses and connections on 'carrier down' seems pointless
to me.
You can't detect the cable being unplugged 'one switch back', so
why do you care about the local cable being unplugged.
All it does is give people an incorrect view of how fast TCP will
detect neteork outages.

Post by Dennis Ferguson
To tell the truth I think this is fixing the problem in the wrong
spot. I don't see a big difference between unplugging the ethernet
cable and plugging it back in, and unplugging the USB or Thunderbolt
ethernet dongle and plugging it back in, or hot-swapping the ethernet
line card out and replacing it with another. If I have active protocol
connections I would like them to survive the interface itself going
away and coming back just as much as I would like them to survive
the special case of the carrier dropping and coming back. Adding
complexity to deal only with the latter doesn't seem worth it.

...
On linux we've had to use a 'bond' of one interface in order to stop
USB interface interface disappearing due to electrical transients.

ifconfig wm0 softcar :-)

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by David Laight

Post by Dennis Ferguson

Post by Roy Marples
As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

Dropping ip addresses and connections on 'carrier down' seems pointless
to me.
You can't detect the cable being unplugged 'one switch back', so
why do you care about the local cable being unplugged.
All it does is give people an incorrect view of how fast TCP will
detect neteork outages.

Dropping connections when IP addresses go away seems pointless to me.
If they are allowed to persist they will either go away on their own
eventually, like they would if the cable one switch away was unplugged,
or they can pick up where they left off if the addresses come back. If it
works this way then there's not a lot of reason to care whether the
addresses go away temporarily or not and the things that manage your
interface configuration can do what is convenient for them.

Post by David Laight

Post by Dennis Ferguson
To tell the truth I think this is fixing the problem in the wrong
spot. I don't see a big difference between unplugging the ethernet
cable and plugging it back in, and unplugging the USB or Thunderbolt
ethernet dongle and plugging it back in, or hot-swapping the ethernet
line card out and replacing it with another. If I have active protocol
connections I would like them to survive the interface itself going
away and coming back just as much as I would like them to survive
the special case of the carrier dropping and coming back. Adding
complexity to deal only with the latter doesn't seem worth it.

...
On linux we've had to use a 'bond' of one interface in order to stop
USB interface interface disappearing due to electrical transients.

That's the problem with tying connection persistence to interface
configuration: you have to invent a new workaround for every kind of
event that might make the configuration go away temporarily, and it
will probably break if the change is actually permanent.

It is the case that the asymmetry you are pointing out, that different
things happen when local kernel notices a problem than when something
a few hops away notices the same problem, has always bothered me. Does
it make sense to report an error when the output queue on the local box
is full, but nothing when it is the output queue on the next hop router
that is full? Or to respond immediately when the local kernel tells you
a destination is unreachable, but to ignore it entirely when the next hop
router tells you the same thing?

Dennis Ferguson


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de