Subject: Re: Re: Endianness of IPv6 and payloads

From: Tim Enos <[email-masked]>
Date: Thu, 14 Sep 2006 15:40:43 -0500 (CDT)

>From: Iljitsch van Beijnum <[email-masked]>
>Date: 2006/09/14 Thu PM 02:26:39 CDT
>To: [email-masked]
>Cc: IETF IPv6 Mailing List <[email-masked]>
>Subject: Re: Endianness of IPv6 and payloads

>On 13-sep-2006, at 20:15, Bob Hinden wrote:
>
>> In my personal view, while this is a nice theoretical problem, no  
>> evidence has been presented that anyone building an implementation  
>> is confused about it.  For example, were there ever any  
>> interoperability problems because someone did this wrong?  Common  
>> sense would indicate that IPv6 has the same "endianness" as IPv4.
>
>> I have hard time understanding why documenting this further this  
>> would be a good use of anyone's time (i.e., individuals, IPv6 w.g.,  
>> ADs, IETF, RFC-Editor, ....).
>
>Well, I think it's a pretty big oversight that this was never  
>standardized in any of the IPv6 RFCs. Now obviously there are many  
>interoperable implementations so it doesn't matter in the real world,  
>but that's no reason to let this slide.
>
>I can tell you from experience that showing up for interop testing  
>after implementing some specification and seeing that the other side  
>uses the opposite byte ordering is no fun. And then arguing with the  
>people who wrote the spec about whose interpretation is the correct  
>one is even less fun.

Given the interoperability issues cited by some, and the absence of standardization cited by others, I'd agree that IPv6 "endianness" ought to be standardized. 

While one can likely logically infer that IPv6 is big-endian, codifying it should eliminate doubt (leaving little to no room for debate/confusion, ala RFC 791, Appendix B for IPv4).

Just my two cents...

Best regards,

Tim
Rom 8:28

>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Fri, 15 Sep 2006 00:31:33 +0300

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).

---

From: "Su Thunder" <[email-masked]>
Date: Fri, 15 Sep 2006 14:41:50 +0000

Hi every body,I noticed this issue very long ago, but I always think the 
byte order of IPv6 header is big endian.But I'm not so sure for the 
payload.If an application or user want to use little endian in the payload 
and it has assurance that the recipient knows this,it can use any of 
them.Payload is not a specific conception.
But it is better to specify every thing in the RFC.

>From: Markku Savela <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], [email-masked]
>Date: Fri, 15 Sep 2006 00:31:33 +0300
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 15 Sep 2006 15:39:40 -0400

> 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