RE: IPV4LL and EXPIRE
David Hauck
Mon Oct 27 20:00:35 2014
On Monday, October 27, 2014 12:16 PM, Roy Marples wrote:
> Hi David
>
> On 27/10/2014 18:57, David Hauck wrote:
>> Yup, this latest trunk seems to be working better wrt this sequence.
>
> Excellent!
>
> A shall prepare for a new release when I get some dubious free time.
>
>> BTW, a couple additional questions:
>>
>> 1. If an IPV4LL link is established (with 169.254.239.165) and then
>> lost in
> favour of a valid DHCP lease (e.g., 192.168.1.1) and then this is lost
> (NOCARRIER) and then an IPV4LL link is re-established (CARRIER, but to
> a segment without a DHCP server) I see that the original LL address is
> re-used (i.e., 169.254.239.165). Is this correct? Shouldn't the new LL
> be a newly random LL?
>
> I changed it from really random to pseudo random as per the RFC.
>
> RFC 3927 Section 2.1 states that the random number generator SHOULD be
> seeded with a value derived from persistent information such as the
> IEEE 802 MAC address so that it usually picks the same address without
> persistent storage.
Great, thx.
>> 2. During the NOCARRIER state (and before IPV4LL or BOUND is
> established) I see there is no IPv4 address for the interface (which
> is expected), however this is an IPv6 address that continues to be associated.
> Why is this?
>> E.g.,
>> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> metric 1
>> inet6 fe80::20b:abff:fe36:1cfc prefixlen 64 scopeid 0x20<link>
>> ether 00:0b:ab:36:1c:fc txqueuelen 1000 (Ethernet)
>> RX packets 228540 bytes 21362755 (20.3 MiB)
>> RX errors 0 dropped 0 overruns 0 frame 0
>> TX packets 196 bytes 37719 (36.8 KiB)
>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>> device interrupt 16 memory 0xfd6c0000-fd6e0000
>
> Depending on your configuration, either dhcpcd or the kernel will
> generate the IPv6LL address. Perfectly normal. This generally appears
> faster than any other address as the standard says "broadcast 1 DAD test
> and wait for an extra second to finish". whereas IPv4 is "broadcast 3
> DAD tests at 1-2 second intervals and wait 2 seconds to finish". As you
> can see, it's a lot slower.
;) I don't know what all that means (I'm IPv6 illiterate), but I'll take you word for it that this is all expected.
-David
> Roy
Archive administrator: postmaster@marples.name