ISC DHCPv6 Server and Stateful Address Allocation
David W. Hankins
David_Hankins at isc.org
Tue Jan 6 17:32:30 UTC 2009
On Mon, Jan 05, 2009 at 05:07:37PM -0500, John Jason Brzozowski wrote:
> Exactly where I was coming from.
Unfortunately, you were both lost. :)
> On Mon, Jan 5, 2009 at 5:00 PM, <Greg.Rabil at ins.com> wrote:
> > No, the "range" 2001:558:ff10:870:8000::/65 encompasses the addresses:
> > 2001:558:ff10:870:8000:0000:0000:0000 -
> > 2001:558:ff10:870:8FFF:FFFF:FFFF:FFFF
That's not correct; a /65 implies the first 65 _bits_. Of the 4-bit
"nibble" '0x8', it is in binary 1000. Only the first bit, 1, is
covered by the mask. The remaining three bits are wildcards, so 0x8-
0xf are covered (0x8 + 0x4 + 0x2 + 0x1). 0x0-0x7 are not covered,
because the first bit is zero.
So, the range quoted above describes a /68 (/64 + 4), having 4 non-
wildcard bits after the /64 prefix (1000, 0x8).
> > Which does _not_ include 2001:558:ff10:870:f914:a7c1:42d1:faa1
I hope I've explained; it does actually.
IPv6 growing pains. Humans were not meant to do nibble math. :(
For the academic answer to the original question; how IPv6 dynamic
("IA_NA") addresses are generated right now can be seen in
server/mdb6.c, search forward for "^build_address6".
The build_address6 function is called from inside another loop that
finds the first unique answer (feeding the result back in as input,
as I recall). The initial input is the client's DUID.
The value is MD5'd (not for privacy), and then the non-wildcard bits
are copied over on top.
IFF the mask length is equal to 64, the 'u' bit (71?) is cleared to
zero. We don't touch any other bits.
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the dhcp-users