<!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">
I'm curious about the opposition to EUI64. The process for numbering
interfaces seems to have things in common with other protocols like IPX
and Appletalk and a lot like the way IS-IS (of IPv4) is configured on
routers, or how ES-IS would work with hosts. Maybe it's no coincidence,
since Deering was (is?) working for a router vendor at the time IPv6
was designed.<br>
<br>
Maybe everyone was just too excited about plug-n-play hype back in
1995, and it seemed like a good idea to make IPv6 more dynamic, or
maybe we're also so ingrained with IPv4 that we don't think about other
approaches. <br>
<br>
It seems pretty straight-forward to configure a network prefix (/48 or
whatever), which may be overloaded into an area identifier - for
OSPFv6, IS-IS etc, and a unique /128 host identifier to a box, whether
it's a router or a host. <br>
<br>
You've mentioned the split between EID/RID, and I don't know that
that's *not* possible with IPv6 - I would think that v6 flow labels,
header stacking and/or OSPF opaque LSAs and/or MPLS could all work
here to keep routing scalable. Some consensus I got out of reading the
IETF 68 was that there's no need for panic about routing in the short
term, and on the other hand there's no clear solution long term - in
other words the technology is still evolving. If it's still evolving
now, I don't know how it could have been designed<br>
any better in 1995 - and IPv6 did go from 64 bits to 128 bits during
design and added other hooks to help it evolve. Since IPv6 had to be a
real world protocol, it also had to make some tradeoffs so it could be
implemented in real (1995) routers, while keeping the door open for the
future.<br>
<br>
Taking a guess here, I'm wondering if what you're thinking of is how to
work E.164 or variable length NSAP addresses + Bind into IPv6 routing.<br>
<br>
<br>
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.<br>
<br>
For some (imaginary) router you would simply have:<br>
<br>
interface loopback 0<br>
ipv6 address 1234:5678::1/128 ! real world address of router or
host<br>
ipv6 router ospf 1<br>
prefix 1234:5678::/48<br>
area 0 prefix-length 64 <br>
interface ethernet 0<br>
ipv6 address eui-64 <br>
ipv6 enable<br>
ipv6 ospf 1 area 0 <br>
!<br>
inteface ethernet 1<br>
ipv6 address eui-64 <br>
ipv6 enable<br>
ipv6 ospf 1 area 0 <br>
!<br>
<br>
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<br>
other dynamic protocols figure out the routing.<br>
<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Paul_Vixie@isc.org">Paul_Vixie@isc.org</a> wrote:
<blockquote cite="mid:30761.1180458872@sa.vix.com" type="cite">
<blockquote type="cite">
<pre wrap="">You're always going to be looking at a sparse /64, you've got
18446744073709551616 addresses. But you need it if you want to do eui64.
</pre>
</blockquote>
<pre wrap=""><!---->
sadly, eui64 is in the standard, and it would take a flag day to remove it.
so while i expect folks to switch from stateless address autoconfiguration
to DHCPv6 to get some auditing and to be able to set config knobs like name
server lists and so on, i believe that everybody will always use /64's for
LANs, since some embedded devices will always demand EUI64. so there's no
way to get the address space back, and IPv6 is as leo said, effectively the
same size as a 72 bit address space.
(note well, there was an urban legend about the /64 boundary being present
in silicon on some switch or router, but in my own testing, every C and J
router i laid hands on was able to work with /96 or /120 netmasks on
connected LAN interfaces, forward to them without using more CPU time than
a connected /64, receive routes, and advertise routes. so at the moment,
"/64 is hardwired into router silicon" is just an urban legend to me. if
you want to argue this point, plz provide session traces and rev levels.)
_______________________________________________
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>