Re: Introducing draft-denog-v6ops-addresspartnaming

[Robert Bonomi <bonomi () mail r-bonomi com>]

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