Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >if you really believe there is going to be a routing system problem, then
> >you absolutely have to support ULA-C because it is the only way to enforce
> >keeping private space private.
> 
> Also doesn't seem to me to make a lot of sense.  There is a set prefix of
> ULAs now.  Filtering it on is already possible (and I heartily encourage
> same!).  Adding ULA-C doesn't make that easier or harder, and it does
> nothing else that would "enforce keeping private space private".  None of
> the ULA-C proposals I have seen came with a police force or standing army of
> clue-bat wielding networking engineers.

the concern i heard wrt ULA-G (and therefore wrt ULA-C upon with -G is based)
is that the filtering recommendations in RFC 4193 were as unlikely to "work"
as the filtering recommendations in RFC 1597 and RFC 1918.  and that with a
global registry of whois and in-addr, ULA-G (and therefore ULA-C) prefixes and
packets would have considerably greater utility when leaked than RFC 1597/1918
prefixes and packets.  so with demonstrable ease of leakage and demonstrably
higher utility of leakage, nobody anywhere believes that ULA-G (and ULA-G)
won't be leaked.  on that basis, ULA-G (and ULA-C) are said to be functional
equivilents to PI space.

i don't like or agree with this reasoning.  i'm just saying what i've heard.

someone on ARIN PPML accused ULA-C (and therefore ULA-G) of being an "end run
around PA/PI" by which they meant "a way to get the benefits of PI without
qualifying for the costs imposed by PI on everyone else in the DFZ".  i
realized in that moment, that ULA-G (and therefore ULA-C) is not an end run
around PI space, it's an end run around the DFZ.  some day, the people who are
then responsible for global address policy and global internet operations,
will end the "tyranny of the core" by which we cripple all network owners in
their available choices of address space, based solely on the tempermental
fragility of the internet's core routing system.  but we appear not to be the
generation who will make that leap.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]