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

[John Paul Morrison]

Paul_Vixie at isc.org wrote:
>> I'm curious about the opposition to EUI64.
>>     
>
> 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.
>   

But it seems usable or at least could be improved/built on.  Is there a 
reason not to have at least /80
on a 48 bit MAC layer?

If you're building a network within an AS, you just need an 
address/loopback for each node or router,
and information about areas - assuming a link state protocol. 
Information about "subnets" can be built into the
area ids (you often see OSPF areas represented as IP addresses), it can 
be IP unnumbered if the physical
layer supports this, and I've recently seen some IP un-numbered for 
Ethernet. 

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

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.

Was there a draft or published RFC on what you mention?

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.

One hopes a solution will converge :-) Or silicon could outstrip the 
public Internet's capacity for growth.


>   
>> 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.
>>     
>
> 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.
>
>   
>> 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.
>>     
>
> 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.
>
>   
>> 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.
>>     
>
> :-).  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.
>
>   
>> 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.
>>     
>
> 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
> (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/d09ba061/attachment.htm>