RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Dave Thaler <dthaler@microsoft.com> Sat, 11 February 2012 02:41 UTC
Return-Path: <dthaler@microsoft.com>
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 3E4AC21F8666 for <ipv6@ietfa.amsl.com>; Fri, 10 Feb 2012 18:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.419
X-Spam-Level:
X-Spam-Status: No, score=-105.419 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 i7glpAo34n83 for <ipv6@ietfa.amsl.com>; Fri, 10 Feb 2012 18:41:44 -0800 (PST)
Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7391121F859E for <ipv6@ietf.org>; Fri, 10 Feb 2012 18:41:44 -0800 (PST)
Received: from mail16-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Sat, 11 Feb 2012 02:41:43 +0000
Received: from mail16-tx2 (localhost [127.0.0.1]) by mail16-tx2-R.bigfish.com (Postfix) with ESMTP id B879980248; Sat, 11 Feb 2012 02:41:43 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail16-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail16-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2 (MessageSwitch) id 1328928101564924_25369; Sat, 11 Feb 2012 02:41:41 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.243]) by mail16-tx2.bigfish.com (Postfix) with ESMTP id 8521C3C0050; Sat, 11 Feb 2012 02:41:41 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 11 Feb 2012 02:41:41 +0000
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 10 Feb 2012 18:41:40 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 10 Feb 2012 18:41:39 -0800
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 18:41:39 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: Dave Thaler <dthaler@microsoft.com>, Chris Grundemann <cgrundemann@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Thread-Topic: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Thread-Index: AQHMmvx1vO8I87vUo0m73gUxdiNcXZXd39qAgAAf8wCAAAn2gIAAFZKAgAAYZICAABHNAIAABeSAgEMv5BCAFhKygA==
Date: Sat, 11 Feb 2012 02:41:38 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
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>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@gmail.com>
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: Sat, 11 Feb 2012 02:41:45 -0000
I'm now working on an actual update to rfc3484 that would Obsolete (not Update) it. I found a couple more technical issues in so doing. I also now believe it's faster to do the replacement than it is to fix a delta-based document. 1) -revise documented the issue with Rule 9 of section 6, but does not mention the same issue with Rule 8 of section 5, nor does it suggest a fix. The proposed change to section 6 rule 9 used a "Netmask()" which was not defined and indeed the term "mask" is not used with IPv6, only prefix length. Instead of taking the proposed change, I propose to instead change the definition of CommonPrefixLen() in section 2.2 as follows: OLD (RFC 3484): We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128. NEW: We define the common prefix length CommonPrefixLen(S, D) of a source address S and a destination address D as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common, up to the length of S's prefix (i.e., the portion of the address not including the interface ID). For example, CommonPrefixLen(fe80::1, fe80::2) is 64. 2) Should ULAs be treated as site-local scope for purpose of the scope rules? Consider the following two cases. Destination Address Sorting: which should be preferred by default: a) a native IPv6 global destination address? b) a non-native ULA destination address that isn't in the same prefix as your own ULA (if any)? I'd argue that (a) is the right answer. The -revise draft's proposal would instead result in (b). Source Address Sorting: which should be preferred by default when sending to a site-local multicast address: a) a deprecated ULA source address? b) a non-deprecated link-local source address? I'd argue that (b) is the right answer. The -revise draft's proposal would instead result in (a). As such, I believe the correct fix is not to put fc00::/7 into the policy table, but instead to update section 3.1 to say that we map ULAs to multicast site-local scope. The existing scope rules would then have the effects I argue are the right answers above. 2) Was RFC 3484 in error when it said IPv4-translatable addresses should be treated as always in the "preferred" state? We now know a lot more about IPv4-translatable addresses than we (or I, anyway) did when 3484 was written, and RFC 6145 is the current reference. IPv4 translatable addresses are not necessarily recognized as such by a host. A host might get one from say DHCPv6 without knowing it's one, and that would be considered fine and normal. However, the statement about being in the "preferred" state is somewhere between unimplementable, and incorrect because the host is supposed to go through DAD, etc. Proposed fix: OLD (RFC 3484): IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status. NEW: IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should be treated as having "preferred" (in the RFC 4862 sense) configuration status. (An "IPv4-converted" address is not assigned to any interface, it's the IPv6 representation of an IPv4 address assigned to someone's interface, just like IPv4-mapped addresses except that IPv4-converted addresses can appear on the wire. See RFC 6145 for details.) -Dave
- 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise… Brian Haberman
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Arifumi Matsumoto
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Chris Grundemann
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian Haberman
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Roger Jørgensen
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian Haberman
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Roger Jørgensen
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Chris Grundemann
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Roger Jørgensen
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Tim Chown
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Chris Grundemann
- -06 candidate Arifumi Matsumoto
- Re: -06 candidate Mark Andrews
- Re: -06 candidate Arifumi Matsumoto
- Re: -06 candidate Brian E Carpenter
- Re: -06 candidate Mark Andrews
- ULA macro in the policy table Re: -06 candidate Arifumi Matsumoto
- Re: ULA macro in the policy table Re: -06 candida… Mark Andrews
- Re: ULA macro in the policy table Re: -06 candida… Arifumi Matsumoto
- Re: ULA macro in the policy table Re: -06 candida… Mark Andrews
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Brian E Carpenter
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Dave Thaler
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Arifumi Matsumoto
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Arifumi Matsumoto
- ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Brian E Carpenter
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Tim Chown
- Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-re… Tim Chown
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Arifumi Matsumoto
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Dave Thaler
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Arifumi Matsumoto
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Brian E Carpenter
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Dave Thaler
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Arifumi Matsumoto
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Hemant Singh (shemant)
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Brian E Carpenter
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Dave Thaler
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Kerry Lynn
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Brian E Carpenter
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Arifumi Matsumoto
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Marc Lampo
- Re: IPv6 zone index was Re: ULA scope [draft-ietf… Arifumi Matsumoto
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Marc Lampo
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- Re: Re: [homenet] ULA scope [draft-ietf-6man-rfc3… Ray Hunter
- RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Marc Lampo
- RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Anders Brandt
- Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.… Mark Andrews
- Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Brian E Carpenter
- RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Anders Brandt
- Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Tim Chown
- Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Don Sturek
- IPv6 zone index was Re: ULA scope [draft-ietf-6ma… t.petch
- RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Anders Brandt
- RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Anders Brandt
- Re: IPv6 zone index was Re: ULA scope [draft-ietf… Brian E Carpenter
- Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-… Brian E Carpenter