Some comments below; sorry that my first query wan't
as cogent as I'd like--early mornings without coffee aren't
the best for coherence.
At 6:43 AM -0700 3/23/09, Fred Baker wrote:
>On Mar 23, 2009, at 5:06 AM, Ted Hardie wrote:
>
>> At 1:18 AM -0700 3/23/09, Fred Baker wrote:
>>> The difference between shim6 and NAT66 in the case is that
>>> the host itself isn't aware that it is using the address (it is using
>>> a ULA or some other address),
>>
>> Just to be clear, what does "some other address" encompass
>> as possibilities? Can you see any case where it would be using
>> some other PA address, PI address, or link-local?
>>
>> Ted
>
>The NAT66 draft describes a scenario in which the hosts in a network
>are using one set of addresses, whether PA from some other ISP or ULA,
>and send packets using that address through a DMZ that changes the
>prefix (the upper 64 bits) by a stated algorithm. A network with many
>ISPs might have many such DMZs between itself and its DMZs. The host
>would therefore think it is using the interior address while its peer
>would observe it using one of the various exterior addresses that
>result from the use of the same interface identifier with the various
>prefixes in question, and the checksum algorithm.
Imagine for a moment that an organization has gotten PI space from
an RIR. It has a choice now to find upstreams who will announce that
prefix to the global routing table. This proposal appears to allow it
to also insert some 1:1 mapping box at a network border, and to change
from that PI space to PA space. (It might do that because it was cheaper
than getting the upstream to carry the traffic and carry the routes). Doing
that means it has at least one type of address independence that ULAs
do not allow: it can announce these prefixes into the global routing table
if it turns out it needs to do so *without further renumbering*. ULAs
force you to have some PA-holding upstream; they may be independent from
any single single one, but you are stuck with the class (a duopoly for many
places in the U.S.).
Note that I have further concerns about ULA's defined sizes and lack
of aggregation for this use. (I fully admit that I have these concerns
partly because people don't do dense deployment all that well, but
I don't see much change there. Educating folks about advances
there may help assuage this concern).
>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.
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.
Thanks for your considered responses,
Ted
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
