On 03/03/12 00:33, Mukom Akong T. wrote:
On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra
<mich...@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
