Re: Why ULA: low collision chance (Was: IPv6 fc00::/7 — Unique local addresses)

Fri Oct 22 05:20:05 UTC 2010

On 10/21/10 6:38 PM, Owen DeLong wrote:
> 
> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
> 
>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
>>> 
>>> Announce your gua and then blackhole it and monitor your prefix.
>>> you can tell if you're leaking. it's generally pretty hard to
>>> tell if you're leaking rfc 1918 since your advertisement may well
>>> work depending on the filters of your peers but not very far.
>> 
>> This is always the argument I hear from corporate customers
>> concerning wanting NAT. If  mistake is made, the RFC 1918 space
>> isn't routable. They often desire the same out of v6 for that
>> reason alone.

the rfc 1918 space is being routed inside almost all your adjacent
networks, so if their ingress filtering is working as expected, great,
but you're only a filter away from leaking.

> Given the number of times and the distance over which I have seen
> RFC-1918 routes propagate, this belief is false to begin with, so,
> removing this false sense of security is not necessarily a bad
> thing.

this happened this morning in a pop we have in the far east... packets
ended up in atlanta. what's more, the return path was natted.

>> I personally could understand the fear of wondering if your
>> stateful firewall is properly working and doing it's job and how a
>> simple mistake could have disastrous effects that NAT systems
>> usually don't have. ULA w/ NAT very well may become the norm.
>> 
> 
> I tend to doubt that it will... Hopefully there will be enough proper
> deployments that developers will not eschew improvements that depend
> on an end-to-end model and there will be real features unavailable to
> any network that deploys such relatively quickly.
> 
> The tragedy won't be networks deploying NAT. I'm all for allowing you
> to buy a gun, ammunition, and aim at your foot or head as you wish.
> 
> The tragedy will be if enough networks do this to hobble development
> of truly useful tools that depend on a NAT-free environment to work.
> 
> Owen
> 
> 
> 