Subject: [IPFIX] Endianness of address types: 5101bis section 6.1.2.

From: Brian Trammell <[email-masked]>
Date: Mon, 22 Oct 2012 13:08:57 +0200

Greetings, all,

I've received a comment off-list from an implementor that section 6.1.2 of 5101 (and 5101-bis) is potentially confusingly worded. The intent here is that all addresses be _encoded_ in big-endian order, regardless of how they are handled internally (e.g., Unix programs often use both host and network byte order for IPv4 addresses: the former for manipulation, the latter for compatibility with the sockets API). "6-octet integers" and "16-octet integers", however, are kind of weird concepts. So I'd suggest the following change:

OLD:

6.1.2. Address Types

   Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
   encoded the same way as the integral data types.  The macAddress is
   treated as a 6-octet integer, the ipv4Address as a 4-octet integer,
   and the ipv6Address as a 16-octet integer.

NEW:

   Address types -- ipv4Address, macAddress, and ipv6Address -- MUST be
   encoded the same way as unsigned integral data types, as four, six, 
   and sixteen octets in network byte order, respectively.

Thoughts?

Thanks,

Brian

---

From: Andrew Feren <[email-masked]>
Date: Mon, 22 Oct 2012 13:39:50 -0400

Hi Brian,

I can't say found the original confusing, but if some people did I don't 
have a problem with the new form.  Or even more simply.

    Address types -- ipv4Address, macAddress, and ipv6Address -- MUST be
    encoded as four, six, and sixteen octets in network byte order, 
respectively.

-Andrew

On 10/22/2012 07:08 AM, Brian Trammell wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 22 Oct 2012 18:44:10 +0100

Brian,

+1 to what Andrew said.

Additionally, please cite an xref for "network byte order".

(Why isn't there an IETF terminology doc for these things?)

Else,

     - RFC 5101 section 3?
     - RFC 1886 or RFC4122?
     - draft-newman-network-byte-order from '99 ?

Thanks,
P.

On 22/10/12 18:39, Andrew Feren wrote:
> Hi Brian,
>
> I can't say found the original confusing, but if some people did I 
> don't have a problem with the new form.  Or even more simply.
>
>> I've received a comment off-list from an implementor that section 
>> 6.1.2 of 5101 (and 5101-bis) is potentially confusingly worded. The 
>> intent here is that all addresses be _encoded_ in big-endian order, 
>> regardless of how they are handled internally (e.g., Unix programs 
>> often use both host and network byte order for IPv4 addresses: the 
>> former for manipulation, the latter for compatibility with the 
>> sockets API). "6-octet integers" and "16-octet integers", however, 
>> are kind of weird concepts. So I'd suggest the following change:
>>
>> OLD:
>>
>> 6.1.2. Address Types
>>
>>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 23 Oct 2012 09:52:43 +0200

Hi, Paul,

Hm. The lack of documentation on network byte order is odd, though I suppose the words "network byte order" are on their own sufficient for any reasonably competent implementor to know what we're talking about. So I think the right thing to do is be very clear that everything in IPFIX is network byte order (as you say, in section 3). 

Will go with Andrew's language, and review 5101bis to ensure that we're as clear about byte order as we need to be elsewhere.

Many thanks, cheers,

Brian

On Oct 22, 2012, at 7:44 PM, Paul Aitken wrote:

>> I can't say found the original confusing, but if some people did I don't have a problem with the new form.  Or even more simply.
>> 
>>   encoded as four, six, and sixteen octets in network byte order, respectively.
>> 
>> -Andrew
>>