Re: IPv6 problems.... (dhcpcd weirdness, rshd fails, etc.)

[mlelstv%serpens.de@localhost (Michael van Elst)]

woods%planix.ca@localhost ("Greg A. Woods") writes:

>> > Nov 15 21:17:32 once inetd[10044]: connection from fe80::1030:c7e5:ac6d:b5ce%bge0(fe80::1030:c7e5:ac6d:b5ce%bge0), service shell (tcp6)
>> > Nov 15 21:17:32 once rshd[10044]: can't get stderr port: Can't assign requested address
>>
>> Looks like a bug, the scope somehow gets lost and rshd cannot bind
>> to an unscoped link local address (the scope references the interface).

>What does "scope" mean in this context?  Isn't the scope whether it is
>link-local, site-local, or global, and isn't that inferred from the
>prefix?  How can that get lost?

A link-local address has the "link" as the scope, i.e. the %bge0 part
that denotes the interface. It's only valid there and you could have
the same link-local address on multiple interfaces.

struct sockaddr_in6 {
        uint8_t         sin6_len;       /* length of this struct(socklen_t)*/
        sa_family_t     sin6_family;    /* AF_INET6 (sa_family_t) */
        in_port_t       sin6_port;      /* Transport layer port */
        uint32_t        sin6_flowinfo;  /* IP6 flow information */
        struct in6_addr sin6_addr;      /* IP6 address */
        uint32_t        sin6_scope_id;  /* scope zone index */
};

A link-local address is only valid with a scope set because you need
to identify what interface it is valid on.


>logging to see for sure.  EADDRNOTAVAIL is odd when it clearly is trying
>to use an address assigned to a working interface.

The link-local address alone is ambigous.

You can also see that on your routing table, like:

fe80::%re0/64               link#1    UC          -        -      -  re0
fe80::%wm0/64               link#2    UC          -        -      -  wm0
fe80::%lo0/64               fe80::1   U           -        -      -  lo0

Each interface gets a (scoped) route to fe80::/64.



>> Nobody notices this with global IPv6 addresses.

>Interesting -- I'm not sure how I can try it with the global address --
>i.e. how do I get the client to bind its source address to the global
>address instead of the link-local address when it is connecting to a
>local server?

You need to talk to the global IPv6 address of the server, then the
outgoing address will also be a global IPv6 address.

link-local and global cannot be used together.


>> > In looking for the cause of the rsh failure I also noted that dhcpcd is
>> > doing the following every 10 seconds:
>>
>> > Nov 15 21:17:37 once dhcpcd[465]: bge0: requesting DHCPv6 information
>>
>> It's trying to get usuable addresses via DHCPv6. This is triggered
>> by your router announcing a "managed" network prefix.

>dhcpcd already got a usable IPv6 global address

>I'm guessing this ongoing log entry is about dhcpcd doing router
>solicitation, but it already got IPv6 routes too....

It's about getting a router advertisement. The advertisement says the
network is managed and dhcpcd then tries to query a DHCPv6 server
for an address.


>Hints on the internets suggest maybe the router is broadcasting router
>advertisements every 10 seconds (and that triggers dhcpcd), which may be
>related to the next bit...

That is the reason. And the advertisment says that the addresses are
"managed" and should be queried by DHCPv6.

Each advertised prefix also includes two flags:

M flag | O flag | Description
-------+--------+-------------------------------------------------------
   0   |    0   | Indicates that no information is available via DHCPv6.
-------+--------+-------------------------------------------------------
   0   |    1   | Indicates that other configuration information is
       |        | available via DHCPv6. Examples of such information
       |        | are DNS-related information or information on other
       |        | servers within the network.
-------+--------+-------------------------------------------------------
   1   |    0   | Indicates that addresses are available via Dynamic
       |        | Host Configuration Protocol (DHCPv6).
-------+--------+-------------------------------------------------------
   1   |    1   | If the M flag is set, the O flag is redundant and can
       |        | be ignored because DHCPv6 will return all available
       |        | configuration information. 


>    8.  Select an IP Address Assignment radio button:

>    + Use DHCP Server.  This method passes more information to LAN
>      devices but some IPv6 systems might not support the DHCv6 client
>      function.

>    + Auto Config.  This is the default setting.  This setting specifies
>      how the router assigns IPv6 addresses to the devices on your home
>      network (the LAN)

>I have left it at the default "Auto Config" setting.

Yes. that's why I doubt that it behaves correctly.



>I don't really understand what "auto config" means in IPv6 parlance, but
>I'm guessing dhcpcd handles this as if it was getting a DHCP lease?

SLAAC (stateless address autoconfiguration) is the default method
to assign IPv6 addresses. The IPv6 address is built from a prefix
and the "identifier" (usually the interface MAC address pumped up
to 64 bit).



>It's weird that this is a binary either/or choice.  Can't you have
>DHCPv6 and auto-configuration on the same LAN -- isn't it just a matter
>of splitting the available address range?

The router "splits" it by advertising a prefix. Part of that advertisement
is a flag telling if you use SLAAC or DHCPv6 for that prefix.



Greetings,