Comment in-line... On 14 Feb 2012, at 17:02, Arifumi Matsumoto wrote:
> Dave, > > another point below. > > On 2012/02/14, at 8:55, Dave Thaler wrote: > >>> -----Original Message----- >>> From: Dave Thaler >>> Sent: Monday, February 13, 2012 2:01 PM >>> To: Dave Thaler; 'Chris Grundemann'; 'Brian E Carpenter' >>> Cc: 'ipv6@ietf.org'; 'Brian Haberman'; 'Bob Hinden' >>> Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt >>> >>> 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. >> >> Dmitry Anipko pointed out that rule 5 (Prefer matching label) would cause >> the -revise rules to prefer IPv4. Still, I'd prefer a solution that doesn't >> solve >> this problem by creating another one (case 3). That is, we should fix a >> problem >> rather than just move it around. >> >> I'll think about this and see if I can come back with a proposal. > >>> 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. > > > AFAIK, neither RFC 3484 nor -revise specifies source address selection > algorithm > for an IPv4 destination address. Simply, it is out of scope of these > documents. > > Do you want to cover these issues in the revision ? I agree with Arifumi's comment here, see the end of paragraph 3 of section 2: "Application of this specification to source address selection in an IPv4 network layer may be possible but this is not explored further here." Tim > > Best regards, > >> >> -Dave >> >>> >>> 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 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------