Pierre,
I certainly understand your argument, and we don't disagree on the technical
merit.
> I’m proposing this change then.
>
> 1. In case the provided prefix is 64, the default consist in assigning
> prefixes of length 64 first.
> 2. I’m adding a reference to 6man-why64.
>
> When the algorithm decides to make a new assignment, it first needs
> to specify the desired size of the assigned prefix. Although this
> algorithm intends to remain generic, it was observed in
> [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
> length is not 64. Therefore, prefixes of length 64 are RECOMMENDED.
> The following table MAY be used as default values, where X is the
> length of the delegated prefix.
>
> If X <= 64: Prefix length = 64
the "may malfunction" is not the reason for why the IPv6 address is classful,
so please don't put that as justification for a default of 64.
I would like this document to say as little as possible about the boundary.
RFC6204 says:
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
which you could tweak to fit this document as well. have text like that in one
place, and then all other places threat it as an arbitrary length.
please remove the table with the description of what to do for various values
of X.
I'd be happy with a statement like in RFC6204:
WPD-3: ...If the
delegated prefix is too small to address all of its
interfaces, the IPv6 CE router SHOULD log a system management
error.
> Processes proposed in the appendix are optional.
> Our implementation supports some part of it, and it works fine in our
> test-cases.
> I’d rather have a /80 than no connectivity at all (And it just works.).
> IMO, why64 is way too pessimistic on the current implementation state and
> even more when it comes to the progress implementations will do in the coming
> years.
>
> And we either do that or let people do NAT66. ;)
>
>
> Is it OK for you Ole ?
I'd also remove the appendix.
it doesn't make sense to specify something that breaks SLAAC.
protocol design is politics. we want to make it clear to the address delegation
authorities that not delegating a large enough address block will lead to
breakage.
in my view, if we let this principle slide, then the risk isn't that the
delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT
anyhow.
cheers,
Ole
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
