[ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: Those pesky ULAs again)

[Jeroen Massar]

[two-reply-in-one-special-bonus-shortcut-message]

Paul_Vixie at isc.org wrote:
>> But why would anybody want  to 'ban' EUI-64 configured addresses?
> 
> because if it remains in the standard, then everybody will have to support
> it and networks will have to be allocated on /64 boundaries for all of the
> yet-unborn IPv6 capable SNMP-monitorable door knobs.
[..rest snipped as we agreed there ;).. ]

We are starting to get into an IETF thing here and not policy anymore
I guess. Though if a /64 boundary doesn't exist any more, then the HD
ratio fails through and we have to revise all the policies and the
1000 odd existing allocations about this.

So I understand correctly here that you are afraid that IPv6 enabled
sensors in your carpet will only be relying on a /64 RA to be
available? Unfortunately there is no RA for non-/64 spaces defined,
one could easily generate a shorter address using the same mechanism
and cutting it down and doing DAD or using the mechanism used for IPv4
link local addresses (yes, IPv4 has that to nothing special in IPv6 :)

A possibly better way to solve that problem is to require the support
for DHCPv6 in all nodes, or have at least a sticker on the box "DHCPv6
supported" so that you know what to expect. The DHCPv6 request will go
over a /64 LL of course. Also in case you come across such a device
you can always special case that subnet and give it a /64 out of the
65k ones you get for a site.


Dan.Thorson at seagate.com wrote:
> Jeroen Massar said:
>> But why would anybody want  to 'ban' EUI-64 configured addresses?
>>
>> Your own network is exactly that: your own network.
>>
>> There is *NO* requirement at all to use EUI-64.
>  [snip]
>
> OK, here's where I may express my ignorance... but RFC2373
> explicitly states:
> (in section 2.4, just after the table of prefix allocations)
>
>  (2) The format prefixes 001 through 111, except for Multicast
>      Addresses (1111 1111), are all required to have to have 64-bit
>      interface identifiers in EUI-64 format.  See section 2.5.1 for
>      definitions.

I always read that "when using a /64 prefix size you have to use
EUI-64". One of the main reasons for EUI-64 is that it is more or less
collision free. When using RA's, which will be the common case when
using a network sized /64 you don't want these collisions.

Also I don't see a MUST there so I don't see a real requirement.


A bigger question in this are actually is, what space do you save with
it? It is indeed a lot of waste when you only have 2 IP addresses (box
+ gateway) on a link which will never ever have more IP addresses on
that link, but does it matter much in the global picture. When you get
a /48, you have 65536 of such links. When you get a /32 you get a
well, IPv4 space sized amount of of them. So does it really hurt?

IMHO using /64's is not a bad thing. If you don't want to use them,
then, as said, don't.

> To me that sounds like there is indeed a requirement to use EUI-64.
> The issue then becomes if you purchase a device which is
> RFC-complient then it may not support non-EUI-64 addressing.  Right?

RFC-compliant is always a fight of interpretation. The standard is the
one that everybody uses. At the moment that means that everybody picks
for themselves, as such the standard is both.

My ISP for instance also gave me a an IPv6 IP for my DSL link out of a
/80. This simply for management purposes. They did route a /48 to the
endpoint and point DNS for the /48 it to my endpoint though:

eth1      Link encap:Ethernet  HWaddr 08:00:2B:E7:02:B3
          inet addr:213.136.24.43 Mask:255.255.255.0
          inet6 addr: 2001:7b8:5:10:74::2/80 Scope:Global
          inet6 addr: fe80::a00:2bff:fee7:2b3/64 Scope:Link

The LinkLocal is a /64 though, and that is used as the nexthop:

PING ff02::1(ff02::1) from fe80::a00:2bff:fee7:2b3 eth1: 56 data bytes
64 bytes from fe80::a00:2bff:fee7:2b3: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from fe80::202:4aff:fe8a:a000: icmp_seq=1 ttl=64 time=18.3 ms
(DUP!)

Which, if you know how EUI-64 works, shows that at least Vendor C
doesn't care about this. Which is at least one very large chunk of
deployed routers.

And that works like a charm (thank you very much venerate BIT.nl :)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070604/c61427f4/attachment.sig>