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

[John Paul Morrison]

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.

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.

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.

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
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.

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.


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.

For some (imaginary) router you would simply have:

interface loopback 0
  ipv6 address 1234:5678::1/128    ! real world address of router or host
ipv6 router ospf 1
  prefix 1234:5678::/48
  area 0 prefix-length 64
interface ethernet 0
 ipv6 address eui-64
 ipv6 enable
 ipv6 ospf 1 area 0
!
inteface ethernet 1
 ipv6 address eui-64
 ipv6 enable
 ipv6 ospf 1 area 0
!

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.



Paul_Vixie at isc.org wrote:
>> 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.
>>     
>
> 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
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070530/15201a99/attachment.htm>