Re: [dhcwg] Review request for draft-ietf-dhc-host-gen-id

[Sheng Jiang <[e-mail]>]

> The prefix is NOT always 64. In principle, it can be 0 to 128, even the
> one assign to host. You can see this in ND prefix option as well: section
> 4.6.2 of RFC 2461.  I don't see a reason why cannot it to be greater than
> 64. Looking at SLAAC, RFC2462, it only defined prefix length + interface
> id length should be equal to 128. The interface id is typically be 64-bit
> long, but it is NOT a MUST. In principle, it can be other length as well
> as far as I understand.

The text doesn't explicitly prevent it, but in practice there is no other width that is allowed.   The prefix can't really be wider than 64 bits, and can't really be narrower.   I'd be curious to hear if you know of some concrete example to the contrary, but it's my understanding that this is pretty much written in stone.

<Sheng> The only current instance is the IPv4-embedded IPv6, which is no in use anymore by my understanding. But it is safer to keep prefix length. I heard some story that in other protocol using prefix, they get rid of prefix length, but run into trouble during IESG review. The format of prefix length plus 128-bit prefix field is almost standard. I see no harm to keep it this way.

> I am afraid this have to be bitfields. Actually, RFC3633 has already done bitfields in DHCPv6, hasn't it?

No, prefix length is 8 bits in RFC3633.

<Sheng> I misunderstanding the meaning of bitfields. Yes, DHCP options much be times of 8 bits. So, if we are going to keep prefix length. It has to be 8 bits, as it is now.

Sheng