At 12:06 PM -0700 3/23/09, Fred Baker wrote:
>
>That is certainly an option, and please don't understand me to be
>arguing against it in a legislative sense. That said, if one has PI
>and chooses to run PA, one wonders about the real need for PI
>addressing - I would expect that the network might release its PI
>prefix.
I suspect most multi-homing is a result of concern about
poor service coupled with capture. Having PI space give you the
fullest field of options to handle that problem; the fact that only
a portion of allocated PI would then appear immediately in the
routing table seems like a benefit to me.
>If one isn't willing to release the PI space, then I really do
>wonder about the NAT usage. It will technically work, I just think the
>policy questions get really muddy.
>
>At the end of the day, I think that there is a place for PI - with a
>handwaving gesture, it ca be argued that anyone that can justify an AS
>number and in fact has multiple upstreams is probably well-served by
>PI. That said, the line of reasoning that takes the RIRs into PI space
>ultimately results in the same kind of swamp we have in the IPv4 route
>table. If "insanity" is defined as "applying the same algorithms to
>the same data and expecting a different result", those who complain
>about the IPv4 route table and request PI space are insane.
And those who recommend the general use of an address range which
is deliberately designed to have very limited aggregation are
not? ULAs don't do CIDR, last I heard. There is a very serious risk
in deploying ULAs that the cost of getting a routing table slot for
one is a function of how hungry a set of ISPs gets. There seems to
me a legitimate worry that deploying on the basis of ULA+PA
because of concerns with routing table growth could backfire badly.
If you find it doesn't work for any compelling application, the result
seems to be market pressure to route ULA. And the routing table goes
boom in yet another tragedy of the commons.
Perhaps I'm paranoid, or fret too easily. But I wouldn't bet on insane.
>I think
>providing a way to reach address independence that doesn't use PI and
>looks to the ISPs like PA has a material benefit. So I would expect
>O(10^4) PI networks world-wide, and the vast majority using a
>different model, such as this one.
>
>>> I would be surprised to see a link-local address in that context, as
>>> IPv6 systems aren't supposed to use them unless the address of the
>>> peer is also link-local.
>>
>> Frankly, this whole effort challenges the notion I had of IPv6 scopes
>> enough that I am still not sure I understand it well. If the box
>> doing
>> this has an interface on the link, I am not sure why it cannot do this
>> translation using link-local addresses. I can picture a wireless box
>> designed to do this, for example.
>
>"Cannot" and "is not supposed to" are two different things. The
>definition of link-local has elements of locality on a link, which I
>think bear consideration.
>
>> Is that a good idea? No, as it further confuses the host stack
>> about whether
>> scopes have a real meaning they need to know and care about, but I
>> don't think I yet understand how that scenario is logically distinct
>> from these proposals.
>
>True, and at one point in the past few months I myself have wondered
>whether unsubnetted SOHO and residential networks would be just as
>happy with link-local. But I think that it is better to use a ULA if
>one is looking for a local address as that is what it is designed for.
I think that if the local "cost" to generate a ULA is anything above
0 (and I include maintenance calls), the chance of deployment based
on link-local gets to be pretty high. If that doesn't worry you, given
3484, I'd like to understand why. All v6 scopes have collapsed at that
point, right?
regards,
Ted Hardie
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
