Re: Common operational misconceptions

[Michael Sinatra <michael () rancid berkeley edu>]

On 03/03/12 00:33, Mukom Akong T. wrote:
> On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra
> <michael () rancid berkeley edu>  wrote:
> > ULA is the IPv6 equivalent of RFC1918
>
> Michael, could you explain this a bit more? In the sense that :
>
> a. Anyone can use ULA pretty much as they wish without having to go to
> their ISP or RIR - same for RFC1918
> b. In order to get to the public Internet, with ULA addressing, some
> kind of translation is required - same for RFC1918

Actually, (b) isn't quite correct, especially depending on how you 
define "the public Internet."  If you define it as "the DFZ," then we're 
*probably* okay.  If you define it as "any commercial ISP and/or any 
inter-AS traffic," then it's not so clear.  To plagiarize myself in a 
previous private response to someone else:

ULAs allow for native routing across a commercial ISP backbone to 
support "extranets" (ugh, I hate that word)--essentially to allow an 
enterprise to use a regular ISP (or ISPs) to carry ULA traffic between 
sites.  RFC 1918 requires that all privately-addressed traffic be 
encapsulated if it is routed into another AS.

The consequence is that any AS can filter all RFC 1918 routes *and* 
traffic at its border(s) and ISPs can (and SHOULD) refuse to route 
unencapsulated RFC 1918-addressed traffic between ASes.  ULAs may 
require holes to be poked in any blanket filter.  I see that as a 
significant difference because you can no longer "guarantee" 
non-routability of the space, which is what people tend to count on.

(We hope this won't happen, but it's not explicitly prevented by RFC 
4193 as it is by RFC 1918.  And see Ted Hardie's "rant" on the subject 
at NANOG 40 for an argument that it might: 
www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf)

My own view on this is that it's likely that ULA will stay out of the 
DFZ (due to the now-widespread availability of IPv6 PI), but that you 
may not be able to count on security (i.e. *traffic*) filters being 
magically in place everywhere as one does for RFC 1918.  (Again, that's 
probably a misconception of RFC 1918, but there is still a big 
difference in the potential for the consistent violation of the "magic 
filter" assumption for ULA.)


> c. Without centralised registration, two different networks could end
> up using same ULA space -  same for RFC1918

Yeah, but there's an orders-of-magnitude difference in the ability to 
generate a reasonable expectation of uniqueness.  Look at common RFC1918 
usage--it often falls into 192.168.0.0/23 (e.g. most CPE NAT devices) or 
10.0.0.0/23.  Larger users tend to be all over net 10, which makes 
merging networks a lot harder.  It's much more likely that such mergers 
will work better with ULA.

The large ULA space had put pressure on the standards community to 
define something like ULA-C, but PI IPv6 has relieved that pressure. 
However, the fact that ULA-C-like-things were ever proposed illustrates 
the differences between ULA and RFC 1918 space.

> There are certainly not identical but I'd think loosely equivalent.
> What am I missing?

There's also a third difference that interacts with the typical 
misconception that RFC 1918 implies or somehow specifies NAT (which I 
think I mentioned elsewhere).  When people think that RFC 1918 == NAT, 
they get really surprised that there's no stateful NAT in IPv6.  Given 
the address space of IPv6, stateless prefix translation could go a long 
way toward giving one the same functionality, but people tend to want 
NAT to perform the stateful overloading of public IP addresses.  So 
there are really three misconceptions at work here:

RFC 1918 implies NAT
NAT is defined as stateful overloading of a small pool of public IP 
addresses to support lots of private IP addresses.  (Stateless NAT?  Whut??)
ULAs are the same as RFC 1918 addresses

I realize that last one is cheating a bit because it it requires three 
misconceptions to create the resultant confusion about there not being 
stateful NAT66, but it *does* exist in the wild.

michael