Re: IPV4LL and EXPIRE
Roy Marples
Mon Oct 27 19:15:33 2014
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.
> 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.
Roy
Archive administrator: postmaster@marples.name