Hello,
RFC5996 gives structures of messages using tables. E.g. section 3.15.1 (see
excerpt below) gives the configuration attribute format as follows:
-----------------------------------------------------------------------------------------------------------------------
3.15.1. Configuration Attributes
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Configuration Attribute Format
...
-----------------------------------------------------------------------------------------------------------------------
RFC5996 contains statement (see excerpt below) on octet order in multi-octet
fields, but does not seem to contain a statement on bit order in an octet.
Thus, e.g. it is not clear whether the R field in the figure above the most
significant bit or the least significant bit of the 1st octet.
--------------
3.1. The IKE Header
...
All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or
"network byte order").
...
--------------
I assume that RFC5996 follows
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt description
stating "bit zero is the most significant bit in a word or a field". Is this
correct understanding?
If so, the R field in the figure above would be the most significant bit of the
1st octet.
Thanks for clarification.
Kind regards
Ivo Sedlacek
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
