<!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">
<a class="moz-txt-link-abbreviated" href="mailto:Paul_Vixie@isc.org">Paul_Vixie@isc.org</a> wrote:
<blockquote cite="mid:3935.1180556876@sa.vix.com" type="cite">
<blockquote type="cite">
<pre wrap="">I'm curious about the opposition to EUI64.
</pre>
</blockquote>
<pre wrap=""><!---->
i want to know when a host comes onto my network. i want to have a chance
to set a particular address for it. i want to be able to do an RFC2136 DNS
Dynamic Update to set the AAAA and/or PTR RR. i want to be able to tell it
what the local name servers are. and i want to be able to use non-sparse
addressing, such as a /112 (65536 possible hosts) rather than a /64 (which
is 18446744073709551615 possible hosts) per subnet.
</pre>
</blockquote>
<br>
But it seems usable or at least could be improved/built on. Is there a
reason not to have at least /80<br>
on a 48 bit MAC layer? <br>
<br>
If you're building a network within an AS, you just need an
address/loopback for each node or router,<br>
and information about areas - assuming a link state protocol.
Information about "subnets" can be built into the<br>
area ids (you often see OSPF areas represented as IP addresses), it can
be IP unnumbered if the physical<br>
layer supports this, and I've recently seen some IP un-numbered for
Ethernet. <br>
<br>
Isn't it sufficient to push down a routing prefix/area id and then use
the 48 bit MAC for local connectivity instead of bothering with ARP?
If I have a router with 10 ethernets and 10 hosts, do you really need
10 subnets, if they<br>
are all in the same IGP area id and share a common routing prefix? Or
the same with a single cable-modem interface and 10,000 downstream
subscribers - seen lots of IPv4 kludges where you keep adding /24s to
an interface, on top of having to update DHCP.<br>
<br>
Knowing when a host comes on your network doesn't seem any different or
more/less secure than with DHCP, and larger networks will rely on layer
2 mechanisms (802.1x, PAP/CHAP etc). On a large network I would
probably want EUI-64 or something like it, with DHCPv6 simply to hand
out a prefix (area) and DNS, leaving the MAC address as the lower bits.<br>
<br>
Was there a draft or published RFC on what you mention?<br>
<br>
For EID/RID, well who knows what form it will eventually take. Maybe
true border routers/eBGP will just get bigger and bigger, while (fully
meshed) iBGP disappears, freeing core routers to switch labels (wasn't
this the early MPLS promise?) or IPv6 flows or extension headers with
the destination ASN embedded in the IP address. Seems like there are
lots of prefixes, but much fewer AS's and even fewer ways to exit an
AS. <br>
<br>
One hopes a solution will converge :-) Or silicon could outstrip the
public Internet's capacity for growth.<br>
<br>
<br>
<blockquote cite="mid:3935.1180556876@sa.vix.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
you're on the right track. people who i trusted to know what the IETF was
and how it worked, told me in 1995 that IPv6 had "rapid renumbering" as one
of its fundamental design requirements. the idea was to be able to add and
delete prefixes from a LAN as an enterprise added and deleted transit
providers. so, lightweight multihoming would be a side effect of rapid
renumbering. subnets and hosts would have more than one prefix, and each
prefix could have its own exit gateway (or share one).
none of that happened. so the entire dynamic architecture that EUI64 was
supposed to be part of hasn't happened. but unlike 8+8 and A6/DNAME, the
IETF hasn't abolished or deprecated EUI64 (yet?). so we're doing DHCPv6
and letting the market sort out which approach is better.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
i hope i didn't say it wasn't possible. i said the lack of an EID/RID split
was IPv4's major problem, and IPv6 either did nothing to solve it, or made it
worse, or made it harder to solve, or perhaps all three. v6 flow labels were
put in to make it possible to renumber a TCP6 endpoint without teardown and
re-setup of sessions. anybody got that working yet?
header stacking will probably go the way of RH0 if it hasn't already, but
maybe there's hope -- is there an RFC that shows how this would work for
mobile IP without requiring that i tunnel the traffic in still-open TCP
sessions through the gateway i was nearest to when i opened the session?
i guess i'm insufficiently imaginative since i can't think of how MPLS or
OSPF can be used to scale a global (exterior) internet routing system.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
:-). In other words, it's like greenhouse gas, let the grandkids work it out,
we'll just continue to grow the current system incrementally so that when the
solution comes it can have a lot more of our processed output to deal with.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
i wanted to use domain names as permanent identifiers and have network-wire
addresses be as irrelevant and ephemeral as IEEE 802. i wanted to pay a setup
and in-flight renumberability complexity tax on every flow, in order to avoid
entrenchment and inertia in the topology. there was talk at one time of an
ICMP6 message for "tell me your hostname" since it was expected that addresses
would change much faster than PTR RRs could be maintained. IPv6 could have
been a dramatic unequivocal improvement over IPv4. instead it's just bigger
addresses, and makes all non-address-size-related problems worse.
thanks for asking.
_______________________________________________
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>