Re: IPv6 socket behaviour different to IPv4?

[神明達哉 <jinmei%wide.ad.jp@localhost>]

At Wed, 04 Jun 2014 13:55:56 +0100,
Roy Marples <roy%marples.name@localhost> wrote:

> > 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,
Darren Reed <darrenr%netbsd.org@localhost> wrote:

> 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