Hi, > This document updates Section 3 of [RFC2460] to reduce the length of > the flow label field from 20 bits to 16 bits, and in the process > creating a 4 bit reserved field.
OK, that's clear enough... 1. I do think that the justification in the draft for such a major change, after 12 years work based on RFC 2460, is weak. Before even knowing whether or not I like the idea, I'd expect to see much more discussion of the rationale and the implications. It's proved remarkably difficult to widely propagate basic changes in IP (diffserv is little used, ECN is still largely invisible, and Re-ECN???). We all know the story on IPv4 options, especially router alert, and we are seeing similar issues with IPv6 extension headers. Not to mention the flow label itself. So the chances that we actually see significant use of such reserved bits seem to be very low. 2. The downside of reducing the flow label to 16 bits is that it becomes clearly useless as a nonce. It can still presumably provide enough pseudo-randomness for load balancing, and it's unlikely that a single pair of hosts will need more than 65535 unique flow labels, but 65k is clearly too small a space to evade random-guess attacks. 3. By the way, we do have some spare bits, i.e. the first four bits in every packet, where only the values 4 and 6 are used. We probably need to reserve the value 0 anyway, and the value 5 is theoretically needed for RFC 1819. But even so, that leaves 12 spare code points... Regards Brian Carpenter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
