Subject: Comments on draft-bourbaki-6man-classless-ipv6-00

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Jun 2017 08:14:04 -0700

Section 1: "Recent proposed changes to the IP Version 6 Addressing
Architecture specification [RFC4291] have caused controversy. While
link prefixes of varied lengths, e.g.  /127, /126, /124, /120, ...
/64 have been successfully deployed for many years, glaring mismatches
between a formal specification and long-standing field deployment
practices are never wise, not least because of the strong risk of
mis-implementation, which can easily result in serious operational
problems."

I'm not sure what this paragraph is trying to say. I think might be
overly philosophical.

Section 4: "For historical reasons, when a prefix is needed on a link,
barring other considerations, a /64 is recommended [RFC7136]."

Historical reason seems like a weak technical argument, maybe just say
it's recommended and reference RFC7421.

Section 4: "But operationally we recommend, barring strong
considerations to the contrary, using 64-bits for SLAAC in order not
to discover bugs where 64 was hard-coded, and to favor portability of
devices and operating systems."

Not using something allowed by the standard in order to avoid hitting
bugs is self defeating. Bugs that are not discovered don't get fixed,
so in the future when someone has a legitimate reason to do something
different it might be too late to fix problems.

Section 4 seems to bounce back and forth: First, /64 is recommended,
but then /48 might be okay, but then /64 is recommended again because
SLAAC might have bugs,  and finally any length is okay because SLAAC
should be correctly implemented. I think it would be clearer to say
that any length is allowed but /64 is recommended and here's why.

Section 5: "On the other hand, we assume that a number of IPv6
implementations fail to enforce limits on the size of some of the data
structures they employ for communicating with neighboring nodes, such
as the Neighbor Cache."

I think this argument is weak. This problem has more to do with the
number of neighbors than the prefix size. In this regard, using a
longer prefix doesn't have impact until it gets really long. For
instance, a /96 can already allow 4B addresses which should be more
than enough to kill any ND cache. I think this a case where
implementations should be fixed instead of the network trying to force
a workaround.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 13:30:13 +1200

Thanks for commenting on what the draft actually says. All good
points, IMHO.

Regards
   Brian

On 06/06/2017 03:14, Tom Herbert wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 14:22:40 +0200

Le 05/06/2017 à 17:14, Tom Herbert a écrit :
[...]
> to discover bugs where 64 was hard-coded, and to favor portability
> of devices and operating systems."
>
> Not using something allowed by the standard in order to avoid
> hitting bugs is self defeating. Bugs that are not discovered don't
> get fixed, so in the future when someone has a legitimate reason to
> do something different it might be too late to fix problems.
>
> but then /48 might be okay, but then /64 is recommended again
> because SLAAC might have bugs,  and finally any length is okay
> because SLAAC should be correctly implemented. I think it would be
> clearer to say that any length is allowed but /64 is recommended and
> here's why.

This can be a matter of backwards compatibility.

One wants SLAAC/Ethernet systems continue working even if plen in RA is
65 or 63.

The old receiver of a new RA will not break, since SLAAC spec says that 
if the plen and IIDlen make not for 128 then discard.

Alex