due to much discussion of ula-c in rir fora, we just scheduled a bof on
ulas for hellview. i need folk to do four short presos
o What are ULAs?
o What is ULA-C?
o Pros
o Cons
and the discussion can degenerate from there 
please write to me privately to volunteer.
randy
we still need a operator to make a short summary preso extolling
the virtues of ula central at the bof.
randy
Perhaps the difficulty in finding one says something of the operational
virtues of ULA.
Owen
How exactly are the opinions of people who operate ISP networks about address space that's never used on the internet relevant?
1) He never specified that the operator had to operate an _ISP_ network.
2) Even ISP networks have infrastructure which they might not want routed
on the public Internet.
Steve
[ i do not see mail from the respondent. and this reminds me why ]
we still need a operator to make a short summary preso extolling
the virtues of ula central at the bof.How exactly are the opinions of people who operate ISP networks about
address space that's never used on the internet relevant?1) He never specified that the operator had to operate an _ISP_ network.
in the words of klaus wirth "i did not run out of ink."
2) Even ISP networks have infrastructure which they might not want routed
on the public Internet.
in fact, the intro speaker is a pro and a carrier. but i don't want to
overload them.
i wonder what the O in nanOg stands for?
randy
Iljitsch van Beijnum wrote:
we still need a operator to make a short summary preso extolling
the virtues of ula central at the bof.How exactly are the opinions of people who operate ISP networks about
address space that's never used on the internet relevant?
One of the potential values of unique private address space is the
ability to built your own internets. Now whether there is value to
unique but private address space that is significantly higher than
private but non-unique address space (1918 style) or simply obtaining
your own address space the normal way is a good question. presumably an
administrative hurdle has to be crossed in the former and later cases
but not the middle one.
[ i do not see mail from the respondent. and this reminds me why ]
Hm, I wonder what it is that I did to deserve that and who else I share this special status with.
we still need a operator to make a short summary preso extolling
the virtues of ula central at the bof.How exactly are the opinions of people who operate ISP networks about
address space that's never used on the internet relevant?
1) He never specified that the operator had to operate an _ISP_ network.
I would invite him to specify the type of operator he had in mind, along with the consideration that assuming public IP network for that isn't entirely unexpected on this list, but apparently, that won't do much good.
I think not everyone has a full understanding of why the IETF came up with unique local addressing for IPv6. The idea was NOT to create a new class of address space in addition to RFC 1918-style private addresses and regular globally routable address space. The main issue was that the existing equivalent of RFC 1918 in IPv6, site local addresses, required extensive special case handling in routers and applications, without a clear definition of how this was supposed to work in practice. See http://www.ietf.org/rfc/rfc3879.txt for the details.
Other address types also require special case handling in IPv6 such as link local addresses. Every IPv6 system (host or router) is required to have an address in the prefix fe80::/64 on all of its interfaces. This means that the fe80::/64 prefix is present on more than one interface, which defies all previously known rules about routing. But since packets using those addresses aren't allowed to pass through a router, that's not really a problem.
The idea behind site local is the same, except that you can have a few router hops within a site. There is no convenient location where you can kill all site local packets so they don't leave the "site" like you can with link locals.
Additionally, there's the issue of organizations that each use local addressing and end up merging their networks. Non-unique addressing makes this very hard.
Solution: new type of local addresses that doesn't require any router magic to keep the packets within the site, and is globally unique so network merging isn't an issue.
This means that despite some different properties, ULA space is really the IPv6 equivalent of RFC 1918 space and NOT some kind or bastard invention that is secretly trying to be global space.
But ULAs *do* require router magic. They require a policy to be in place that causes them to not be advertised unless the policy is overridden, and a policy that doesn't believe them even if they are mistakenly advertised. The simple way to accomplish this is to either (small installations) list the prefixes one will advertise or accept, or (larger installations) explicitly deny ULAs before permitting those in the relevant communities (send side) or accepting anything received.
Well, there is no such thing as an out-of-the-box BGP configuration, so that's to be expected.
Although ISPs tend to let packets with RFC 1918 source addresses slip out from time to time, they're actually pretty good at rejecting RFC 1918 routes: currently, route-views.oregon-ix.net doesn't have the 10.0.0.0, 172.16.0.0 or 192.168.0.0 networks in its BGP table (there are two entries for 192.0.2.0, though). So in IPv4 the magic is of sufficiently quality.
Although ISPs tend to let packets with RFC 1918 source addresses slip
out from time to time, ...
maybe some isp's, or even most isp's in some parts of the world, but not
isp's in general. we see a continuous barrage of rfc1918-sourced queries
at f-root, along with a continuous blast of rfc1918-related updates in
AS112. i don't think you want to use RFC 1918 as your poster child for
getting filtering right.
... they're actually pretty good at rejecting RFC 1918 routes: currently,
route-views.oregon-ix.net doesn't have the 10.0.0.0, 172.16.0.0 or
192.168.0.0 networks in its BGP table (there are two entries for
192.0.2.0, though). So in IPv4 the magic is of sufficiently quality.
route-views is run by competent people, and the networks who feed routing
tables to it are usually run by competent people. filtering this kind of
trash is probably a normal part of operations for this class of networks.
i don't think you can use route-views as a poster child for filtering having
been gotten right.