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>> 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.