Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> Is thread trying to say the IPv6 *headers* specified in the IPv6 RFC's > leave the byte order of the header fields unspecified? I never noticed > this omission as an implementor. > > For payloads, the issue is moot, because IPv6 and IPv4 payloads and > upper layer headers are same (or should always be, even if some > protocols are only used currently with IPv6). The thread, or at least I, am trying to say that all mention of byte ordering, be it headers or data, is missing in IPv6. In IPv4 (or IPv6), the upper layer protocols typically don't mention anything about byte ordering either. You have to go back to RFC 791 to be given this info. For example, RFC 793 (TCP), mentions nothing about headers or data byte ordering. But since RFC 791 gives a general rule for IP headers and for IP payload, all the IP payload, in principle the issue is resolved. Some think that RFC 791 Appendix B is ill advised by including all of the payload. And maybe it is. In principle, RFC 791 *could* have said that only the IP header must be big endian. Then, once you have decoded the "protocol" field in the IP header, you can then consult the documentation for that protocol to determine the byte ordering. And go on up the protocol layers that way. But that isn't how it's done in IPv4. The general rule is given at the IP layer and it holds on up the stack. If the topic is brought up at all, it would be exceptions from the general rule only. So, in IPv6, we probably now have to stick with this philosophy. Mainly because IPv6 doesn't change the upper layers. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
