cengel at sponsordirect.com
Mon Apr 12 11:42:33 EDT 2010
Owen DeLong wrote:
> Well said. Even RFC-1918 space can be routed across the
> global internet due to misconfiguration, so, I fail to see
> how that can possibly provide the protection described.
> Admittedly, the number of misconfigurations increases in
> inverse proportion to topological proximity, but,
> nonetheless, lots of routing tables see RFC-1918 space on the
> global internet due to misconfiguration.
> Why would ULA-C or any other "special" prefix be any different?
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> > Oddly, I work for mondo-megacorp and I find it interesting
> that you're
> > speaking for all entities that fit that category collectively.
> > From my vantage point ,the security posture associated with a
> > particular prefix, service or network internal to our
> > domain is defined by requirements not by some intrinsic
> nature of the
> > prefix.
With RFC-1918 there are two things that HELP prevent it from being routed to you. Firstly it's understood by convention that it's not supposed to be routed across the global internet... meaning that a non-negligible number of admins are going to decline to route it. Secondly it's not unique, so even if an admin accepted routes for it, the chance that it would be YOUR particular route and nobody elses is also fairly small. Granted, the chances that it would be routed to you are still some number higher then 0 percent.... but we all know that in security there is no such thing as a 0 percent chance of exploit (perfect defense). Any measure that reduces the chance of exploit by ANY degree has some value as a protection.
With ULA-C, you do take away the non-unique factor but you still have the understood not to be globaly routed factor which does help. It's the same reason why people stop at red lights. There is nothing magical about the color red that makes car's apply thier breaks. It's simply well understood by most drivers that the color red means STOP. The color chosen doesn't really matter (just like the pre-fix), it could have been blue, orange or violet.... what matters is that it's a color easly distinguishable from the one which indicates GO (green) and that the convention of what you are SUPPOSED to do has been widely published and is well understood by most drivers who use the road.
That's why ULA-C has value. The actual pre-fix chosen doesn't matter... what matters is that it's WIDELY published and understood what the INTENT of an address within that range is... so that when people see it, they can at least easily recognize what they are SUPPOSED to do with it. No one can force them to follow that convention, but at least the information is available for them to do so, if they choose. By contrast, it's not particularly easy for an admin to know that some guy half-way across the world is using this particular portion of his GUA for his private network and doesn't want it routed and this other particular portion of his GUA should be routed, if you happen to get announcements for both.
Furthermore, I fail to see what the big hang-up is here. I don't think anyone is trying to speak for all domains and tell them that they MUST use ULA space for their private networks. By all means, if anyone that want's to use a portion of their GUA space for that... there is nothing in ULA that would hinder them from doing so. However, a certain percentage of the community clearly feels that there would be value in having ULA-C space. If there is no particular shortage of address space in IPv6, and the people who want it are willing to pay the costs to support ULA-C and we minimize the potential for abuse by treating it fee/policy wise identical to PI... where is the objection?
Do we really need to micro-manage everyone else's networks & addressing choices for them.... or can we accept that different people have different views/approaches/values and provide for a wide range of options so that as many folks as possible can pursue the approach that THEY feel works best for them?
More information about the ARIN-PPML