Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 14 February 2012 22:28 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830B21E80E1 for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2012 14:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2ontSI3Xsij for <ipv6@ietfa.amsl.com>; Tue, 14 Feb 2012 14:28:40 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 863F821E804B for <ipv6@ietf.org>; Tue, 14 Feb 2012 14:28:32 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q1EMSU5K024113 for <ipv6@ietf.org>; Tue, 14 Feb 2012 22:28:30 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q1EMSU5K024113
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1329258510; bh=y3mNgVwMsZ6sffNFi/9VAMYZlQY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=g+apNv6stWTiD0qc0RwDOdo0hoh53lDah9ePvU76HlLXtnSD81HgkGc/cLV7ofH+0 oTjLptpEyr5Db3vUik4E43VmOvO9cDA9Z86zOOxz0LiykfUSKyoVE0IlFM1OUEsFuM ig6GHrOfONwdQ83RgPS4YFXaDkDaplO7WLiNoT88=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id o1DMSU0543729287PJ ret-id none; Tue, 14 Feb 2012 22:28:30 +0000
Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q1EMSOS8003340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ipv6@ietf.org>; Tue, 14 Feb 2012 22:28:25 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1251.1)
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <1D57B1DC-79A4-4935-961E-830277F29715@nttv6.net>
Date: Tue, 14 Feb 2012 22:28:24 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|95f06fed57df49a47999c03029b31bdeo1DMSU03tjc|ecs.soton.ac.uk|E9E2EB30-6BD8-4AAD-A954-DFE73FD85737@ecs.soton.ac.uk>
References: <4EB3F3D6.4090302@innovationslab.net> <CAC1-dtnas++ahkBmpdyq7DbyAEg0W6bZY16qGzKmsP10vC39FQ@mail.gmail.com> <4EEA3D20.7020603@innovationslab.net> <CAKFn1SFvs0PzBXtEWWo814Oe5TJmbQEJBm5FeYJY5xzrr=KFSw@mail.gmail.com> <4EEA5793.8080800@gmail.com> <CAKFn1SHA-=cQ_=5rJVLVMvQYXoTL_D1dCR=uWZK-qFrcGp6P-w@mail.gmail.com> <4EEA7AF8.2090508@gmail.com> <CAC1-dtn9M8-9cPAmkhCiGV0Gi5+Gfs8GAssTOaA-ZFhyUY3feg@mail.gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F3557@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1D57B1DC-79A4-4935-961E-830277F29715@nttv6.net> <E9E2EB30-6BD8-4AAD-A954-DFE73FD85737@ecs.soton.ac.uk>
To: 6man Mailing List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=o1DMSU054372928700; tid=o1DMSU0543729287PJ; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: q1EMSU5K024113
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 22:28:41 -0000

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
> --------------------------------------------------------------------