Robert Elz wrote:
Date: Tue, 5 Jul 2005 00:58:36 -0700
From: "Christian Huitema"
<huitema(_at_)windows(_dot_)microsoft(_dot_)com>
Message-ID:
<DAC3FCB50E31C54987CD10797DA511BA0F86C29E(_at_)WIN-MSG-10(_dot_)wingroup(_dot_)windeploy(_dot_)ntdev(_dot_)microsoft(_dot_)com>
| The problem is the really small size of the option type field in IPv6.
| There really only are 5 bits available for numbering both the hop by hop
| and the end to end options. That makes for a grand total of 32, of which
| three are assigned by basic IPv6 specs. So, there really are good
| reasons to be somewhat conservative with the assignments.
It isn't really that bad, the option with 17 in the low 5 bits and 0 in
the upper 3 is a different option than the one with 17 in the low 5 bits and
7 in the upper 3.
So, really there are 8 distint groups of 32 options each.
Well, that is not how I read the text in RFC 2460. It's pretty clear
to me that there are only 32 option codes and that the other three bits
don't extend the code space, but rather they modify the meaning of the
32 basic options. (e.g. the same option can have a hop-by-hop flavour
and an e2e flavour).
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf