From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Fri Nov 19 14:18:02 2010 Date: Fri, 19 Nov 2010 12:19:34 -0800 From: Joel Jaeggli <joelja@bogus.com> To: Owen DeLong <owen@delong.com> Subject: Re: Introducing draft-denog-v6ops-addresspartnaming Cc: bmanning@vacation.karoshi.com, nanog@nanog.org

On 11/19/10 10:56 AM, Owen DeLong wrote:

...

...

It is always two bytes. A byte is not always an octet. Some machines do

It is always two OCTETS. A byte is not always an octet...

Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22 bytes not 16.

<pedant> 3 words of CPU memory (with 50+ bits available to possibly pack 'something else useful' in.) One could get away with 11 words of PPU memory, but that would require pack/unpack on every move between CPU<->PPU address-spaces. </pedant> just implementing a K&R 'C' compiler was a real challenge on that hardware. :)

One can define that byte size for the purposes of the human reading of addresses ipv6 as 8 bits, without getting into machine specific details. what's important to the machine isn't the division of the address into parts (they aren't divided in the machine representation it's just one long row of bits) but rather where the mask falls.

Yup. When talking IP, the 'network byte size' is fixed at 8 bits. This is 'cast in stone', as is 'network byte order', and 'bit order'. If the 'scope' of the term is restricted to Internet protocol/connectivity contexts, one can use 'byte' unambiguously as a referant to an 8-bit qty.