[arin-ppml] Encouraging IPv6 Transition

[Owen DeLong]

On May 16, 2012, at 7:11 PM, Michael Richardson wrote:

> 
>>>>>> "Owen" == Owen DeLong <owen at delong.com> writes:
>    Owen> No, RFC-1918 and NAT are among the key reasons to argue for
>    Owen> IPv6.  Collision is just icing on the cake.
> 
> For *INTERNET* access, you are right.

I believe this applies just as well to systems which do not (intentionally)
exchange packets with the internet, but which use IP addressing. Indeed,
these systems fall into one of two categories (I will explain below).

> I'm talking about systems which do not (intentionally) exchange packets
> with the Internet, but which use IP addressing "internally"(%) to
> communicate, and at the edge of these devices, they speak to an
> Enterprise network of some kind.

There are two categories of "internal only" networks. One is isolated
networks which are entirely self-contained and do not touch any networks
which interact with the internet. These networks can be assembled with
any address space without regard to internet numbering.

The other is semi-private networks in that they do not directly exchange
packets with the internet, but, they touch and exchange packets with networks
that do. These networks do, indeed, need locally (at least) unique addressing
which does not conflict with external internet addressing. For such addressing,
one has two options... GUA and ULA.

In either case, IPv6 provides the advantages of avoiding RFC-1918 and NAT.
Sure, you might be able to do IPv4 in some instances of both cases without
using RFC-1918 and/or NAT, but it is relatively unlikely at any scale and almost
certainly impossible across a few mergers and acquisitions of any size.
(We were talking enterprise, not SMB here, right?)

> 
> (%)-"internally" is in quotes, because, in one case, the network plans
>    to span many miles of tundra. 
> 

"Internal" is a matter of topology, not geography.

> 1) The leak potential is large due to misconfiguration.   Sometimes
>   bits of the Enterprise are used as "backbone" for these systems.
>   (That's why layer-3 IP networking is so useful...)
>   When the packets escape into some part of the Enterprise which does
>   not know about said device, people start asking whois.
>   ULA-Random may be just fine for a homenet network, but I'd never want
>   to have it an Enterprise.

So why not use GUA? Policy allows you to use GUA for such purposes.
Filter these GUA routes at the border and filter the packets too, just in case.
Unless you have two parallel misconfigurations (routing _AND_ packet filters),
you won't have external leaks.

This solves your desire for whois and RDNS. There's no need to do complex
split horizon, just use DNS views (easy with BIND, not sure about other tools).
Indeed, not even really a need to register your RDNS servers globally so long
as the resolvers on the enterprise networks you touch have NS cache hints
pointing in the right direction for those zones.

> 
> 2) what if there are two of these devices, or two enterprises with these
>   devices merge?  I can't see why the *manufacturer* of said device
>   can't trivially get a /48 or /40 in Non-Connected space, and then
>   stamp in a /56 or /60 (as appropriate) into each instance sold.
> 

Again, not seeing a problem with using GUA for this, though I fail to
understand why addressing would be applied by the manufacturer
rather than configured by the administrator.

>   Look at ethernet... you pay the IEEE $2500 once, you get your OUI
>   prefix.  Done, no renewal necessary.  It's hard enough to justify 
>   that $2500 once... but $1250 every year?  

The short answer is that layer 3 addressing operates in an entirely
different context from layer 2 addressing. Layer 3 addressing must be
globally unique. Layer 2 addressing only needs to be unique within
a link. Layer 2 addressing operates in a completely flat topology.
Layer 3 addresses are hierarchical and contain and/or define a
certain amount of topological information.

> 
>   "Thanks, this IPv6 stuff is too difficult, we'll just squat on
>   something.   IPv6 ULA-R gives us no advantage over RFC1918 or
>   squatting."
> 

The ideal solution for what you describe is GUA. You are right, ULA is no
better and no worse than RFC-1918.

>   (Actually, IPv4 squatting is better, because if the manufacturer puts
>   something useful on a web site about where they squat, google can
>   find it when whois returns nonsense)

In fact, not true. You can put something useful on the web site about where
you located in ULA-R and have a reasonable chance that google finds
only your squat and not 5,000 other squatters using the same space.

> 
> 
>>> But, I didn't say it was risk of collision with ULA-R that was
>>> the main problem, it is lack of reverse DNS and lack of whois
>>> that is the problem.
> 
>    Owen> Why do you need non-local RDNS and/or WHOIS for local-only
>    Owen> addresses?
> 
> Why do I see large ISPs with multiple ASs?
> Why isn't all their traffic local?  Why aren't their networks convex?
> 

If they were entirely internal non-connected networks, you wouldn't. They are not. They are globally connected networks and their internal structures are exposed in order to facilitate better routing where they touch the internet.

> See above.  
> One hand does not know what the other hand is doing, and does not need to.
> 

Quite the opposite, actually.

>    Owen> If the addresses should not be seen outside of your
>    Owen> organization, why would you need a directory service to tell
>    Owen> you who the addresses belong to?
> 
> emphasis on "SHOULD"
> 
> Take two windows laptops at two enterprises a floor apart, turn on wifi
> bridging on both.  Now try to figure out where the packets are coming
> from.   With RFC1918 it's already a disaster.  IPv6 doesn't need to suck
> that way.
> 

Indeed, it doesn't suck that way unless you make it do so. ULA does, indeed
suck just as bad as RFC-1918. If you don't want that suckage, use GUA.

I'm all for distributing more GUA at lower fees. If you use ULA, it's free, but,
you get what you pay for.

Owen