dhcpcd-discuss

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

References:
IPV4LL and EXPIREDavid Hauck
Re: IPV4LL and EXPIRERoy Marples
RE: IPV4LL and EXPIREDavid Hauck
Re: IPV4LL and EXPIRERoy Marples
Re: IPV4LL and EXPIRERoy Marples
RE: IPV4LL and EXPIREDavid Hauck
Re: IPV4LL and EXPIRERoy Marples
RE: IPV4LL and EXPIREDavid Hauck
Re: IPV4LL and EXPIRERoy Marples
Archive administrator: postmaster@marples.name