<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
There's some good points but:<br>
<br>
- how do you get collisions? If even if a 48 bit MAC address is
duplicated, this only impacts a layer 2 network. If you have a router,
you have a FIB that can sort out whether two duplicate MACs are
attached to different interfaces - no collisions there.<br>
<br>
- subnets aren't necessarily small in a service provider network. So
Appletalk with 16 bits wouldn't scale onto a cable-modem head end. <br>
We live in a 48 bit MAC world - ethernet, bluetooth, fiber channel etc,
I suppose 64 bits was just building in some future proofing.<br>
<br>
- I think it's been pointed out already that other size subnets do work<br>
<br>
- you can obscure your mac address in software, and a random mac
address doesn't give much more information than a random IP address.<br>
<br>
- your link local IP address does change but this should be
meaningless. You never configure BGP or OSPF router-id's based on a
physical IP address<br>
anyway. It should always be a loopback, virtual interface. With eBGP,
current IPv4 practice typically uses the interface address, but people
do use<br>
loopbacks on occasion even with IPv4 eBGP sessions, and often with
multihop. I see any confusion here as a dependency on IPv4 router
configuration syntax.<br>
<br>
It's just link-local, so for a router (not that it's applicable to
routers) it would be like an un-numbered interface only for Ethernet. <br>
Router-id's and areas would always be administered. <br>
<br>
For a host I don't think it's any different (or it shouldn't be), but I
may be getting out of my v6 depth here. <br>
A basic host/user wouldn't care. An important server would configure
other virutal addresses which could live on top of multiple link local
IP addresses,<br>
and connectivity would survive if one interface went down. (whether
ICMPv6 properly deals with hosts updating the routers, I'm not sure).<br>
<br>
And what's so sacred about a static, physical IP address, as opposed to
a static (or even DHCP) virtual IP address?<br>
My laptop loses it's connections every time I disconnect from my wired
network and enable my own wireless. <br>
Or I lose connectivity while my wireless is working, and plug in to a
live ethernet port and a static IP address but a dead gateway. <br>
<br>
Some of this stuff needs to get away from physical addressing anyway to
make things work.<br>
<br>
When we start having IPv6 and EUI-64, link local only connectivity down
in USB devices, blue-tooth or whatever, it'll be much more appreciated<br>
for the fact that you don't have to know or care about addressing,
service discovery etc. Plug in your new hard disk, let the IPv6 stacks<br>
talk to each other automatically, either OS to device, or more likely
embedded Linux SATA controller talking to the embedded Linux SATA
target/disk drive.<br>
<br>
<br>
Leo Bicknell wrote:
<blockquote cite="mid:20070530215313.GA53938@ussenterprise.ufp.org"
type="cite">
<pre wrap="">In a message written on Wed, May 30, 2007 at 12:56:15PM -0700, John Paul Morrison wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> I'm curious about the opposition to EUI64. The process for numbering
</pre>
</blockquote>
<pre wrap=""><!---->
It's quite simply the worst of all worlds. Pick your reason:
* 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?
* 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 still have to handle collisions. Duplicate addresses are bad.
Are you going to let your PBX get taken out for even a few seconds
because of a collision with a duplicate address by stateless autoconfig?
* It's a permanent cookie that identifies the user.
* 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.
* 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?
* 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.
* 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. (DHCP6)
* Users with servers are going to fixed assign them, in order, from the
bottom, because they put in static DNS, IP's in load balancers, and so
on. The protocol dictates these uses waste on the order of 56+ bits.
* 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.
* 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?
When it comes to "auto configuration", AppleTalk did it easier, DECNet
did it better. The market has spoken.
</pre>
<blockquote type="cite">
<pre wrap=""> EUI64: I know stateless auto-config isn't for routers, but that
doesn't mean some protocol like it couldn't be used to bring up router
interfaces betwewen the same OSPF/IS-IS area. There's often no point
to having an IP address on an interface, when a link local or
unnumbered address would do. Other protocols don't even use them
explicitly.
</pre>
</blockquote>
<pre wrap=""><!---->
There's lots of reasons to have IP's unique IP's on a router interface:
* So you can set up DNS to make traceroute et all useful.
* So you can configure protocols like BGP, MSDP, IPSec and others to it.
* So you can explicitly reach the device over various paths.
* So you can test the device on specific interfaces.
* So you can have physical addresses independent of virtual addresses.
I'm sure I forgot a few.
</pre>
<blockquote type="cite">
<pre wrap=""> For some (imaginary) router you would simply have:
</pre>
</blockquote>
<pre wrap=""><!---->
Humm, smells like DecNet to me.
</pre>
<blockquote type="cite">
<pre wrap=""> Nowadays, hosts often have multiple, dynamic interfaces, so it would
be nice to have a single host identifier, and let eui64 and icmp
router solicitation or
other dynamic protocols figure out the routing.
</pre>
</blockquote>
<pre wrap=""><!---->
No they don't. I don't know where people get this crazy idea.
Yes, my laptop has wired and wireless ethernet. The times I go
between the two are few and far between. When I do, it's because
one is broken, and there's no state to move to the other connection.
Yes, my server has two ethernet ports, plugged into the same VLAN
on two different switches, running NIC Teaming so both are never
active at the same time, and sharing a virtual address.
I would venture that less than 1/100th of a percent of all machines
on the Internet right now have two active interfaces in two different
subnets. I'll bet 80% of them are routers of some sort. Think of all
the home PC's...the work desktops, the vast numbers do NOT have two
connections. Of the legit servers that are on two networks, most are
front end / back end splits, and they are not dynamic, and they do not
interchange in any way.
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a></pre>
</blockquote>
<br>
</body>
</html>