Subject: [dnsext] "Network bit order" in RFC 3845

From: Stuart Cheshire <[email-masked]>
Date: Wed, 22 Apr 2009 11:55:42 -0700

RFC 3845 says:

    Each bitmap encodes the low-order 8 bits of RR types within the
    window block, in network bit order.  The first bit is bit 0.

What the hell does that mean?

Of course the "first" bit is bit 0. Everyone agrees on that. The  
problem is that people don't agree which bit is "first", hence the  
need to specify an order.

A Google search for "network bit order" finds... drum roll... RFC  
3845. Not very helpful.

Is bit 'x' the bit with value 2^x, or the bit with value 2^(n-1-x)  
(where 'n' is 8 in this case, because we're dealing with 8-bit bytes)?

 From the example later in the RFC, I'm guessing the latter.

So this means that we're assuming big-endian bit order within the  
byte (i.e. the "first" bit is the most significant one).

However, also from the example, it appears that the order of the  
bytes in the 256-bit bitmap is little-endian (i.e. the least  
significant bits, 0-7, go in the first byte, the next most  
significant bits, 8-15, go in the second byte, and so on).

So in summary:

The order of the bytes in the block is little-endian (first byte is  
least significant eight bits of the 256-bit bitmap)
The order of the bits in each byte is big-endian (the first bit of  
each group of eight goes in the most significant bit of the byte)

i.e. the expression to see if bit 'x' is set is not:

if (byte[x/8] & (1 << (x%8))) // then bit x is set

but in fact:

if (byte[x/8] & (1 << (7 - (x%8)))) // then bit x is set

As x increases, we move forward through the bytes in the block, but  
backwards through the bits of each byte.

Do I have that correct?

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 22 Apr 2009 20:26:12 -0400

You wanted to look up "network order" which is mentioned in many RFCs
starting at least as early as RFC 1235.
Donald

On Wed, Apr 22, 2009 at 2:55 PM, Stuart Cheshire <[email-masked]> wrote:

> Of course the "first" bit is bit 0. Everyone agrees on that. The problem is
> that people don't agree which bit is "first", hence the need to specify an
> order.
>
> A Google search for "network bit order" finds... drum roll... RFC 3845. Not
> very helpful.
>
> Is bit 'x' the bit with value 2^x, or the bit with value 2^(n-1-x) (where
> 'n' is 8 in this case, because we're dealing with 8-bit bytes)?
>
> So this means that we're assuming big-endian bit order within the byte
> (i.e. the "first" bit is the most significant one).
>
> However, also from the example, it appears that the order of the bytes in
> the 256-bit bitmap is little-endian (i.e. the least significant bits, 0-7,
> go in the first byte, the next most significant bits, 8-15, go in the second
> byte, and so on).
>
> So in summary:
>
> The order of the bytes in the block is little-endian (first byte is least
> significant eight bits of the 256-bit bitmap)
> The order of the bits in each byte is big-endian (the first bit of each
> group of eight goes in the most significant bit of the byte)
>

-- 
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Apr 2009 14:28:07 +0100

> What the hell does that mean?

I would argue it's meaningless. The Internet is an octet transport medium
and the order of the bits within the octet is invisible. For example,
Token Ring sends bytes in little endian bit order, whereas serial Ethernet
uses big endian bit order, and gigabit Ethernet over copper sends bytes in
parallel.

Numbering of bits is orthogonal to transmission order. RFC 3845 should
have said "leftmost, most significant bit" instead of "first bit" and
noted that this is consistent with network byte ordering. See also the
numbering of bits in the packet diagrams in RFC 793 etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Apr 2009 09:56:49 -0400

> starting at least as early as RFC 1235.

Is this a clarification that ought to be made with, say, an erratum?
(That's not a suggestion, it's a question.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Apr 2009 07:50:33 -0700

>(That's not a suggestion, it's a question.)

Yes, definitely.

--Paul Hoffman, Director
--VPN Consortium