IPv6 socket behaviour different to IPv4?

[Darren Reed]

I'm trying to get the IPFilter test suite up and running on NetBSD
and I've come to my first hurdle.

netbsd ~/ipf-test-suite# wget -O /dev/null
ftp://192.168.200.2//pub/test_data.txt
--2014-06-01 17:43:55-- ftp://192.168.200.2//pub/test_data.txt
=> '/dev/null'
Connecting to 192.168.200.2:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /pub ... done.
==> SIZE test_data.txt ... 68
==> PASV ... done. ==> RETR test_data.txt ... done.
Length: 68 (unauthoritative)

100%[=============================================================>]
68 --.-K/s in 0s

2014-06-01 17:43:56 (3.89 MB/s) - '/dev/null' saved [68]

netbsd ~/ipf-test-suite# wget -O /dev/null
'ftp://[192:168:200::2]//pub/test_data.txt'
--2014-06-01 17:44:23-- ftp://[192:168:200::2]//pub/test_data.txt
=> '/dev/null'
Connecting to [192:168:200::2]:21... failed: Can't assign requested address.
Retrying.

What actually gets tried?

3354 1 wget write(0x2, 0xffffffffffffaf70, 0x5d) = 93
"--2014-06-01 17:45:48--
ftp://[192:168:200::2]//pub/test_data.txt\n (try: 2) => '/dev/null"
3354 1 wget write(0x2, 0xffffffffffffab20, 0x25) = 37
"Connecting to [192:168:200::2]:21... "
3354 1 wget __socket30(0x18, 0x1, 0) = 4
3354 1 wget connect(0x4, 0xffffffffffffada0, 0x1c) Err#49
EADDRNOTAVAIL
3354 1 wget close(0x4) = 0

so it presumably gets an IPv6 socket but that then connect fails because
the network interface is down?

hme0: flags=8063<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
capabilities=3c00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=0
ec_capabilities=1<VLAN_MTU>
ec_enabled=0
address: 08:00:20:b6:cd:99
media: Ethernet autoselect (none)
status: no carrier
inet 192.168.200.2 netmask 0xffffff00 broadcast 192.168.200.255
inet6 fe80::a00:20ff:feb6:cd99%hme0 prefixlen 64 detached
scopeid 0x2
inet6 192:168:200::2 prefixlen 48 detached

So the "IN6_IFF_DETACHED" flag is set from usr/src/sys/netinet/in6.c here:
in6_update_ifa1()
...
if (ifp->if_link_state == LINK_STATE_DOWN) {
ia->ia6_flags |= IN6_IFF_DETACHED;
...

Which means that the kernel never finds an active address to use when
it calls in6_ifawithifp().

Should the behaviour of the kernel be changed such that it behaves the
same way for IPv6 sockets connecting to IP addresses on network intefaces
that are down as it does for IPv4 sockets?

Or should the IPv4 behaviour be changed?

Or just leave it as it is?

Darren


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

[Roy Marples]

Hi

Post by Darren Reed
I'm trying to get the IPFilter test suite up and running on NetBSD
and I've come to my first hurdle.
netbsd ~/ipf-test-suite# wget -O /dev/null
ftp://192.168.200.2//pub/test_data.txt
--2014-06-01 17:43:55-- ftp://192.168.200.2//pub/test_data.txt
=> '/dev/null'
Connecting to 192.168.200.2:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /pub ... done.
==> SIZE test_data.txt ... 68
==> PASV ... done. ==> RETR test_data.txt ... done.
Length: 68 (unauthoritative)
100%[=============================================================>]
68 --.-K/s in 0s
2014-06-01 17:43:56 (3.89 MB/s) - '/dev/null' saved [68]
netbsd ~/ipf-test-suite# wget -O /dev/null
'ftp://[192:168:200::2]//pub/test_data.txt'
--2014-06-01 17:44:23-- ftp://[192:168:200::2]//pub/test_data.txt
=> '/dev/null'
Connecting to [192:168:200::2]:21... failed: Can't assign requested address.
Retrying.
What actually gets tried?
3354 1 wget write(0x2, 0xffffffffffffaf70, 0x5d) = 93
"--2014-06-01 17:45:48--
ftp://[192:168:200::2]//pub/test_data.txt\n (try: 2) => '/dev/null"
3354 1 wget write(0x2, 0xffffffffffffab20, 0x25) = 37
"Connecting to [192:168:200::2]:21... "
3354 1 wget __socket30(0x18, 0x1, 0) = 4
3354 1 wget connect(0x4, 0xffffffffffffada0, 0x1c) Err#49
EADDRNOTAVAIL
3354 1 wget close(0x4) = 0
so it presumably gets an IPv6 socket but that then connect fails because
the network interface is down?
hme0: flags=8063<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
capabilities=3c00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=0
ec_capabilities=1<VLAN_MTU>
ec_enabled=0
address: 08:00:20:b6:cd:99
media: Ethernet autoselect (none)
status: no carrier
inet 192.168.200.2 netmask 0xffffff00 broadcast 192.168.200.255
inet6 fe80::a00:20ff:feb6:cd99%hme0 prefixlen 64 detached
scopeid 0x2
inet6 192:168:200::2 prefixlen 48 detached
in6_update_ifa1()
...
if (ifp->if_link_state == LINK_STATE_DOWN) {
ia->ia6_flags |= IN6_IFF_DETACHED;
...
Which means that the kernel never finds an active address to use when
it calls in6_ifawithifp().
Should the behaviour of the kernel be changed such that it behaves the
same way for IPv6 sockets connecting to IP addresses on network intefaces
that are down as it does for IPv4 sockets?
Or should the IPv4 behaviour be changed?
Or just leave it as it is?

This is a good question!
Traditionally userland manages every IPv4 address whereas the kernel
manages linklocal IPv6 addresses and maybe a few other types as well.
Because of this, there is the need to manage network changes for these
addresses and this is what you are seeing.
I have no opinion on the correct behavior re your socket query though.

Roy

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

[Darren Reed]

So the issue appears to be with how IPv6 determines what addresses
are ok to use on a network interface. In particular, it always wants to
use DAD before an interface is deemed ok to use. Of course when a NIC
is down, it is not possible for DAD to start so non-link local addresses
are never marked safe for use.

When autoconfiguration of addresses is active, I can't see a problem
with this, nor even automatic address selection where a full /128 is
not configured, only the portion of the IPv6 address that doesn't have
an EID in it.

But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

To change the behaviour, it would be necessary to add a new flag to
ifa_flags (IFA_NOAUTOSEL?) that could only be set when the address
was assigned to the interface.

Darren


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

[Ted Lemon]

Post by Darren Reed
Of course when a NIC
is down, it is not possible for DAD to start so non-link local addresses
are never marked safe for use.

Isn't DAD applicable to link-local addresses as well?


--
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 Ted Lemon

Post by Darren Reed
Of course when a NIC
is down, it is not possible for DAD to start so non-link local addresses
are never marked safe for use.

Isn't DAD applicable to link-local addresses as well?

Yes it is.

--
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 Darren Reed
But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

Why do you have this desire?
If any address is on-link, DAD needs to be performed.

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 Darren Reed
But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

Why do you have this desire?
If any address is on-link, DAD needs to be performed.

Put yourself in an IPv6 only world...

Not relevant to the discussion, the same logic also applies to IPv4
although this requires a good userland daemon like say dhcpcd.
DAD is performed using ARP and when the link goes down the address is
removed from the interface.

In your /etc/hosts file, you have an entry in it for an IPv6 address
to be assigned to your hostname and no other line with your hostname.
As soon as you disconnect from the network, you can no longer do
"ssh hostname".

And this is a problem how exactly? `ssh localhost` still works.
Sounds more like a local name resolution issue than an address
availability one.

Roy

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

[Darren Reed]

Post by Roy Marples

Post by Darren Reed
But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

Why do you have this desire?
If any address is on-link, DAD needs to be performed.

Put yourself in an IPv6 only world...

In your /etc/hosts file, you have an entry in it for an IPv6 address
to be assigned to your hostname and no other line with your hostname.

As soon as you disconnect from the network, you can no longer do
"ssh hostname".

Darren

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

[Darren Reed]

Post by Roy Marples

Post by Roy Marples

Post by Darren Reed
But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

Why do you have this desire?
If any address is on-link, DAD needs to be performed.

Put yourself in an IPv6 only world...

Not relevant to the discussion, the same logic also applies to IPv4
although this requires a good userland daemon like say dhcpcd.

In an IPv4 world, if I put "10.1.1.1 netbsd" in my hosts file and
manually assign 10.1.1.1 to any network interface, then I will
always be able to connect to 10.1.1.1 and thus "netbsd".

Post by Roy Marples
DAD is performed using ARP and when the link goes down the address is
removed from the interface.

Except that DAD only marks an IP address as being unusable when
a duplicate is detected which is significantly different to an address
being unusable until an effort has been made to ensure it is unique.

Post by Roy Marples

In your /etc/hosts file, you have an entry in it for an IPv6 address
to be assigned to your hostname and no other line with your hostname.
As soon as you disconnect from the network, you can no longer do
"ssh hostname".

And this is a problem how exactly? `ssh localhost` still works.
Sounds more like a local name resolution issue than an address
availability one.

Rinse and repeat by replacing "hostname" with a static IP address that
you have assigned to a network interface.

Darren

--
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 Darren Reed

Post by Roy Marples

Post by Roy Marples

Post by Darren Reed
But when I configure "fd00::1" or "1::1" as an IPv6 address, I would
expect that the system should be able to recognise that there is no
desire on my part to change the address should a conflict arise but
I can't see any way for the kernel to divine that when it is just given
an IP address.

Why do you have this desire?
If any address is on-link, DAD needs to be performed.

Put yourself in an IPv6 only world...

Not relevant to the discussion, the same logic also applies to IPv4
although this requires a good userland daemon like say dhcpcd.

In an IPv4 world, if I put "10.1.1.1 netbsd" in my hosts file and
manually assign 10.1.1.1 to any network interface, then I will
always be able to connect to 10.1.1.1 and thus "netbsd".

I said a good userland daemon, not manual assignment :)

Post by Darren Reed

Post by Roy Marples

In your /etc/hosts file, you have an entry in it for an IPv6 address
to be assigned to your hostname and no other line with your hostname.
As soon as you disconnect from the network, you can no longer do
"ssh hostname".

And this is a problem how exactly? `ssh localhost` still works.
Sounds more like a local name resolution issue than an address
availability one.

Rinse and repeat by replacing "hostname" with a static IP address that
you have assigned to a network interface.

I'm still not entirely sure what your use case is or why you believe
it's important to talk to an address on a non functioning interface (ie,
it's down or no carrier)
If you want the same behavioral traits as IPv4 then at a guess you would
need to make IN6_IFF_NODAD assignable from userland (currently it's
rejected).
I'm not entirely sure that's a good idea though.

Roy

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

[Darren Reed]

Post by Roy Marples
...
I'm still not entirely sure what your use case is or why you believe
it's important to talk to an address on a non functioning interface
(ie, it's down or no carrier)
If you want the same behavioral traits as IPv4 then at a guess you
would need to make IN6_IFF_NODAD assignable from userland (currently
it's rejected).
I'm not entirely sure that's a good idea though.

I'm inclined to agree with you on that part because DAD is a useful
activity to perform regardless of how the IP address was assigned,
however ...

Looking at the source, it appears that flag is not properly used even now
(see the patch below.)

It would seem that "tentative" is also being overloaded in how it is
used as this comment:

* If my address is tentative, this means that there's somebody
* already using the same address as mine. This indicates DAD
failure.
* This is defined in RFC 2462.
*

does not reflect that tentative is used to mark an address that is
newly assigned to an interface or that an interface has gone through
a down/up transition.

There is an existing lever, net.inet6.ip6.dad_count, which when set to 0
turns off DAD completely. If a global such as this exists, why not allow
for a more local setting - even if it is per-interface?

Darren

--- sys/netinet6/in6_var.h.orig 2014-06-05 00:38:38.000000000 +1000
+++ sys/netinet6/in6_var.h 2014-06-05 00:39:09.000000000 +1000
@@ -681,7 +681,7 @@
int in6_update_ifa(struct ifnet *, struct in6_aliasreq *,
struct in6_ifaddr *, int);
void in6_purgeaddr(struct ifaddr *);
-int in6if_do_dad(struct ifnet *);
+int in6if_do_dad(struct ifnet *, struct struct in6_ifaddr *);
void in6_purgeif(struct ifnet *);
void in6_savemkludge(struct in6_ifaddr *);
void in6_setmaxmtu (void);

--- sys/netinet6/in6.c.orig 2014-06-05 00:27:51.000000000 +1000
+++ sys/netinet6/in6.c 2014-06-05 00:38:15.000000000 +1000
@@ -1077,7 +1077,7 @@
if (ifp->if_link_state == LINK_STATE_DOWN) {
ia->ia6_flags |= IN6_IFF_DETACHED;
ia->ia6_flags &= ~IN6_IFF_TENTATIVE;
- } else if (hostIsNew && in6if_do_dad(ifp))
+ } else if (hostIsNew && in6if_do_dad(ifp, ia))
ia->ia6_flags |= IN6_IFF_TENTATIVE;

/*
@@ -1303,8 +1303,7 @@
* XXX It may be of use, if we can administratively
* disable DAD.
*/
- if (hostIsNew && in6if_do_dad(ifp) &&
- ((ifra->ifra_flags & IN6_IFF_NODAD) == 0) &&
+ if (hostIsNew && in6if_do_dad(ifp, ia) &&
(ia->ia6_flags & IN6_IFF_TENTATIVE))
{
int mindelay, maxdelay;
@@ -2232,11 +2231,14 @@
}

int
-in6if_do_dad(struct ifnet *ifp)
+in6if_do_dad(struct ifnet *ifp, struct in6_ifaddr *ia)
{
if ((ifp->if_flags & IFF_LOOPBACK) != 0)
return 0;

+ if ((ia->ia6_flags & IN6_IFF_NODAD) != 0))
+ return 0;
+
switch (ifp->if_type) {
case IFT_FAITH:
/*


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

[神明達哉]

At Wed, 04 Jun 2014 13:55:56 +0100,

Post by Roy Marples

Post by Darren Reed
Rinse and repeat by replacing "hostname" with a static IP address that
you have assigned to a network interface.

I'm still not entirely sure what your use case is or why you believe
it's important to talk to an address on a non functioning interface (ie,
it's down or no carrier)
If you want the same behavioral traits as IPv4 then at a guess you would
need to make IN6_IFF_NODAD assignable from userland (currently it's
rejected).
I'm not entirely sure that's a good idea though.

A knob to manually suppress DAD may be of some use, but
that shouldn't be used too casually, e.g., simply because it's a
manually configured address. At least that would violate RFC 4862,
which states DAD must be performed for manually configured addresses,
too:

Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:

I'm also not sure if I understand this correctly:

At Wed, 04 Jun 2014 09:31:09 +1000,

Post by Roy Marples
In your /etc/hosts file, you have an entry in it for an IPv6 address
to be assigned to your hostname and no other line with your hostname.
As soon as you disconnect from the network, you can no longer do
"ssh hostname".

Does this mean this address was once usable when the host is connected
(after performing DAD), but disconnecting it makes it unusable
somehow for a reason related to DAD? I'm not familiar with very
latest NetBSD kernel code, but IIRC the original DAD implementation of
the KAME project didn't behave that way. If you reboot a system while
it's disconnected, though, the kernel may try to perform DAD, making
the address tentative, noticing the interface is down, and keeping the
address tentative (thus unusable). Perhaps this is the problem
currently discussed?

If so, again IIRC, the tentative flag should be able to be cleared
manually. We might also consider changing the kernel behavior so it
only initiates DAD when the interface becomes up.

--
JINMEI, Tatuya

--
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 神明達哉
Does this mean this address was once usable when the host is connected
(after performing DAD), but disconnecting it makes it unusable
somehow for a reason related to DAD? I'm not familiar with very
latest NetBSD kernel code, but IIRC the original DAD implementation of
the KAME project didn't behave that way. If you reboot a system while
it's disconnected, though, the kernel may try to perform DAD, making
the address tentative, noticing the interface is down, and keeping the
address tentative (thus unusable). Perhaps this is the problem
currently discussed?
If so, again IIRC, the tentative flag should be able to be cleared
manually. We might also consider changing the kernel behavior so it
only initiates DAD when the interface becomes up.

So what used to happen is this
Tentative address assigned, DAD performed, tentative flag cleared and
optionally duplicated flag set.

What happens now is this
Tentative address assigned
IF link != DOWN then
DAD performed, tentative flag cleared and optionally duplicated
flag set.
else
detached flag is set

Link goes from != DOWN to DOWN then all IPv6 addresses are marked as
detached (this is what Darren is complaining about)

Link goes from DOWN to != DOWN then all IPv6 addresses are marked as
tentative, detached flag is cleared and DAD is performed again

The rationale for this is simple, DAD must be performed on link change
as we may have moved to a different network.
This is also stated in RFC6509 Section 5.4

5.4. Link-Layer Indication

In order to start detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become
available [RFC4957].

After the indication is received, the host MUST mark all currently
configured (non-tentative) IP addresses as inoperable until the
change detection process completes.

I chose to mark them as non tentative (ie detached) at link down,
because we're fractionally to late at link up.

I did experiment with just marking the addresses as tentative instead of
detached, but this had the side effect of an active link taking over in
a timely manner.
My use case is my laptop with wired and wireless connections, unplug one
then the other takes over.

Roy


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

[神明達哉]

At Wed, 04 Jun 2014 18:09:11 +0100,

Post by Roy Marples
Link goes from != DOWN to DOWN then all IPv6 addresses are marked as
detached (this is what Darren is complaining about)
Link goes from DOWN to != DOWN then all IPv6 addresses are marked as
tentative, detached flag is cleared and DAD is performed again
The rationale for this is simple, DAD must be performed on link change
as we may have moved to a different network.
This is also stated in RFC6509 Section 5.4

This should be RFC6059, btw.

Post by Roy Marples
5.4. Link-Layer Indication
In order to start detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become
available [RFC4957].
After the indication is received, the host MUST mark all currently
configured (non-tentative) IP addresses as inoperable until the
change detection process completes.
I chose to mark them as non tentative (ie detached) at link down,
because we're fractionally to late at link up.

Ah, okay. So, as I understand it, this is not an issue of DAD but an
issue of DNA, and, more specifically, a matter of how precisely we
implement it. Disabling DAD on that interface certainly looks too
much if the purpose is to allow node-local communication using a
"detached" address. One possibility would be to introduce a tweakable
switch that disables the DNA operation at the risk of allowing the
small window on link up. Another, probably more substantial but
probably cleaner change would be to allow using a detached address for
(node) local communication (e.g., allow bind() but filter out packets
using a detached address if they are sent to the wire rather than
loopback).

--
JINMEI, Tatuya

--
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 神明達哉
Ah, okay. So, as I understand it, this is not an issue of DAD but an
issue of DNA, and, more specifically, a matter of how precisely we
implement it.

It's not really DNA either. I just used that RFC as an example of why
the behavior as I see it is required.
If you don't perform DAD on link change then why bother with DAD at all?

Post by 神明達哉
Disabling DAD on that interface certainly looks too
much if the purpose is to allow node-local communication using a
"detached" address. One possibility would be to introduce a tweakable
switch that disables the DNA operation at the risk of allowing the
small window on link up. Another, probably more substantial but
probably cleaner change would be to allow using a detached address for
(node) local communication (e.g., allow bind() but filter out packets
using a detached address if they are sent to the wire rather than
loopback).

I've not tested this, but wouldn't a host route to the interface address
via the loopback address work?

Roy

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

[神明達哉]

At Wed, 04 Jun 2014 21:09:03 +0100,

Post by Roy Marples

Post by 神明達哉
Ah, okay. So, as I understand it, this is not an issue of DAD but an
issue of DNA, and, more specifically, a matter of how precisely we
implement it.

It's not really DNA either. I just used that RFC as an example of why
the behavior as I see it is required.
If you don't perform DAD on link change then why bother with DAD at all?

To perform DAD on link up, it should suffice to just make the
addresses tentative on getting the indication of status change. (If I
understand it correctly) the implementation using DETACHED flag is
stronger than that: closing a small (if theoretical/any) window where
these addresses could be used between the link up and the address
status change (marked as tentative) upon recognizing the link status.
Personally, I'd still consider it a valid DAD implementation even if
it allows such a small window as long as it's small enough (remember,
DAD is not an algorithm that guarantees 100% safety anyway).

Post by Roy Marples

Post by 神明達哉
Disabling DAD on that interface certainly looks too
much if the purpose is to allow node-local communication using a
"detached" address. One possibility would be to introduce a tweakable
switch that disables the DNA operation at the risk of allowing the
small window on link up. Another, probably more substantial but
probably cleaner change would be to allow using a detached address for
(node) local communication (e.g., allow bind() but filter out packets
using a detached address if they are sent to the wire rather than
loopback).

I've not tested this, but wouldn't a host route to the interface address
via the loopback address work?

Is this a question of whether local communication using a detached
address is currently possible? I don't fully remember either, but the
host route itself should work (unless it's removed as a result of the
status change to detached). But there may be other issues, like
whether bind(2) is allowed for that address.

--
JINMEI, Tatuya

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

[Darren Reed]

Post by 神明達哉

Post by Roy Marples

Post by 神明達哉
Disabling DAD on that interface certainly looks too
much if the purpose is to allow node-local communication using a
"detached" address. One possibility would be to introduce a tweakable
switch that disables the DNA operation at the risk of allowing the
small window on link up. Another, probably more substantial but
probably cleaner change would be to allow using a detached address for
(node) local communication (e.g., allow bind() but filter out packets
using a detached address if they are sent to the wire rather than
loopback).

All of these suggestions have merit as I'm also of a mind to not
disable (or need to disable) DAD just to support node-local
communication whilst the link is down.

Post by 神明達哉

Post by Roy Marples
I've not tested this, but wouldn't a host route to the interface address
via the loopback address work?

Is this a question of whether local communication using a detached
address is currently possible? I don't fully remember either, but the
host route itself should work (unless it's removed as a result of the
status change to detached). But there may be other issues, like
whether bind(2) is allowed for that address.

Yes - part of the problem here is that bind(2) currently fails and I cannot
see how creating a host route would fix that.

Darren

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