RE: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx] On Behalf Of james woodyatt
Sent: Thursday, February 16, 2017 14:52
To: IETF-Discussion Discussion <ietf@xxxxxxxx>
Cc: draft-ietf-6man-rfc4291bis@xxxxxxxx; 6man WG <ipv6@xxxxxxxx>; 6man-chairs@xxxxxxxx
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@xxxxxxx> 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@xxxxxxxxxx>

 

 

 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]