[Roll] question about rpl-04.txt prefix length

[Michael Richardson <mcr at sandelman.ca>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


5.1.3.1.1.5.  Destination Prefix

   The Destination Prefix suboption does not have any alignment
   requirements.  Its format is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 3    |            Length             |Resvd|Prf|Resvd|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |                                               |
       +-+-+-+-+-+-+-+-+                                               |
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


...
   The Prefix Length is an 16-bit unsigned integer that indicates the
   number of leading bits in the destination prefix.

It's shown as an 8-bit value in the picture, and 8 bits is enough for 
128 bits of prefix length.  I take it the text is wrong, and the picture
is right?

Change to:
   The Prefix Length is an 8-bit unsigned integer that indicates the
   number of (leading) bits in the destination prefix which are part of
   the network part of the address.

===

   The Destination Prefix contains Prefix Length significant bits of the
   destination prefix.  The remaining bits of the Destination Prefix, as
   required to complete the trailing octet, are set to 0.

I'd like to change this to read:

   Up to 128 bits of destination prefix MAY be present in normal IPv6
   most significant bit first format.  The number of bytes present
   is determined by the suboption length.
   The receiving node MUST assume any bits not present are zero.
   The receiving node SHOULD ignore any bits present but not required,
   setting them to zero.
   
Note that this is a subtle change, I think.  If not the original text
ambiguously permitted this.   If your prefix is, for instance,
2001:4830:16ca::/64, you need to transmit only the first 6 bytes. You do
not need to transmit the 2 bytes of zeros between bits 48 and
64. Obviously, you do not need to transmit 8 bytes of zeros from 64 to
128. 

Also note that this also implies an implementation can just send all 128
bits if it likes --- it's dumb and wasteful, but it's legal.  As all
implementaitons will have to validate that there are in fact "Prefix
Length" of data available before using the data, this won't in fact
change any well written code. (If you did not check, buffer overflow...)

A downside is that this introduces a possible covert channel, but I
don't think it's relevant.

<PREMATURE OPTIMIZATION>
Also this opens up a possibility that the prefix length can be derived
from the option length, plus 3 bits of the reserved field.  Maybe that's
what was written in a previous draft...
</PREMATURE OPTIMIZATION>

(I notice that rpl-04 removed the alignment requirement. I agree with
that)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 







      



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSwGfZ4CLcPvd0N1lAQLrmQf+O8xlggvoBhBFL3mtxnJzKXeRtWfBi39h
Fv29t8kVnkg5AcPpwuVFK+TT75TqjzNqvQLQgZV32ijb1UVkmxH6yfdgJuER4jSF
7mwdbHa4a9OqQp4HonTGVpf0nYFvIKJykRI7A06C7VRyZIwBpH4Af+HOD18z9emf
UnlIOIbMrmpozaFdUByKqdVIotBaFD8jegAoSc41Jo2oLbIgvvIMQkDP972ylpk7
6lGln/ApE0fcSnSpvLCgcVKjEA6yqgyEd+ClqEgBINv8YhFrXyGMI2fKpJrfy63X
S+UdPO8wSgs/mRt6BQCkMtJehPBiCEJMVx2BI27uAgcW/1R/yJr80Q==
=jIKh
-----END PGP SIGNATURE-----