My response to IEEE 802.15.4 would then be, but you can't assume that this same
IPv6 header compression algorithm can be used in the unassigned IPv6 address
space.
The message has to be clear. I think all the niggling objections make matters
worse, for the future, in which future we will discover that the egregious
waste caused by prefixes <= 64 bits creates a need for another IP version. The
assumption that 64-bit prefixes are more than enough can become invalid in nit
time, e.g. with IoT device that require multiple internal subnets.
Bert
From: ipv6 [mailto:ipv6-bounces(_at_)ietf(_dot_)org] On Behalf Of james woodyatt
Sent: Thursday, February 16, 2017 14:52
To: IETF-Discussion Discussion <ietf(_at_)ietf(_dot_)org>
Cc: draft-ietf-6man-rfc4291bis(_at_)ietf(_dot_)org; 6man WG
<ipv6(_at_)ietf(_dot_)org>; 6man-chairs(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6
Addressing Architecture) to Internet Standard
On Feb 16, 2017, at 00:45, Randy Bush
<randy(_at_)psg(_dot_)com<mailto:randy(_at_)psg(_dot_)com>> wrote:
If your statement is that we only have the 64 bit boundary because of
SLAAC I believe you are wrong.
cite, please. what else actually needs it?
https://tools.ietf.org/html/rfc7421
that excuses it. cite where it is actually needed to do something
useful other than slaac.
RFC 6282 compresses IPv6 headers over IEEE 802.15.4 in a way that depends on
such networks always having 64-bit network prefix length.
--james woodyatt <jhw(_at_)google(_dot_)com<mailto:jhw(_at_)google(_dot_)com>>