Yet another problem in draft-ietf-6man-rfc3484-revise...
Section 2.4 (Private IPv4 address scope):
[...]
> The algorithm currently specified in RFC 3484 is based on the
> assumption that a source address with a small scope cannot reach a
> destination address with a larger scope.
[...]
The above sentence is simply not true, it was NOT based on such an
assumption at all. It was based on the assumption that it was
less likely to work. There's two reasons why it's less likely to work.
First, it might or might not be able to reach it (the text overstates
by saying it cannot... it was acknowledged that it may or may not).
Second, if it goes through a NAT, it might not work for protocols
that embed IP addresses in payloads.
[...]
> Due to this assumption, in the presence of both a NATed private IPv4
> address and a transitional address (like 6to4 or Teredo), the host
> will choose the transitional IPv6 address to access dual-stack peers
> [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6
> connectivity over native IPv4 connectivity, particularly where the
> transitional connectivity is unmanaged, is not considered to be
> generally desirable.
>
> This issue can be fixed by changing the address scope of private IPv4
> addresses to global.
Section 10 of RFC 3484 contained many examples. -revise contains
no such example of what it's talking about, so I have to guess. Let's
look at 3 cases.
Case 1:
D set = { global IPv6, global IPv4 }
S set = { Teredo IPv6, RFC1918 IPv4 }
Under RFC 3484 rules, Destination Address Selection would prefer
the Teredo connectivity under rule 2 (Prefer matching scope).
Under -revise rules, Destination Address Selection would still prefer
the Teredo connectivity under rule 6 (Prefer higher precedence),
since the precedence of the (non-Teredo) destination address
beats the precedence of the IPv4 address. Hence -revise
does not change the behavior in this case.
Case 2:
D set = { Teredo IPv6, global IPv4 }
Not an interesting case because Teredo addressing should be
disabled when a host has a global IPv4 address.
Case 3:
D set = { global IPv4 = 1.2.3.4 }
S set = { NAT-ed IPv4 = 10.2.3.4, global IPv4 = 128.66.3.4 }
Under RFC 3484 rules, Source Address Selection would prefer
the global IPv4 address under Rule 2(Prefer appropriate scope).
Under -revise rules, Source Address Selection would instead prefer
the NAT'ed IPv4 under Rule 8 (Longest matching prefix).
This is broken. I don't see a real case the proposed change
fixes, I only see real cases it breaks.
-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
