1

I am having a doubt about how to store IPv6 addresses on my system. On my system I accept a packet from the network run statistics on it and send it forward.

I have read the that common way to store it is in big-endian(network order) regardless of the endianness of the CPU. Although several colleagues of mine said they also familiar with this notation no one including google couldn't give a concrete explanation of why its the customary tradition.

The way I see it, the data will be accessed many times in the system so isn't it simpler to change it to host-order(on my case its little-endian) and use it on the entire system without having to run ntoh calls each time I want to run some arithmetic operation on it, and simply change it to network-order if I want to use this address on a packet I want to send back on the network?

antonpuz
  • 3,256
  • 4
  • 25
  • 48
  • What are you using the addresses for, in a way that requires them to be kept in host order? – E_net4 Mar 08 '15 at 16:08
  • 2
    There doesn't seem to be any point to host order vs. network order - it's not like you're going to be doing arithmetic on chunks of an IPv6 address. – nobody Mar 08 '15 at 16:09
  • @AndrewMedico on my case I do have arithmetic operations, like comparing between two ip addresses to find the bigger one or increasing the address by 1 to get the next address – antonpuz Mar 08 '15 at 16:16
  • 1
    "bigger one"? What does "bigger" mean? And why do you do +1? ("next address"? Are you network scanning or something?) – Yakk - Adam Nevraumont Mar 08 '15 at 16:22
  • 2
    See https://stackoverflow.com/questions/13514614/why-is-network-byte-order-defined-to-be-big-endian – cremno Mar 08 '15 at 16:24
  • Even though this question is not a duplicate of that one, because the OP is not asking *why the addresses are big-endian in the protocol*, but why users of the addresses implement software that keep it big-endian. But in the end, that question will lead to the same fatality: *closed as not constructive*, because the question is too broad and lead to personal opinions. – zmo Mar 08 '15 at 16:26
  • And then there's the issue of any [advantages little endian has over big endian](http://programmers.stackexchange.com/questions/95556/what-is-the-advantage-of-little-endian-format). And of course Wikipedia describes a ["middle endian" format](http://en.wikipedia.org/wiki/Endianness#Middle-endian) that AFAIK is no longer common, if existing at all. As an aside, this may not be constructive, but it's still quite fascinating. If you can help it, depending on what you're actually doing, I'd suggest not even converting the IP addresses; just keep them in host byte order if possible. –  Mar 08 '15 at 16:35
  • You really need to proof-read your post before posting... – thang Mar 08 '15 at 17:25

2 Answers2

1

The reason is as simple as: because RFC-1700 says so.

Following a three-decade dispute over which endianness is the single "correct one", Danny Cohen published On Holy Wars and a Plea of Peace in an attempt to shed light into the problem (which is deeper than just "byte order") and with the futile hope that the industry would agree on one consistent order.
The bottom line was that as long as you transmit a message as "one message", there is no such problem as order, but as soon you transmit sub-parts in the message (words, bytes, or bits) you need to decide for one order. It does not matter much which one you choose as long as you stick to your decision. The debate about which order is more correct than the other was as unproductive and silly as the debate on how to break an egg in "Gulliver's Travels", which Cohen referred to and took the name "endianness" from.

In 1994, the authors of RFC-1700 decided to end the debate, at least as far as the IP suite was concerned, by stating:

The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data in "big-endian" order. That is, fields are described left to right, with the most significant octet on the left and the least significant octet on the right.

Every RFC thereafter has followed (explicitly or silently) that convention, which of course includes IPv6.

Practically speaking, it doesn't matter what byte order IP addresses are. They could be words or bytes in little-endian or big-endian, or nibbles, or they could be counting Quatloos if the implementors deemed that practical.
For 99% of all people, 99% of the time, it makes zero difference because neither are you supposed to look at or understand the address, nor do you need to remember "magic values", nor do you (normally) need to modify an address.

You usually get an opaque block of memory that is an IP address and port from "somewhere" (say, getaddrinfo or recvfrom) and you use that blob as-is, e.g. with socket or sendto.
You do not normally need to perform "math" on the address, or anything similar. At best, you might want to compare two addresses for equality.

Yes, applications that need to perform more complicated things with addresses exist, but they are by far the minority of applications.

Community
  • 1
  • 1
Damon
  • 67,688
  • 20
  • 135
  • 185
-1

The way I see it, the data will be accessed many times in the system so isn't it simpler to change it to host-order(on my case its little-endian) and use it on the entire system without having to run ntoh calls each time I want to run some arithmetic operation on it, and simply change it to network-order if I want to use this address on a packet I want to send back on the network?

Well, you're right to wonder about this, but I believe that what you call customary tradition, is just a design choice when doing an application.

I might reverse your question: when you don't need to do any arithmetics on the addresses, why get into the trouble of reversing the order twice just for the sake of keeping it into the host's order?

If your application does a lot of maths on the IP address, it might be indeed smart to reverse it to little-endianness and reverse it before sending it back. But if you do not do any maths on it, then just keep it big-endian. And don't forget that the x86 is not the only CPU around, you also got other host architectures, like ARM or PPC, that were big-endian until they became bi-endian.

zmo
  • 24,463
  • 4
  • 54
  • 90