Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[[e-mail]]

Dave,

> Given that what we are left with is policy, I think it is quite harsh of you to declare that there is no consensus on the current text on the IETF list.
> There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost. There is a justified fear that allowing the 64 bit boundary to slide, we will end up in a situation similar to IPv4 addressing. E.g. charging per address.
> 
> I'm a little worried that your fighting yesterday's battle.  To be honest, I'm less worried about charing for more than one IP address. I'm much more worried about charging for more than one subnet. In fact, I'm worried a hard and inflexible boundary at /64 reinforces a model for charging for more than one subnet.
> 
> If that happens would you prefer people use NTPv6 or NAT66?  I'd prefer a more flexible subnet boundary, that allows the18 quadrillion addresses in a /64 to be broken into smaller subnets. 

Therein lays the paradox. If the IETF were to standardise arbitrary prefix length > 64 you end up being charged per address. If implementations don't support arbitrary prefix lengths > 64 you end up having to do NAT66, ND proxy...
Which is why all implementations should support arbitrary prefix length, but not tell anyone. ;-)

> 
> Furthermore, we are talking about giving individual devices their own subnets.  I like this model and with today's scale that will be fine.  But, longer-term this has me worried, especially if we keep a inflexible /64 boundary. 

That would require extreme waste in the first 64 bits...
2^64 number of addresses is an awfully big number.

> This is where the IETF has to perform a fine balancing act. On one side ensure that the 64 bit boundary stands, at the other side ensure that all implementors do not enshrine a hard-coded boundary in their implementations.
> 
> Ok, are you willing to put that in the document?  The /64 requirement, is a political consideration, not a technical one.  Because other than /64 subnets are clearly technically possible, we have evidence of it in RFC 7421. 

But unless we also kept some technical limitations, would anyone accept the boundary if it was purely policy?
(And at this point there is surely a lot more technical reasons than just SLAAC.)

Best regards,
Ole