[153451] in North American Network Operators' Group
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Jun 6 15:11:43 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <000d01cd43f4$cdd5bb30$69813190$@gmail.com>
Date: Wed, 6 Jun 2012 12:05:31 -0700
To: Chuck Church <chuckchurch@gmail.com>
Cc: 'NANOG list' <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
It is because of IEEE EUI-64 standard.
It was believed at the time of IPv6 development that EUI-48 would run =
out 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 =
already),
it will likely occur prior to the EOL for IPv6.
There is a simple algorithm used by IEEE for mapping EUI-48 onto the =
EUI-64
space.
The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, =
indicating that
the address was locally generated (if it is a 1) vs. IEEE/vendor =
assigned (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 =
developers
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 =
protocol,
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 =
domains?
> 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 =
group.
> /80 would make more sense, it does match up with Ethernet MACs. Not =
as easy
> to compute, for humans nor processors that like things in 32 or 64 bit
> chunks however. Anyone have a definite answer?
>=20
> Thanks,
>=20
> Chuck
>=20
> -----Original Message-----
> From: Jean-Francois.TremblayING@videotron.com
> [mailto:Jean-Francois.TremblayING@videotron.com]=20
> 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?)
>=20
> Anton Smith <anton@huge.geek.nz> a =E9crit sur 06/06/2012 09:53:02 AM =
:
>=20
>> Potentially silly question but, as Bill points out a LAN always=20
>> occupies a /64.
>>=20
>> Does this imply that we would have large L2 segments with a large=20
>> number of hosts on them? What about the age old discussion about=20
>> keeping broadcast segments small?
>=20
> The /64 only removes the limitation on the number of *addresses* on =
the 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.=20
>=20
> The ND noise generated is arguably higher than ARP because of DAD, but =
I
> don't remember seeing actual numbers on this (anybody?).=20
> I've seen links with up to 15k devices where ARP represented a =
significant
> part of the link usage, but most weren't (yet) IPv6.=20
>=20
> /JF
>=20
>=20
>=20
