1

Historically, network protocol RFCs have used big-endian (network order) fields.

I am currently involved in the design of a new (UDP) protocol, which, one-day, might be standardised with an RFC.

Would having little-endian fields be a problem with standards committees?

Are there any examples of IETF-standardised protocols which use little-endian byte ordering?

(It does seem rather pointless to use big-endian representations in new protocols, as big-endian architectures are essentially dead.)

fadedbee
  • 42,671
  • 44
  • 178
  • 308
  • Why does the native byte order of your architecture have any bearing on the network serialization format? I'd say simply go for big-endian. – tripleee Apr 06 '18 at 14:15
  • 1
    I doubt they approve directly. Currently IETF standardises only 3rd party protocols/formats with LE, but not own new ones. But if it becomes popular they could make RFC even with LE. – Netch Apr 06 '18 at 14:17
  • 1
    @tripleee It just seems pointless in 2018 for *both* ends to be reversing byte order for compatibility with network-byte-order *in a new protocol*. I'd rather specify little-endian byte order. Are there *any* extant big-endian architectures? – fadedbee Apr 09 '18 at 10:12
  • Are your latency requirements really serious enough that you need for the packets to be immediately machine-readable without any parsing? Perhaps I'm showing my ignorance of realtime requirements but it seems like you are micro-optimizing something which doesn't really matter. – tripleee Apr 09 '18 at 10:19

2 Answers2

1

Kerberos (eg. RFC6542) is a Proposed Standard and used little endian, so do RFC7748 elliptic curves.

Still, getting a new protocol approved that neither has very good reasons ("it's common in elliptic curve calculations" was, as was "Kerberos is already widely deployed"; "all my systems are LE anyway" will probably not be) will probably be not easy and need much discussion; see QUIC's for an example of such a discussion -- and note that QUIC does use network byte order.

chrysn
  • 810
  • 6
  • 19
0

DO NOT USE LITTLE_ENDIAN. Among other things, the classic set of functions for dealing with endians-ness only include the concepts of "host" endian and "network" endian. There's no standard method of dealing with "little" endian.

PESMITH_MSFT
  • 350
  • 1
  • 9