On Sat, 23 Sep 2006 15:27:36 +0200, Joerg Roedel said:
(I assume you are speaking of the position of the 3 in the header). The
RFC is not clear at this point. It defines that the first 4 bits in the
16 bit Ethernet header MUST be 0011. But it don't defines the
byteorder of that 16 bit word nor if the least or most significant bit
comes first.
Unless stated otherwise, it's pretty safe to assume that all "on the wire" data
mentioned in an RFC is in 'network byte order'. That's why hton*() and ntoh*()
functions exist...
Is there something in the RFC that suggests that a byte order other than
'network order' is possible/acceptable there?
On Sun, Sep 24, 2006 at 09:07:43PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Sat, 23 Sep 2006 15:27:36 +0200, Joerg Roedel said:
quoted
(I assume you are speaking of the position of the 3 in the header). The
RFC is not clear at this point. It defines that the first 4 bits in the
16 bit Ethernet header MUST be 0011. But it don't defines the
byteorder of that 16 bit word nor if the least or most significant bit
comes first.
Unless stated otherwise, it's pretty safe to assume that all "on the wire" data
mentioned in an RFC is in 'network byte order'. That's why hton*() and ntoh*()
functions exist...
Yes. Thats what the OpenBSD people did :-)
The problem with the header is the bitorder. The OpenBSD people assumed
that the least significant bits come first in the 16-bit header.
Is there something in the RFC that suggests that a byte order other than
'network order' is possible/acceptable there?
No. The RFC states nothing at all about byte- or bitorder. That is why
the RFC is ambigious at this point.
Joerg Roedel wrote:
quoted
Is there something in the RFC that suggests that a byte order other than
'network order' is possible/acceptable there?
No. The RFC states nothing at all about byte- or bitorder. That is why
the RFC is ambigious at this point.
RFC 791 (IPv4) Appendix B does give instructions on byte ordering for
all IPv4 headers and data, and RFC 791 is listed in the References for
RFC 3378. I noticed this is only Informational, not a Standards track
document, so I guess the non-interoperable implementations kind of go
with the territory.
-Brian