> From nanog-bounces+bonomi=mail.r-bonomi....@nanog.org Fri Nov 19 14:18:02 > 2010 > Date: Fri, 19 Nov 2010 12:19:34 -0800 > From: Joel Jaeggli <joe...@bogus.com> > To: Owen DeLong <o...@delong.com> > Subject: Re: Introducing draft-denog-v6ops-addresspartnaming > Cc: bmann...@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.