Is network byte order pointless under IPv6?

Question

If we use a 32-bit integer to store an IPv4 address, then the byte order of the integer must be considered.

However, as there is no built-in 128-bit integer type under almost all platforms, an IPv6 address must be stored into a byte array, so, I think the byte order is no longer a problem.

Am I correct? Or is there a corresponding function htonlXXX for IPv6?

All the data can be organized as a byte stream. IPv6 doesn't care data formats it sends. — xmllmx, Jan 13 '13 at 08:49
@xmllmx: by that reasoning you don't need it either for IPv4. — Mat, Jan 13 '13 at 08:50
GCC provides `__int128_t` for enough platforms that I think your "no built-in 128-bit integer type under almost all platforms" claim is wrong. Intel also provides a similar type. — , Jan 13 '13 at 08:51
@Mat, but the IP address is generated by the system, rather than the application itself. So the byte order must be considered. The byte order may be different under different systems. — xmllmx, Jan 13 '13 at 08:52
@xmllmx So? The question doesn't say there's a *standard* 128-bit integer type on almost no platforms. — , Jan 13 '13 at 08:54
"The byte order may be different under different systems." Precisely, and that doesn't change with IPv6. Byte ordering is just as important in the same scenarios. Maybe the address itself can be handled differently, but the rest of the data didn't magically become endian-agnostic. — Mat, Jan 13 '13 at 08:55
@hvd, I have said "ALMOST" rather than "ALL", so you and I are both correct. ;) — xmllmx, Jan 13 '13 at 08:57

mrbultitude · Accepted Answer · 2013-01-13T13:30:11.287

IPv6 does require network byte order for ipv6 addresses. hton and ntoh are all about converting the address from how you have it stored in your code, to how it needs to be stored in the packet (and vice-versa). So the issue becomes how you have it stored in your code.

Also the definition of an IPv6 address in code can allow more ways to address it than just an array of bytes:

struct in6_addr
{
    union 
    {
        __u8 u6_addr8[16];
        __u16 u6_addr16[8];
        __u32 u6_addr32[4];
    } in6_u;
#define s6_addr in6_u.u6_addr8
#define s6_addr16 in6_u.u6_addr16
#define s6_addr32 in6_u.u6_addr32
};

IPv6 addresses, to the user, are represented as 8 16-bit values. If you have the address stored as 8 16-bit values in your code, then you will need to use htons on each 16 bit value as you place it into the packet using the u6_addr16[] array, and use ntohs as you retrieve each 16-bit value from u6_addr16[].

These links are helpful:

http://msdn.microsoft.com/en-us/library/ee175867.aspx

http://en.wikipedia.org/wiki/IPv6_address (especially the diagram at top right)

Thank you very much, mrbultitude. I noticed that this is your first post in StackOverflow. Special thanks for your two links. — xmllmx, Jan 13 '13 at 12:35
Are you sure that's right? If you have an IPv4 address stored as an array of two uint16_t values, doing htons on each half is not the same as doing htonl on the whole uint32_t address. — , Apr 30 '13 at 08:34

score 4 · Answer 2 · answered Jan 13 '13 at 09:06

Network byte ordering was useful in 2 situations. Firstly, you could use it on the address as you have stated. Secondly, you must consider the byte ordering of the data you are sending. You are right in saying in the comments that TCP is just a byte stream, but a lot of protocols dictate byte ordering of numbers as network ordering.

score 4 · Answer 3 · answered Jan 13 '13 at 10:17

However, as there is no built-in 128-bit integer type under almost all platforms, an IPv6 address must be stored into a byte array, so, I think the byte order is no longer a problem.

That does not follow; when you construct the byte array, you still have to consider whether you pack the data in 0123456789ABCDEF or FEDCBA976543210 order. Correct byte ordering is still required, it is simply that functions such as ntohl() and htonl() are not applicable in generating a 128 bit address.

If you generate the binary address from the "presentation" form using inet_ntop() for example, you do not need to consider byte order yourself for either address type. Byte order is still critical, but the API will have handled it for you.

Steve Jessop · Answer 4 · 2013-01-13T13:25:21.407

The specific reason that you have to pay close attention to byte-order when handling IPv4 address and port numbers, is that the structures sockaddr_in and in_addr have data members with integer types larger than char, and whose contents are required to be in network byte order.

Even with IPv4 you can avoid worrying about the byte-order of the address part of that -- use inet_aton or inet_pton to fill the in_addr directly from a string. The latter function does IPv6 addresses too (filling an in6_addr).

When using IPv6 you still need htons for the port number, and you will need host/network conversion if you choose to access an in6_addr in chunks bigger than a byte.

As you say, if your platform doesn't have a 128 bit type then you can't access an in6_addr as a single 128-bit chunk in the way that you might have accessed in_addr as a single 32-bit chunk. But if some networking interface/implementation with a 128 bit type ever does decide to expose a 128-bit view of it, then hopefully it will also provide matching ntohX and htonX functions.

score 1 · Answer 5 · answered Jan 13 '13 at 08:54

1

struct in6_addr{
　　uint8_t s6_addr[16];//128bit ipv6 address
};

Through this struct, what you think is right.

answered Jan 13 '13 at 08:54

laifjei

606
2
7
16

Is network byte order pointless under IPv6?

5 Answers5

Related