[ppml] [address-policy-wg] Those pesky ULAs again

[Iljitsch van Beijnum]

On 30-mei-2007, at 23:53, Leo Bicknell wrote:

>>    I'm curious about the opposition to EUI64.

> It's quite simply the worst of all worlds.  Pick your reason:

Well, IPv6 address configuration certainly _contains_ all worlds:

- IPv4-style manual configuration
- IPv4-style DHCP address assignment
- IPX-style use of the MAC address in the lower bits of the address
- AppleTalk-style use of random numbers in the lower bits of the address

Interestingly, the availability of 64 bits that a host can pretty  
much come up with itself have lead to some innovation in the form of  
crypto-generated addresses that can be used to prove ownership of an  
address. If anything, 64 bits is on the low side for these uses.  :-)

Note that it's not all that useful to complain about IETF work that  
has been done over a decade ago and has since been widely  
implemented. We'll have to live with it until someone comes up with  
something better AND a reasonable upgrade path from the current  
situation to the new model.

That being said, considering that IPv6 addresses are 128 bits so we  
may as well put some of those bits to good use, stateless  
autoconfiguration with EUI-64s is a pretty good system. You just have  
to get rid of some IPv4 thinking to appreciate it.

>
> * EUI-48 is here to stay, even if we run out.  Or are we going to
>   replace every bit of deployed ethernet, fddi, and token ring  
> silicon?

Two out of three ain't bad... But apparently nobody feels we need  
something better than ethernet if we can just increase the bitrate  
once in a while. Note that IEEE 1394 (Firewire) uses EUI-64s.

> * If EUI-64 eliminated the need for duplicate address detection, it
>   would be a step forward.  It doesn't, so we have that code  
> complexity.

We all run OSPF or IS-IS. That's complex. Duplicate address detection  
isn't even a blip on the complexity radar.

> * We still have to handle collisions.  Duplicate addresses are bad.

Sure. If you want to have some fun, configure a host with the MAC  
address of an IPv6 router, then boot up the router. It will be  
completely dead in the water (for IPv6 on that interface at least)  
because it can't complete DAD for its link-local address.

For a long time, I distrusted stateless autoconfig and used manual  
configuration for servers (well, A server) but over the years, it has  
worked so well that I wouldn't hesitate to use it for servers now.

> * It's a permanent cookie that identifies the user.

Mostly a problem for systems that move around: you get to track them  
by their MAC address. RFC 3041 temporary addresses fix this, though.

> * If we assume randomized addresses to fix the cookie issue,
>   and we simply use DAD to make sure there are no duplicates, than  
> it's
>   AppleTalk like, and it did quite happily in 16 bits rather than 64,
>   even with large subnets.

True, but then you couldn't have fixed addresses with stateless  
autoconf, which means back to (some kind of) manual configuration for  
systems that need fixed addresses.

> * Subnets are sparse, and I would argue getting sparser.  Where I had
>   4096 host subnets in 1993, I now have 32 host subnets because  
> virtual
>   interfaces and vlans are now free.  Why would anyone think of
>   providing more host bits?

Does it matter whether you have 4096 hosts in a subnet or 16 with a  
64-bit subnet size?

> * It puts a fixed boundary in the system.  CIDR taught us fixed
>   boundaries are bad.  Fortunately no one has put them in silicon
>   yet, but it will happen, and it will be bad.

I don't get why a fixed 64-bit boundary is mandated in RFC 3513 either.

> * Getting just an address is useless.  You can't even browse just the
>   web without nameservers as well.
> * The system is not extensible to other attributes, so it has to be
>   thrown out entirely.

This is VERY untrue. Router advertisements can have options, and even  
the prefix options have options of their own. New options can be  
defined as needed, and this is exaclty what happened for resolving  
DNS server addresses.

> * Since they are sparse, they make designing robust hardware more
>   difficult.  Your router can't have enough ram for 2^64 entries per
>   subnet, but if it doesn't there's a DDOS potential when you get  
> scanned.
>   You will get scanned, even in IPv6.

Hm, I should test what happens with a neighbor discovery storm some  
time. Since ICMP must be rate limited in IPv6, I'd assume it wouldn't  
be as bad as an ARP storm in IPv4, though.

> * When you swap out hardware, your interface changes, screwing up DNS,
>   access lists, and other items.  Do you want a BGP session that won't
>   come back because you replaced a faulty card?

You do need manually configured addresses for BGP sessions for  
exactly this reason, yes. On the other hand, you _don't_ have to have  
manually configured addresses for any other protocols. I can simply  
tell all routers in a VLAN this:

!
interface TerabitEthernet 39/14.4095
  ipv6 address 2001:db8:31:4095::/64 eui-64
!

This helps with the configuration management.

(Well actually you don't need global addresses to get OSPFv3 or any  
other internal routing protocol working.)

> When it comes to "auto configuration", AppleTalk did it easier, DECNet
> did it better.  The market has spoken.

And it's saying that IP is better than AppleTalk, DECnet, IPX or  
CLNP. And despite its limited deployment, IPv6 does share the big  
advantage of IPv4 for the most part: it has the applications users need.