[153452] in North American Network Operators' Group
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
daemon@ATHENA.MIT.EDU (Steve Clark)
Wed Jun 6 16:04:51 2012
Date: Wed, 06 Jun 2012 16:02:42 -0400
From: Steve Clark <sclark@netwolves.com>
To: Owen DeLong <owen@delong.com>
In-Reply-To: <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com>
Cc: 'NANOG list' <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 06/06/2012 03:05 PM, Owen DeLong wrote:
> It is because of IEEE EUI-64 standard.
>
> It was believed at the time of IPv6 development that EUI-48 would run o=
ut of
> numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't
> quite made that change (though Firewire does appear to use EUI-64 alrea=
dy),
> it will likely occur prior to the EOL for IPv6.
>
> There is a simple algorithm used by IEEE for mapping EUI-48 onto the EU=
I-64
> space.
>
> The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indi=
cating that
> the address was locally generated (if it is a 1) vs. IEEE/vendor assign=
ed (if it is a 0).
>
> The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps=
> it as follows:
>
> let AA =3D XX xor 0x02.
>
> AAYY:ZZff:feRR:SSTT
>
> ff:fe above is literal.
>
> IPv6 was originally going to be a 32-bit address space, but, the develo=
pers
did you mean "originally going to be a 64-bit address space"...
> and proponent of SLAAC convinced IETF to add 64 more bits to the IPv6
> address for this purpose. Since bits are free when designing a new prot=
ocol,
> there really was no reason to impose such limitations.
>
> You really don't gain anything by going to /80 at this point. There are=
more
> than enough addresses available in IPv6 for any foreseeable future even=
> with /64 subnets.
>
> Owen
>
>
>
>
> On Jun 6, 2012, at 7:58 AM, Chuck Church wrote:
>
>> Does anyone know the reason /64 was proposed as the size for all L2 do=
mains?
>> I've looked for this answer before, never found a good one. I thought=
I
>> read there are some L2 technologies that use a 64 bit hardware address=
,
>> might have been Bluetooth. Guaranteeing that ALL possible hosts could=
live
>> together in the same L2 domain seems like overkill, even for this grou=
p.
>> /80 would make more sense, it does match up with Ethernet MACs. Not a=
s easy
>> to compute, for humans nor processors that like things in 32 or 64 bit=
>> chunks however. Anyone have a definite answer?
>>
>> Thanks,
>>
>> Chuck
>>
>> -----Original Message-----
>> From: Jean-Francois.TremblayING@videotron.com
>> [mailto:Jean-Francois.TremblayING@videotron.com]
>> Sent: Wednesday, June 06, 2012 10:36 AM
>> To: anton@huge.geek.nz
>> Cc: NANOG list
>> Subject: IPv6 /64 links (was Re: ipv6 book recommendations?)
>>
>> Anton Smith<anton@huge.geek.nz> a =E9crit sur 06/06/2012 09:53:02 AM =
:
>>
>>> Potentially silly question but, as Bill points out a LAN always
>>> occupies a /64.
>>>
>>> Does this imply that we would have large L2 segments with a large
>>> number of hosts on them? What about the age old discussion about
>>> keeping broadcast segments small?
>> The /64 only removes the limitation on the number of *addresses* on th=
e L2
>> domain. Limitations still apply for the amount of ARP and ND noise. A
>> maximum number of hosts is reached when that noise floor represents a
>> significant portion of the link bandwidth. If ARP/ND proxying is used,=
the
>> limiting factor may instead be the CPU on the gateway.
>>
>> The ND noise generated is arguably higher than ARP because of DAD, but=
I
>> don't remember seeing actual numbers on this (anybody?).
>> I've seen links with up to 15k devices where ARP represented a signifi=
cant
>> part of the link usage, but most weren't (yet) IPv6.
>>
>> /JF
>>
>>
>>
>
>
--=20
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@netwolves.com
http://www.netwolves.com
