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?

Answer 1

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)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Through this struct, what you think is right.