[arin-ppml] V6 address allocation policy

[James Hess]

On Sun, Jan 17, 2010 at 8:27 PM, Owen DeLong <owen at delong.com> wrote:
> On Jan 17, 2010, at 7:46 AM, William Herrin wrote:
>> On Sat, Jan 16, 2010 at 7:55 PM, Owen DeLong <owen at delong.com> wrote:
...
>> Practically speaking, we should start to see anecdotes about ULA
>> collisions as folks try to connect 100 to 1000 organizations together,
>> still a usefully large number but far fewer than RFC 4193 implies.
> Practically speaking, even if you buy into that argument, you're still
> quite a bit better off than RFC-1918.

If you have a V6 ULA collision, you may be a lot worse off  than you
were with a  IPv4  RFC-1918  collision.
The thing is:  you can probably mitigate an RFC-1918 collision  (when
merging companies, for example),   by using creative NAT rewriting
rules;  NAT'ing both sources and destinations, to provide connectivity
 for the transition period, when the merging companies  renumber  to
eliminate conflicts.

In the IPv6 world, so far, there is no such thing as NAT.
You cannot use NAT or translation  to mitigate an address space
collision, when the tool  and even the specification has not been
created..

A  RFC-1918 collision can be much less of an issue than a ULA
collision,  even though it is more likely.

So the combination of IPv6 + ULA  can make you a lot worse off in some
scenarios.

When the specifications for IPv6 NAT come out, and vendors start
making equipment that can  NAT map a block of V6 addresses 1:1 into
another block of addresses, _then_ we can consider you a lot better
off with ULA  in that scenario.
..
>>
> So, in order for ULA to buy you nothing, you'd have to be able to argue
> that 1:3 and 1:1,048,576 are equivalent risks. If you are willing to make
> bets like that, I want to be your bookie.


> Even if this is true (I'm not completely convinced), you're comparing
> ULA at 1:100<n<1000 vs. RFC-1918 at 1:0.003.

--
-J