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 On Jun 1, 2007, at 11:51 AM, Randy Bush wrote:
we still need a operator to make a short summary preso extolling the virtues of ula central at the bof.
randy
On 1-jun-2007, at 20:51, Randy Bush 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?
On Jun 1, 2007, at 3:13 PM, Iljitsch van Beijnum wrote:
On 1-jun-2007, at 20:51, Randy Bush 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?
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
On 2-jun-2007, at 0:34, Randy Bush wrote:
[ 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.
Iljitsch van Beijnum wrote:
On 1-jun-2007, at 20:51, Randy Bush 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.
On 2-jun-2007, at 0:43, Joel Jaeggli wrote:
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 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.
On Jun 1, 2007, at 4:05 PM, Iljitsch van Beijnum wrote:
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.
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.
On 2-jun-2007, at 1:27, Fred Baker wrote:
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.
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. -- Paul Vixie
participants (7)
-
Fred Baker -
Iljitsch van Beijnum -
Joel Jaeggli -
Owen DeLong -
Paul Vixie -
Randy Bush -
Steve Feldman