From timothyhartrick@gmail.com Tue Jan 31 22:32:10 2012 Return-Path: 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 0E39611E808D for ; Tue, 31 Jan 2012 22:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WpNTQ6rWCejV for ; Tue, 31 Jan 2012 22:32:09 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6825621F8593 for ; Tue, 31 Jan 2012 22:32:09 -0800 (PST) Received: by pbdy7 with SMTP id y7so965385pbd.31 for ; Tue, 31 Jan 2012 22:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6NPjxuDK11p962paMKvMu/TT6zPToH/P80AuMBDKlhc=; b=h/uM1lN4ua68F5kDs14DPpWdEkXNF8TDJd8on34Gk13vKRoGX9yVGrjEV3cPUxjeD/ SVccuwar+uRHF8ysPevZERkaLTzGyzulJ4+tyHIW0Fe5+vlRBEA7bBikiUA6ZZxxq7k2 qWqIzycti8reb/sFzdgxx34iJNVGmK3s8hwIE= MIME-Version: 1.0 Received: by 10.68.231.10 with SMTP id tc10mr50679359pbc.91.1328077929186; Tue, 31 Jan 2012 22:32:09 -0800 (PST) Received: by 10.68.227.103 with HTTP; Tue, 31 Jan 2012 22:32:09 -0800 (PST) Received: by 10.68.227.103 with HTTP; Tue, 31 Jan 2012 22:32:09 -0800 (PST) In-Reply-To: <4F28CC25.2090706@gont.com.ar> References: <4F289A80.201@si6networks.com> <4F28CC25.2090706@gont.com.ar> Date: Tue, 31 Jan 2012 22:32:09 -0800 Message-ID: Subject: Re: A small survey of support of IPv6 atomic fragments From: Timothy Hartrick To: Fernando Gont Content-Type: multipart/alternative; boundary=047d7b33d19e34043504b7e13d2a X-Mailman-Approved-At: Wed, 01 Feb 2012 04:56:01 -0800 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:32:10 -0000 --047d7b33d19e34043504b7e13d2a Content-Type: text/plain; charset=ISO-8859-1 Fernando, Unless something has changed for the worse recently, HP-UX would have a yes in both columns. Tim Hartrick On Jan 31, 2012 9:22 PM, "Fernando Gont" wrote: > On 01/31/2012 10:50 PM, Fernando Gont wrote: > > OS | Atomic fragments | Improved Processing > > -------------------+------------------+------------------------------ > > FreeBSD 8.2 | No | No > > FreeBSD 9.0 | Yes | No > > Linux 3.0.0-15 | Yes | Yes > > NetBSD 5.1 | No | No > > OpenBSD-current | Yes | Yes > > Solaris | Yes | Yes > > Win 7 Home Premium | Yes | No > > --------------------------------------------------------------------- > > Minor errata: FreeBSD 8.2 does support atomic fragments (but not > draft-gont-6man-ipv6-atomic-fragments). It was *FreeBSD 8.0* the system > discarding the atomic fragments. > > Therefore, the corrected table is: > > OS | Atomic fragments | Improved Processing > -------------------+------------------+------------------------------ > FreeBSD 8.0 | No | No > FreeBSD 8.2 | Yes | No > FreeBSD 9.0 | Yes | No > Linux 3.0.0-15 | Yes | Yes > NetBSD 5.1 | No | No > OpenBSD-current | Yes | Yes > Solaris 11 | Yes | Yes > Win 7 Home Premium | Yes | No > --------------------------------------------------------------------- > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b33d19e34043504b7e13d2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Fernando,

Unless something has changed for the worse recently, HP-UX would have a = yes in both columns.

Tim Hartrick

On Jan 31, 2012 9:22 PM, "Fernando Gont&quo= t; <fernando@gont.com.ar>= wrote:
On 01/31/2012 10:50 PM, Fernando Gont wrote:
> =A0 =A0 =A0 =A0OS =A0 =A0 =A0 =A0 =A0| Atomic fragments | =A0 =A0 Impr= oved Processing
> -------------------+------------------+------------------------------<= br> > FreeBSD 8.2 =A0 =A0 =A0 =A0| =A0 =A0 =A0 No =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 No
> FreeBSD 9.0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 No
> Linux 3.0.0-15 =A0 =A0 | =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0Yes
> NetBSD 5.1 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 No =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 No
> OpenBSD-current =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0Yes
> Solaris =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0Yes
> Win 7 Home Premium | =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 = =A0 =A0 No
> ---------------------------------------------------------------------<= br>
Minor errata: FreeBSD 8.2 does support atomic fragments (but not
draft-gont-6man-ipv6-atomic-fragments). It was *FreeBSD 8.0* the system
discarding the atomic fragments.

Therefore, the corrected table is:

=A0 =A0 =A0 OS =A0 =A0 =A0 =A0 =A0| Atomic fragments | =A0 =A0 Improved Pr= ocessing
-------------------+------------------+------------------------------
FreeBSD 8.0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0No =A0 =A0 =A0 =A0| =A0 =A0 =A0= =A0 =A0 =A0 No
FreeBSD 8.2 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 No
FreeBSD 9.0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 No
Linux 3.0.0-15 =A0 =A0 | =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 = =A0 =A0Yes
NetBSD 5.1 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 No =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 No
OpenBSD-current =A0 =A0| =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 = =A0 =A0Yes
Solaris 11 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0Yes
Win 7 Home Premium | =A0 =A0 =A0 Yes =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 = =A0 No
---------------------------------------------------------------------

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar ||= fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--047d7b33d19e34043504b7e13d2a-- From brian@innovationslab.net Wed Feb 1 06:13:32 2012 Return-Path: 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 DEB4321F8A53 for ; Wed, 1 Feb 2012 06:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 8FTDDAMYPby9 for ; Wed, 1 Feb 2012 06:13:32 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3108211E8797 for ; Wed, 1 Feb 2012 06:13:07 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 14FCA881AA for ; Wed, 1 Feb 2012 06:13:07 -0800 (PST) Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A9A0F130009 for ; Wed, 1 Feb 2012 06:13:06 -0800 (PST) Message-ID: <4F294870.8000605@innovationslab.net> Date: Wed, 01 Feb 2012 09:13:04 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <4F25CA23.90706@gmail.com> In-Reply-To: <4F25CA23.90706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:13:33 -0000 On 1/29/12 5:37 PM, Brian E Carpenter wrote: > Hi, > > I've only seen one comment on this question. Any more, or should > the authors just decide? I tend to favor option 2. It avoids affecting legacy support of the IPv6address syntax. Regards, Brian > > Regards > Brian Carpenter > > On 2012-01-04 15:23, Brian E Carpenter wrote: >> Representing IPv6 Zone Identifiers in Uniform Resource Identifiers >> >> We'd like feedback on this. In particular, which of the two options >> proposed do people prefer? >> >> OPTION 1: >> >> The existing syntax of IPv6address is extended by adding a specific >> option for the case of link-local addresses. >> >> OPTION 2: >> >> The existing syntax of IPv6address is retained, and a zone identifier >> may be added optionally to any literal address. This allows >> flexibility for unknown future uses. >> >> - Brian& Bob >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt >> Date: Tue, 06 Dec 2011 17:27:00 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers >> Author(s) : Brian Carpenter >> Robert M. Hinden >> Filename : draft-carpenter-6man-uri-zoneid-00.txt >> Pages : 6 >> Date : 2011-12-06 >> >> This document describes how the Zone Identifier of an IPv6 scoped >> address can be represented in a Uniform Resource Identifier that >> includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-00.txt >> >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian@innovationslab.net Wed Feb 1 07:50:29 2012 Return-Path: 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 C4BEB11E811F for ; Wed, 1 Feb 2012 07:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 b5r-6wEdPFfH for ; Wed, 1 Feb 2012 07:50:29 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BE2E811E811C for ; Wed, 1 Feb 2012 07:50:28 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EED7B881C0 for ; Wed, 1 Feb 2012 07:50:27 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6D2CE130009 for ; Wed, 1 Feb 2012 07:50:27 -0800 (PST) Message-ID: <4F295F40.8010502@innovationslab.net> Date: Wed, 01 Feb 2012 10:50:24 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments References: <4F148730.6030308@innovationslab.net> In-Reply-To: <4F148730.6030308@innovationslab.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:50:29 -0000 All, On 1/16/12 3:23 PM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt > Pages : 12 > Date : 2011-12-15 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on January 31, 2012. Based on the feedback received, there is consensus for 6MAN to adopt this draft as a working group draft. I will instruct the author to post the next revision as a 6MAN WG document. Regards, Brian From pch-b29AA871B@u-1.phicoh.com Wed Feb 1 15:37:35 2012 Return-Path: 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 A8FC611E812D for ; Wed, 1 Feb 2012 15:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 07K0pf3XQwk8 for ; Wed, 1 Feb 2012 15:37:35 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 821CC11E8124 for ; Wed, 1 Feb 2012 15:37:34 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rsjjy-0001inC; Thu, 2 Feb 2012 00:37:26 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> <4F272AE3.5080208@si6networks.com> <4F2839EF.2090100@gont.com.ar> In-reply-to: Your message of "Tue, 31 Jan 2012 15:58:55 -0300 ." <4F2839EF.2090100@gont.com.ar> Date: Thu, 02 Feb 2012 00:37:26 +0100 X-Mailman-Approved-At: Wed, 01 Feb 2012 16:02:25 -0800 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 23:37:35 -0000 In your letter dated Tue, 31 Jan 2012 15:58:55 -0300 you wrote: >On 01/31/2012 08:12 AM, Philip Homburg wrote: >> "Such traffic absolutely occurs in the wild. I have three reasonably >> busy name servers where this is logged as an error from the ipfw code, >> e.g." >> >> Inconclusive. We don't know why that traffic is there. >> >> So, just remove that requirement from RFC-2460, and the problem is gone. > >If you're meaning to remove support for some feature from the standard >on the basis that it is not used, then the *you* should prove that is >not being used. I'm not claiming that it is not used. The Internet is a very big place, proving a negative is almost impossible. One issue is, are atomic fragments used for anything other than stateless IPv6/IPv4 translators? Unless I misunderstood you, you claimed there was such usage. I can't find the message you were referring to, so I asked you for a message ID. Instead you gave examples from another area, that seems consistent with stateless translators. The second issue is that in my opinion, sending atomic fragments to such translators is a bad idea and should be deprecated. Assuming there is no other use for atomic fragments, that implies to me that we should not spend any time making it work better. Just let it die off. Why is sending atomic fragments to translators a bad idea? Because the whole IPv6 Internet has to support it (and will suffer the effects) and the use is extremely limited. There is some benefit when: - The path between the translator and the IPv4 host has an mtu of less then 1280, - and there is a one to one correspondance between IPv4 and IPv6 addresses (so using it in a traditional NAT context doesn't work) - and the data flow from any IPv6 host to the IPv4 host does not exceed 20 Mbit/s - and the IPv6 host maintains a strict counter in the lower 16-bit of the fragment ID. If any of those conditions are not met then either atomic fragments are not needed, or having the translator generate the id in the IPv4 header is just as good. >I personally believe it is very dangerous to think about removing >something without bothering to consider what might break, and without >bothering whether there's stuff (such as translators) that depend on >that feature. > >Fix the bug, and be done with it. I'm not saying that any existing support has to be removed. Just let it be. But fully supporting atomic fragments everywhere will have a lot of impact, and that is in my opinion not worth the effort. So it best to stop now. And not create any additional standards or recommendations on how to deal with or generate atomic fragments. From fgont@si6networks.com Wed Feb 1 17:04:37 2012 Return-Path: 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 884E611E8098 for ; Wed, 1 Feb 2012 17:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, 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 19qjzN1Qy95a for ; Wed, 1 Feb 2012 17:04:37 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8B11E808F for ; Wed, 1 Feb 2012 17:04:36 -0800 (PST) Received: from [190.48.223.230] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rsl6I-0007RU-C5; Thu, 02 Feb 2012 02:04:34 +0100 Message-ID: <4F29E110.7000103@si6networks.com> Date: Wed, 01 Feb 2012 22:04:16 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> <4F272AE3.5080208@si6networks.com> <4F2839EF.2090100@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:04:37 -0000 On 02/01/2012 08:37 PM, Philip Homburg wrote: > I'm not claiming that it is not used. The Internet is a very big place, proving > a negative is almost impossible. At the very least, one should bother surveying implementations and/or doing some measurements... > One issue is, are atomic fragments used for anything other than stateless > IPv6/IPv4 translators? Weren't one of the pointers I provided about atomic fragments used for the DNS? > Unless I misunderstood you, you claimed there was such > usage. I can't find the message you were referring to, so I asked you for a > message ID. Instead you gave examples from another area, that seems consistent > with stateless translators. See the post by in the thread about "Fragmentation-related security issues". > The second issue is that in my opinion, sending atomic fragments to such > translators is a bad idea and should be deprecated. Assuming there is no other > use for atomic fragments, You know that they say assumptions are the mother of all f* ups? > that implies to me that we should not spend any time > making it work better. Just let it die off Let's agree to disagree. . > Why is sending atomic fragments to translators a bad idea? Because the whole > IPv6 Internet has to support it (and will suffer the effects) and the use is What are "the effects"?? > I'm not saying that any existing support has to be removed. Just let it be. > But fully supporting atomic fragments everywhere will have a lot of impact, > and that is in my opinion not worth the effort. See the survey I posted. Everybody modulo NetBSD supports them. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tomosann@gmail.com Wed Feb 1 17:48:12 2012 Return-Path: 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 7500D11E808A for ; Wed, 1 Feb 2012 17:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 iiundDXHYagp for ; Wed, 1 Feb 2012 17:48:12 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A916911E8087 for ; Wed, 1 Feb 2012 17:48:11 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so1749377bkb.31 for ; Wed, 01 Feb 2012 17:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=x1DjovLNtv4XSFkxnvPcoetz3s7QDCnmCNEWd/b90vQ=; b=eHUps8UvwF5OdvRB+aCAo6cG4YYJiY0cLlvqqCxL5p3vBRm9Spb4mJIwDmFajxjIC+ q5lRX1Ufk3u+483+Eb0ciQMMyKIfYMnoWYUf535UgdfzDdpnO89Iizx0+/+UgsJ0NgnA g+rK6C1GvYVZGQpdJZmP+Hm3VxUE8OJxrSb68= MIME-Version: 1.0 Received: by 10.204.141.9 with SMTP id k9mr375252bku.93.1328147290747; Wed, 01 Feb 2012 17:48:10 -0800 (PST) Sender: tomosann@gmail.com Received: by 10.205.45.136 with HTTP; Wed, 1 Feb 2012 17:48:10 -0800 (PST) In-Reply-To: <4F03B818.6000100@gmail.com> References: <4F03B818.6000100@gmail.com> Date: Thu, 2 Feb 2012 10:48:10 +0900 X-Google-Sender-Auth: 1Up8GyyMZhuV2WJxvHsgvat5aFI Message-ID: Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt From: Tomoyuki Sahara To: 6man Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:48:12 -0000 On Wed, Jan 4, 2012 at 11:23 AM, Brian E Carpenter wrote: > Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > > We'd like feedback on this. In particular, which of the two options > proposed do people prefer? OPTION 2 seems better to me. It's easier to implement. Thanks, Tomoyuki From fgont@si6networks.com Wed Feb 1 16:49:48 2012 Return-Path: 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 8D62711E809C for ; Wed, 1 Feb 2012 16:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.789, 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 AbJoSAMQ-uyJ for ; Wed, 1 Feb 2012 16:49:48 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E811E8098 for ; Wed, 1 Feb 2012 16:49:47 -0800 (PST) Received: from [190.48.223.230] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rskry-0007LF-Nz; Thu, 02 Feb 2012 01:49:47 +0100 Message-ID: <4F29DDA5.2060405@si6networks.com> Date: Wed, 01 Feb 2012 21:49:41 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: undisclosed-recipients:; Subject: Fwd: RA-Guard: Advice on the implementation (feedback requested) X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Feb 2012 17:49:01 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 00:49:48 -0000 FYI. Please post your comments to the *v6ops* mailing-list , and CC me if possible). Thanks! Best regards, Fernando -------- Original Message -------- Subject: RA-Guard: Advice on the implementation (feedback requested) Date: Wed, 01 Feb 2012 21:44:29 -0300 From: Fernando Gont Organization: SI6 Networks To: IPv6 Operations Folks, We have just published a revision of our I-D "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" . In essence, this is the problem statement, and what this I-D is about: * RA-Guard is essential to have feature parity with IPv4. * Most (all?) existing RA-Guard implementations can be trivially evaded: if the attacker includes extension headers in his packets, the RA-Guard devices fail to identify the Router Advertisement messages. -- For instance, THC's "IPv6 attack suite" () contains tools that can evade RA-Guard as indicated. * The I-D discusses this problem, and provides advice on how to implement RA-Guard, such that the aforementioned vulnerabilities are eliminated, we have an effective RA-Guard device, and hence feature-parity with IPv4. We'd like feedback on this I-D, including high-level comments on whether you support the proposal in this I-D. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Thu Feb 2 14:07:14 2012 Return-Path: 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 EA29421F867C; Thu, 2 Feb 2012 14:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 81CbmTbaAL2P; Thu, 2 Feb 2012 14:07:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7184621F85D4; Thu, 2 Feb 2012 14:07:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120202220713.1563.44684.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2012 14:07:13 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:07:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Processing of IPv6 "atomic" fragments Author(s) : Fernando Gont Filename : draft-ietf-6man-ipv6-atomic-fragments-00.txt Pages : 14 Date : 2012-02-01 The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-atomic-fragments-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-ipv6-atomic-fragments-00= .txt From ietfc@btconnect.com Fri Feb 3 06:48:27 2012 Return-Path: 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 5088B21F85A1 for ; Fri, 3 Feb 2012 06:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.935, 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 gwLXdpGEidZt for ; Fri, 3 Feb 2012 06:48:26 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id F26BE21F852D for ; Fri, 3 Feb 2012 06:48:25 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr10.btconnect.com with SMTP id GEJ32216; Fri, 03 Feb 2012 14:48:24 +0000 (GMT) Message-ID: <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> From: "t.petch" To: "6man" , References: <4F03B818.6000100@gmail.com> Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Date: Fri, 3 Feb 2012 14:47:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4F2BF3B7.008C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, __STOCK_PHRASE_7, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1800_1899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F2BF3B8.001C,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:48:27 -0000 Brian Did you look at the INET-ADDRESS-MIB when preparing this? I ask because it defines [RFC4001] a 4 byte zone index; and a display hint of 'd' is decimal:-) "InetAddressIPv6z ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" DESCRIPTION "Represents a non-global IPv6 network address, together with its zone index: Octets Contents Encoding 1-16 IPv6 address network-byte order 17-20 zone index network-byte order The corresponding InetAddressType value is ipv6z(4). The zone index (bytes 17-20) is used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. The zone index may contain the special value 0, which refers to the default zone for each scope. SYNTAX OCTET STRING (SIZE (20)) Tom Petch ----- Original Message ----- From: "Tomoyuki Sahara" To: "6man" Sent: Thursday, February 02, 2012 2:48 AM Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt > On Wed, Jan 4, 2012 at 11:23 AM, Brian E Carpenter > wrote: > > Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > > > > We'd like feedback on this. In particular, which of the two options > > proposed do people prefer? > > OPTION 2 seems better to me. > It's easier to implement. > > > Thanks, > Tomoyuki > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From brian.e.carpenter@gmail.com Fri Feb 3 11:11:57 2012 Return-Path: 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 AA94821F85C5 for ; Fri, 3 Feb 2012 11:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 hsXPymwAOk0l for ; Fri, 3 Feb 2012 11:11:57 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B102721F85AD for ; Fri, 3 Feb 2012 11:11:56 -0800 (PST) Received: by eaae12 with SMTP id e12so1505807eaa.31 for ; Fri, 03 Feb 2012 11:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4YExgQjVt3X/li87bYSLwafHs9SDYHQ8tNGVIiBaerw=; b=nOG7ZF/xsLpI0uhgRtaGyRCKwdvhmAFFymiMTshapLTqh+8aC5G4DSfH10vEQjmuW7 LaS5nh81l80sSt13m7VVH28sMtH/v6AwjK1LjGaSekdV18qm5Ss3cXJ1CW3qIBW1evgC Kah9cBN7+TmjYRXnNxAEnel+Hy4fN8+dl3n0A= Received: by 10.213.7.80 with SMTP id c16mr1392946ebc.7.1328296315866; Fri, 03 Feb 2012 11:11:55 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id e12sm25064649eea.5.2012.02.03.11.11.52 (version=SSLv3 cipher=OTHER); Fri, 03 Feb 2012 11:11:54 -0800 (PST) Message-ID: <4F2C316D.4070008@gmail.com> Date: Sat, 04 Feb 2012 08:11:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> In-Reply-To: <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 19:11:57 -0000 Thanks Tom, this is new to me. I don't understand where the 'decimal' hint comes from, given that the practice has always been to use alphanumerics. Does anyone know if this is actually used, and if so, how? Regards Brian Carpenter On 2012-02-04 02:47, t.petch wrote: > Brian > > Did you look at the INET-ADDRESS-MIB when preparing this? I ask because it > defines [RFC4001] a 4 byte zone index; and a display hint of 'd' is decimal:-) > > "InetAddressIPv6z ::= TEXTUAL-CONVENTION > DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" > DESCRIPTION > "Represents a non-global IPv6 network address, together > with its zone index: > > Octets Contents Encoding > 1-16 IPv6 address network-byte order > 17-20 zone index network-byte order > > The corresponding InetAddressType value is ipv6z(4). > > The zone index (bytes 17-20) is used to disambiguate > identical address values on nodes that have interfaces > attached to different zones of the same scope. The zone index > may contain the special value 0, which refers to the default > zone for each scope. > SYNTAX OCTET STRING (SIZE (20)) > > Tom Petch > > ----- Original Message ----- > From: "Tomoyuki Sahara" > To: "6man" > Sent: Thursday, February 02, 2012 2:48 AM > Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt > > >> On Wed, Jan 4, 2012 at 11:23 AM, Brian E Carpenter >> wrote: >>> Representing IPv6 Zone Identifiers in Uniform Resource Identifiers >>> >>> We'd like feedback on this. In particular, which of the two options >>> proposed do people prefer? >> OPTION 2 seems better to me. >> It's easier to implement. >> >> >> Thanks, >> Tomoyuki >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > From ietfc@btconnect.com Fri Feb 3 13:01:27 2012 Return-Path: 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 BBE9F21F84F8 for ; Fri, 3 Feb 2012 13:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 5s1PRyrRYvF8 for ; Fri, 3 Feb 2012 13:01:27 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6BB21F84CE for ; Fri, 3 Feb 2012 13:01:25 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr10.btconnect.com with SMTP id GBX66008; Fri, 03 Feb 2012 21:01:24 +0000 (GMT) Message-ID: <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Brian E Carpenter" References: <4F03B818.6000100@gmail.com><00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Date: Fri, 3 Feb 2012 21:01:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4F2C4B23.002C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, __STOCK_PHRASE_7, __LINES_OF_YELLING, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4F2C4B24.003F,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:01:27 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "t.petch" Cc: "6man" Sent: Friday, February 03, 2012 8:11 PM > Thanks Tom, this is new to me. I don't understand > where the 'decimal' hint comes from, given that the > practice has always been to use alphanumerics. > > Does anyone know if this is actually used, and if so, how? Brian My exposure to zoneids started with the installation of Windows 2000 Servers, but there was no SNMP involved there; I cannot recall if URI were in use, I think not, and the ids I saw were, I think, numeric. I did see that RFC4007 says that " Implementations choosing to follow the recommended basic API [10] will want to restrict their index values to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure." but I am not sure what that means, in terms of character set. Tom Petch > > Regards > Brian Carpenter > > On 2012-02-04 02:47, t.petch wrote: > > Brian > > > > Did you look at the INET-ADDRESS-MIB when preparing this? I ask because it > > defines [RFC4001] a 4 byte zone index; and a display hint of 'd' is decimal:-) > > > > "InetAddressIPv6z ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" > > DESCRIPTION > > "Represents a non-global IPv6 network address, together > > with its zone index: > > > > Octets Contents Encoding > > 1-16 IPv6 address network-byte order > > 17-20 zone index network-byte order > > > > The corresponding InetAddressType value is ipv6z(4). > > > > The zone index (bytes 17-20) is used to disambiguate > > identical address values on nodes that have interfaces > > attached to different zones of the same scope. The zone index > > may contain the special value 0, which refers to the default > > zone for each scope. > > SYNTAX OCTET STRING (SIZE (20)) > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Tomoyuki Sahara" > > To: "6man" > > Sent: Thursday, February 02, 2012 2:48 AM > > Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt > > > > > >> On Wed, Jan 4, 2012 at 11:23 AM, Brian E Carpenter > >> wrote: > >>> Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > >>> > >>> We'd like feedback on this. In particular, which of the two options > >>> proposed do people prefer? > >> OPTION 2 seems better to me. > >> It's easier to implement. > >> > >> > >> Thanks, > >> Tomoyuki > >> -------------------------------------------------------------------- > >> 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 > -------------------------------------------------------------------- > > From fgont@si6networks.com Fri Feb 3 13:23:58 2012 Return-Path: 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 0AF3D21F85E5 for ; Fri, 3 Feb 2012 13:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.713, 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 03s93Em5yJtm for ; Fri, 3 Feb 2012 13:23:57 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7700721F858B for ; Fri, 3 Feb 2012 13:23:57 -0800 (PST) Received: from [190.48.237.225] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RtQbp-0003Aq-OM; Fri, 03 Feb 2012 22:23:54 +0100 Message-ID: <4F2C45FD.9070607@si6networks.com> Date: Fri, 03 Feb 2012 17:39:25 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> In-Reply-To: <4F2C316D.4070008@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:23:58 -0000 On 02/03/2012 04:11 PM, Brian E Carpenter wrote: > Thanks Tom, this is new to me. I don't understand > where the 'decimal' hint comes from, given that the > practice has always been to use alphanumerics. > > Does anyone know if this is actually used, and if so, how? Jumping into the "discussion" -- (please shell if I misunderstood the question). Windows uses decimal zone-ID's. e.g.; fe80::1%1 (where %1, %2, etc. are the different interfaces...) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Fri Feb 3 13:25:21 2012 Return-Path: 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 DD3E211E807F for ; Fri, 3 Feb 2012 13:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 wZcXk2aX5SwR for ; Fri, 3 Feb 2012 13:25:21 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D564B21F85DB for ; Fri, 3 Feb 2012 13:25:20 -0800 (PST) Received: by eekc41 with SMTP id c41so1273101eek.31 for ; Fri, 03 Feb 2012 13:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MchJ7NKByFxvECm3kYs6s5TBwsrdKZudkZI/8FuFZDY=; b=br9ZVr+moRiCjuFJx5KW8gCzkgdFvi+WYeuvMhJuHqXr6gLZ8l0K8ycJF38JhhNT9w lJqhR/yZImOfky/Rj9UTgu23svX1RGVqpInmzSmsHWy6FlK+jlI5HN/0o+BM4c7Idv66 N+HWjaqI7xxK7gsg1p8wNFaAG2XzZDXyWCVNA= Received: by 10.14.97.70 with SMTP id s46mr2717393eef.54.1328304318172; Fri, 03 Feb 2012 13:25:18 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id e12sm26380990eea.5.2012.02.03.13.25.15 (version=SSLv3 cipher=OTHER); Fri, 03 Feb 2012 13:25:17 -0800 (PST) Message-ID: <4F2C50B4.1080004@gmail.com> Date: Sat, 04 Feb 2012 10:25:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com><00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> In-Reply-To: <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:25:22 -0000 On 2012-02-04 09:01, t.petch wrote: > ----- Original Message ----- > From: "Brian E Carpenter" > To: "t.petch" > Cc: "6man" > Sent: Friday, February 03, 2012 8:11 PM >> Thanks Tom, this is new to me. I don't understand >> where the 'decimal' hint comes from, given that the >> practice has always been to use alphanumerics. >> >> Does anyone know if this is actually used, and if so, how? > > Brian > > My exposure to zoneids started with the installation of Windows 2000 > Servers, but there was no SNMP involved there; I cannot recall if > URI were in use, I think not, and the ids I saw were, I think, numeric. > > I did see that RFC4007 says that > " Implementations choosing to follow the > recommended basic API [10] will want to restrict their index values > to those that can be represented by the sin6_scope_id field of the > sockaddr_in6 structure." > but I am not sure what that means, in terms of character set. Not much, since it's a uint32_t. "Linux only supports it for link scope addresses, in that case sin6_scope_id contains the interface index (see netdevice(7)) " In other words, if it's presented as "eth0" or "foobar99" in a URI, it will get mapped into an interface number before it goes into a socket call. That mapping will be o/s and host dependent. At least in Linux, it's netdevice ioctls that convert between an interface name and its index number. "SIOCGIFNAME Given the ifr_ifindex, return the name of the interface in ifr_name. This is the only ioctl which returns its result in ifr_name. SIOCGIFINDEX Retrieve the interface index of the interface into ifr_ifindex. " I assume that the MIB is intended to hold the index, up to 4 bytes long, not the name. Brian > > Tom Petch > > >> Regards >> Brian Carpenter >> >> On 2012-02-04 02:47, t.petch wrote: >>> Brian >>> >>> Did you look at the INET-ADDRESS-MIB when preparing this? I ask because it >>> defines [RFC4001] a 4 byte zone index; and a display hint of 'd' is > decimal:-) >>> "InetAddressIPv6z ::= TEXTUAL-CONVENTION >>> DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" >>> DESCRIPTION >>> "Represents a non-global IPv6 network address, together >>> with its zone index: >>> >>> Octets Contents Encoding >>> 1-16 IPv6 address network-byte order >>> 17-20 zone index network-byte order >>> >>> The corresponding InetAddressType value is ipv6z(4). >>> >>> The zone index (bytes 17-20) is used to disambiguate >>> identical address values on nodes that have interfaces >>> attached to different zones of the same scope. The zone index >>> may contain the special value 0, which refers to the default >>> zone for each scope. >>> SYNTAX OCTET STRING (SIZE (20)) >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Tomoyuki Sahara" >>> To: "6man" >>> Sent: Thursday, February 02, 2012 2:48 AM >>> Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt >>> >>> >>>> On Wed, Jan 4, 2012 at 11:23 AM, Brian E Carpenter >>>> wrote: >>>>> Representing IPv6 Zone Identifiers in Uniform Resource Identifiers >>>>> >>>>> We'd like feedback on this. In particular, which of the two options >>>>> proposed do people prefer? >>>> OPTION 2 seems better to me. >>>> It's easier to implement. >>>> >>>> >>>> Thanks, >>>> Tomoyuki >>>> -------------------------------------------------------------------- >>>> 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 >> -------------------------------------------------------------------- >> >> > > From jinmei@isc.org Fri Feb 3 23:11:58 2012 Return-Path: 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 2D6BD21F8531 for ; Fri, 3 Feb 2012 23:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] 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 5kKtXYd-7PxS for ; Fri, 3 Feb 2012 23:11:57 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3F21F84D0 for ; Fri, 3 Feb 2012 23:11:57 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 36B65C9476; Sat, 4 Feb 2012 07:11:45 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E43F7216C6B; Sat, 4 Feb 2012 07:11:44 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Fri, 03 Feb 2012 23:11:44 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "t.petch" Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt In-Reply-To: <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> References: <4F03B818.6000100@gmail.com> <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 07:11:58 -0000 At Fri, 3 Feb 2012 21:01:32 +0100, "t.petch" wrote: > My exposure to zoneids started with the installation of Windows 2000 > Servers, but there was no SNMP involved there; I cannot recall if > URI were in use, I think not, and the ids I saw were, I think, numeric. > > I did see that RFC4007 says that > " Implementations choosing to follow the > recommended basic API [10] will want to restrict their index values > to those that can be represented by the sin6_scope_id field of the > sockaddr_in6 structure." > but I am not sure what that means, in terms of character set. (I've not read the the uri-zoneid draft, but anyway) In terms of RFC4007 zone indices are primarily numeric numbers. Only in the textual representation of
%, and only optionally for convenience, the zone_id part can be a more human-understandable form, such as an network interface name that can uniquely identify the corresponding zone in the context of
%. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From brian@innovationslab.net Sat Feb 4 05:20:45 2012 Return-Path: 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 1AA3821F853E for ; Sat, 4 Feb 2012 05:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gKPwrXY-UTx0 for ; Sat, 4 Feb 2012 05:20:42 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 27DFA21F84E0 for ; Sat, 4 Feb 2012 05:20:41 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DFD1B881D0 for ; Sat, 4 Feb 2012 05:20:41 -0800 (PST) Received: from clemson.local (ip68-10-153-35.hr.hr.cox.net [68.10.153.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 829AC130009 for ; Sat, 4 Feb 2012 05:20:41 -0800 (PST) Message-ID: <4F2D30A7.1090004@innovationslab.net> Date: Sat, 04 Feb 2012 08:20:39 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 13:20:45 -0000 On 2/4/12 2:11 AM, JINMEI Tatuya / 神明é”哉 wrote: > At Fri, 3 Feb 2012 21:01:32 +0100, > "t.petch" wrote: > >> My exposure to zoneids started with the installation of Windows 2000 >> Servers, but there was no SNMP involved there; I cannot recall if >> URI were in use, I think not, and the ids I saw were, I think, numeric. >> >> I did see that RFC4007 says that >> " Implementations choosing to follow the >> recommended basic API [10] will want to restrict their index values >> to those that can be represented by the sin6_scope_id field of the >> sockaddr_in6 structure." >> but I am not sure what that means, in terms of character set. > > (I've not read the the uri-zoneid draft, but anyway) In terms of > RFC4007 zone indices are primarily numeric numbers. Only in the > textual representation of
%, and only optionally for > convenience, the zone_id part can be a more human-understandable form, > such as an network interface name that can uniquely identify the > corresponding zone in the context of
%. The zone ID information included in the InetAddressIPv6z object in RFC 4001 was modeled after the description of the zone ID in RFC 4007. As Jinmei points out, the user friendly name is mapped to an easily indexed interface number to determine the actual zone. Regards, Brian From brian.e.carpenter@gmail.com Sat Feb 4 11:24:55 2012 Return-Path: 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 5C7A621F84A1 for ; Sat, 4 Feb 2012 11:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZnH674GgJ4Eo for ; Sat, 4 Feb 2012 11:24:54 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A18B921F848A for ; Sat, 4 Feb 2012 11:24:54 -0800 (PST) Received: by eekc41 with SMTP id c41so1602623eek.31 for ; Sat, 04 Feb 2012 11:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DKuFpbC6aTU4026A0V1QKPsMgc+MY8LVVDYNa68bMWk=; b=KosQrw/WBjpk2HCcrH6/g3EG/fy8NcqJ9+QT45FFR9EN9uPJDcM1Z0nCnfLOdJb5qG qP4DfMSCDtL8dS7XQXIscb5mWfWZDQarmG79zrwboU6vYqi1wOwI/DxiMjMD/3eJzPD0 3pg9aNTy76x6/t3vmQXM52ElsECq/okqLIIhE= Received: by 10.14.94.134 with SMTP id n6mr3673040eef.63.1328383493850; Sat, 04 Feb 2012 11:24:53 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x4sm38484796eeb.4.2012.02.04.11.24.50 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 11:24:52 -0800 (PST) Message-ID: <4F2D85F6.4080101@gmail.com> Date: Sun, 05 Feb 2012 08:24:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <00e801cce27a$87f0e260$4001a8c0@gateway.2wire.net> <4F2C316D.4070008@gmail.com> <000901cce2ae$a332bce0$4001a8c0@gateway.2wire.net> <4F2D30A7.1090004@innovationslab.net> In-Reply-To: <4F2D30A7.1090004@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 19:24:55 -0000 On 2012-02-05 02:20, Brian Haberman wrote: > On 2/4/12 2:11 AM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: >> At Fri, 3 Feb 2012 21:01:32 +0100, >> "t.petch" wrote: >> >>> My exposure to zoneids started with the installation of Windows 2000 >>> Servers, but there was no SNMP involved there; I cannot recall if >>> URI were in use, I think not, and the ids I saw were, I think, numeri= c. >>> >>> I did see that RFC4007 says that >>> " Implementations choosing to follow the >>> recommended basic API [10] will want to restrict their index valu= es >>> to those that can be represented by the sin6_scope_id field of th= e >>> sockaddr_in6 structure." >>> but I am not sure what that means, in terms of character set. >> >> (I've not read the the uri-zoneid draft, but anyway) In terms of >> RFC4007 zone indices are primarily numeric numbers. Only in the >> textual representation of
%, and only optionally for >> convenience, the zone_id part can be a more human-understandable form,= >> such as an network interface name that can uniquely identify the >> corresponding zone in the context of
%. >=20 > The zone ID information included in the InetAddressIPv6z object in RFC > 4001 was modeled after the description of the zone ID in RFC 4007. As > Jinmei points out, the user friendly name is mapped to an easily indexe= d > interface number to determine the actual zone. >=20 > Regards, > Brian Exactly, and obviously in a URI it will be the user friendly name. The mapping is a host-specific function. Brian C From sreenatha.b@huawei.com Mon Feb 6 03:02:58 2012 Return-Path: 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 99BF021F85BD for ; Mon, 6 Feb 2012 03:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 0+JQ8eGskrGa for ; Mon, 6 Feb 2012 03:02:57 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 781C021F85B4 for ; Mon, 6 Feb 2012 03:02:57 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYY00B29X9R8U@szxga03-in.huawei.com> for ipv6@ietf.org; Mon, 06 Feb 2012 19:01:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYY008D4X9I5E@szxga03-in.huawei.com> for ipv6@ietf.org; Mon, 06 Feb 2012 19:01:03 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW22817; Mon, 06 Feb 2012 19:00:19 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 19:00:17 +0800 Received: from blrprnc08ns (10.18.96.97) by szxeml413-hub.china.huawei.com (10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Mon, 06 Feb 2012 19:00:27 +0800 Date: Mon, 06 Feb 2012 16:30:09 +0530 From: sreenatha Subject: Querry regarding Hop-by-Hop extension header processing. X-Originating-IP: [10.18.96.97] To: ipv6@ietf.org Message-id: <002401cce4be$7eb91640$7c2b42c0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sOcMXEmUZpb9KdmLR8fDvA)" Content-language: en-us Thread-index: Aczkvn36rFGi7BC6S0+Pu5hEGOasWQ== X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 06 Feb 2012 03:43:09 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:02:58 -0000 --Boundary_(ID_sOcMXEmUZpb9KdmLR8fDvA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Folks, I have one query. In section 4 of RFC 2460, it is said that Hop-by-Hop extension header should be processed by all nodes including the Source and destination nodes. What is the point in processing the Hop-by-Hop extension header by Source node if the node only inserting the Header? Thanks- B.Sreenatha Setty, Software Engineer, Huawei Technologies India Private Ltd., Bangalore ---------------------------------------------------------------------------- -------------------------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ---------------------------------------------------------------------------- -------------------------------------------------------------------------- --Boundary_(ID_sOcMXEmUZpb9KdmLR8fDvA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Folks,

     I have one query. In section 4 of RFC 2460, it is said that Hop-by-Hop extension header should be processed by all nodes including the Source and destination nodes. What is the point in processing the Hop-by-Hop extension header by Source node if the node only inserting the Header?

 

 

Thanks-

B.Sreenatha Setty,

Software Engineer,

Huawei Technologies India Private Ltd.,

Bangalore

------------------------------------------------------------------------------------------------------------------------------------------------------

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immedia /o:p>

------------------------------------------------------------------------------------------------------------------------------------------------------

 

--Boundary_(ID_sOcMXEmUZpb9KdmLR8fDvA)-- From shtsuchi@cisco.com Mon Feb 6 09:01:41 2012 Return-Path: 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 7E6B721F869D; Mon, 6 Feb 2012 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9HvDrxylBllH; Mon, 6 Feb 2012 09:01:41 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B25821F8643; Mon, 6 Feb 2012 09:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2029; q=dns/txt; s=iport; t=1328547700; x=1329757300; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pPqTRhm29sGtwai2xWMA5EN27nFu8AZsgjk54NS4fm8=; b=fmnAIob+yI3IliCCrvZjUShTGcH402uIvvwh65SqscerAorh+3JQmxcS emtfv2V9GmEhgCbOTXs2iJaxLd9FODEnDwAo9P6kILFHJShZXVemzOqSi 84ItZRjhoS7SxvEYGGrEvG/JsgftQdswVTuvwHIq9dLBZcMjkPlaUmdRC U=; X-IronPort-AV: E=Sophos;i="4.73,371,1325462400"; d="scan'208";a="4938292" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 06 Feb 2012 17:01:38 +0000 Received: from [10.70.230.103] (tky-vpn-client-230-103.cisco.com [10.70.230.103]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q16H1YNg018372; Mon, 6 Feb 2012 17:01:35 GMT Message-ID: <4F30076A.4040509@cisco.com> Date: Tue, 07 Feb 2012 02:01:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Softwires@ietf.org, ipv6@ietf.org, dthaler@microsoft.com Subject: Fwd: I-D Action: draft-cai-softwire-6rd-mib-01.txt References: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> In-Reply-To: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: draft-fu-softwire-4rd-mib@tools.ietf.org, draft-cai-softwire-6rd-mib@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:01:41 -0000 Dave Thaler,Softwire WG and 6man WG We have published 6rd mib draft. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01 6rd MIB is charter item of softwire wg. https://datatracker.ietf.org/wg/softwire/charter/ We felt lack of current IP TUNNEL MIB(RFC4087) to support 6rd and modern tunnel protocol. So the draft described two approaches to support 6rd mib. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01#section-5 1.New module approach like a L2TP MIB [RFC3371] 2.Extend IP TUNNEL MIB to support 6rd,4rd and so on. 4rd MIB draft was published on last week. http://tools.ietf.org/html/draft-fu-softwire-4rd-mib-00 Which approach is good for us? We need feedback and comments. I would appreciate any comments. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-cai-softwire-6rd-mib-01.txt Date: Fri, 3 Feb 2012 17:18:50 +0800 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for 6rd Author(s) : Lei Cai Jacni Qin Shishio Tsuchiya Filename : draft-cai-softwire-6rd-mib-01.txt Pages : 11 Date : 2012-02-03 This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cai-softwire-6rd-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-cai-softwire-6rd-mib-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From iesg-secretary@ietf.org Mon Feb 6 09:04:52 2012 Return-Path: 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 B486B21F86AA; Mon, 6 Feb 2012 09:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, 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 Ewj52Y2OhPRx; Mon, 6 Feb 2012 09:04:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6719D21F86B2; Mon, 6 Feb 2012 09:04:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'An uniform format for IPv6 extension headers' to Proposed Standard (draft-ietf-6man-exthdr-06.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120206170451.8586.40945.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 09:04:51 -0800 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:04:52 -0000 The IESG has approved the following document: - 'An uniform format for IPv6 extension headers' (draft-ietf-6man-exthdr-06.txt) as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-exthdr/ Technical Summary This document describes the issues that can arise when defining new extension headers and discusses the alternative extension mechanisms in IPv6. It also provides a format for defining new IPv6 extension headers that would allow implementations to process past unknown extension headers. Working Group Summary This document was reviewed by the 6man WG and represents the consensus of that groups. Document Quality This document has been reviewed by the members and co-chairs of the 6MAN working group. Personnel The responsible Area Director is Jari Arkko. The Document Shepherd is Brian Haberman. RFC Editor Note Add "Updates: RFC 2460" to the header. From iesg-secretary@ietf.org Mon Feb 6 12:23:49 2012 Return-Path: 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 4D88621F8743; Mon, 6 Feb 2012 12:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 pwDsxxxaI3ca; Mon, 6 Feb 2012 12:23:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A85C21F8759; Mon, 6 Feb 2012 12:23:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'RFC3627 to Historic status' to Informational RFC (draft-ietf-6man-3627-historic-01.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120206202348.695.4663.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 12:23:48 -0800 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 20:23:49 -0000 The IESG has approved the following document: - 'RFC3627 to Historic status' (draft-ietf-6man-3627-historic-01.txt) as an Informational RFC This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ Technical Summary This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to HISTORIC status to reflect the updated guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links). While a standards track document already supersedes an informational document and therefore RFC6164 is the appropriate guidance to follow when the two documents are in conflict, this links the two documents so that it is clearer that the IETF has updated guidance on the matter. Working Group Summary This document was reviewed by the 6man WG and represents the consensus of the group. Document Quality This document formally moves RFC 3627 to Historic given the existence and use of RFC 6164. Personnel Brian Haberman is the Document Shepherd and Jari Arkko is the responsible Area Director. From j.schoenwaelder@jacobs-university.de Tue Feb 7 02:41:17 2012 Return-Path: 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 B134721F87AD for ; Tue, 7 Feb 2012 02:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 QiTEJ4eQSbTn for ; Tue, 7 Feb 2012 02:41:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D17B721F8767 for ; Tue, 7 Feb 2012 02:41:16 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2974D20BFF; Tue, 7 Feb 2012 11:41:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QNn3Ff4ywXkx; Tue, 7 Feb 2012 11:41:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3B1A20BFE; Tue, 7 Feb 2012 11:41:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9673E1CEE5B5; Tue, 7 Feb 2012 11:40:58 +0100 (CET) Date: Tue, 7 Feb 2012 11:40:58 +0100 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Message-ID: <20120207104058.GA23771@elstar.local> Mail-Followup-To: Brian E Carpenter , 6man References: <4F03B818.6000100@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F03B818.6000100@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:41:17 -0000 Hi, I have one question. The I-D restricts zoneid names to 15 characters: ZoneID = 1*15unreserved This raises the question why limiting this to 15 characters. I know that at my Linux and MacOS X boxes have this limit (and I would not be surprised if BSDs do as well) but at the end it is a #define. So the question is whether this limit should be hard coded in the URI format. Looking at RFC 3986, I see reg-name = *( unreserved / pct-encoded / sub-delims ) or port = *DIGIT and it appears there is no limit in the URI format on DNS names or port numbers (even though today's DNS and transport protocols put limits on those things). /js PS: I am asking this question because there is a MIB object ifName that has a limit of 255 ASCII characters (I assume basically due to SNMP constraints) and there is a YANG module in the making which currently allows 255 UTF-8 characters and I think it would be nice to think a moment about how these things fit together. PS: RFC 3493 only says there is a constant IF_NAMESIZE - so the socket API does not really say what the interface name size limit really is. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Tue Feb 7 03:05:22 2012 Return-Path: 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 52B2121F86D9 for ; Tue, 7 Feb 2012 03:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, 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 6GRYXpC+94v5 for ; Tue, 7 Feb 2012 03:05:21 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3F121F861B for ; Tue, 7 Feb 2012 03:05:20 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr14.btconnect.com with SMTP id GDU26611; Tue, 07 Feb 2012 11:05:17 +0000 (GMT) Message-ID: <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Brian E Carpenter" References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Date: Tue, 7 Feb 2012 11:05:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F31056C.00C1, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F31056D.0120,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:05:22 -0000 Juergen This topic kicked off with http://www.ietf.org/mail-archive/web/ipv6/current/msg14975.html as a report of some unexpected behaviour in Firefox and the view there was that BSD and Linux imposed a limit of 15 characters. The question also arose as to whether or not this impacted DNS. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Brian E Carpenter" Cc: "6man" Sent: Tuesday, February 07, 2012 11:40 AM Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt > Hi, > > I have one question. The I-D restricts zoneid names to 15 characters: > > ZoneID = 1*15unreserved > > This raises the question why limiting this to 15 characters. I know > that at my Linux and MacOS X boxes have this limit (and I would not be > surprised if BSDs do as well) but at the end it is a #define. So the > question is whether this limit should be hard coded in the URI format. > Looking at RFC 3986, I see > > reg-name = *( unreserved / pct-encoded / sub-delims ) > or > port = *DIGIT > > and it appears there is no limit in the URI format on DNS names or > port numbers (even though today's DNS and transport protocols put > limits on those things). > > /js > > PS: I am asking this question because there is a MIB object ifName > that has a limit of 255 ASCII characters (I assume basically due > to SNMP constraints) and there is a YANG module in the making > which currently allows 255 UTF-8 characters and I think it would > be nice to think a moment about how these things fit together. > > PS: RFC 3493 only says there is a constant IF_NAMESIZE - so the socket > API does not really say what the interface name size limit really > is. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From j.schoenwaelder@jacobs-university.de Tue Feb 7 04:59:09 2012 Return-Path: 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 D9ACF21F8748 for ; Tue, 7 Feb 2012 04:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 K1896EjK4way for ; Tue, 7 Feb 2012 04:59:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 181A521F8751 for ; Tue, 7 Feb 2012 04:59:09 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 687AD20C70; Tue, 7 Feb 2012 13:59:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jxYjHRCTLFbT; Tue, 7 Feb 2012 13:59:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 074B020C36; Tue, 7 Feb 2012 13:59:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 027F81CEE8A1; Tue, 7 Feb 2012 13:58:49 +0100 (CET) Date: Tue, 7 Feb 2012 13:58:49 +0100 From: Juergen Schoenwaelder To: "t.petch" Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Message-ID: <20120207125849.GC24056@elstar.local> Mail-Followup-To: "t.petch" , Brian E Carpenter , 6man References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:59:10 -0000 On Tue, Feb 07, 2012 at 11:05:20AM +0100, t.petch wrote: > Juergen > > This topic kicked off with > http://www.ietf.org/mail-archive/web/ipv6/current/msg14975.html > as a report of some unexpected behaviour in Firefox and the view > there was that BSD and Linux imposed a limit of 15 characters. While 15 characters seem to be a common length restriction in todays Unix implementations, there does not seem to be an architectural constraint that it has to be 15 - the socket API functions say there is a limit but they leave it open what it is. On a really low-end Juniper router in our lab (without doing anything to it), I find interface names like sp-0/0/0.16383 - already 14 characters. But then I also realize that this interface name contains characters that do not fit the unreserved production of RFC 3986 either. So in short, I think we should avoid putting up length restrictions and we may need to think what to do about interface names that contain characters not matching the unreserved production of RFC 3986. Perhaps if all characters are digits, we can treat the value as an interface number as a last resort. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Tue Feb 7 12:53:17 2012 Return-Path: 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 6BD9521F879D for ; Tue, 7 Feb 2012 12:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 dP2Ms7qgXXKJ for ; Tue, 7 Feb 2012 12:53:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B552821F8790 for ; Tue, 7 Feb 2012 12:53:16 -0800 (PST) Received: by iagf6 with SMTP id f6so12700325iag.31 for ; Tue, 07 Feb 2012 12:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WeGmGkcaoWo0pe7P/Y50Az34MQq9BRas+7ybJnLgDjs=; b=A8yVEgPI731zyaUiBRmZnkaI1zV7+9bp5rPBiT/hHRLLs6eeUYhrgmPKjxc0gMXOAs DD+PQka65y0PFBvzqi0QRESAiot6El+Kno1GXmqKnzbbKijev91digZ1R6i3IWV7E0qc KZJUUQUaMAKvUhRlGQT97TqtcVeMIII304TN4= Received: by 10.50.88.132 with SMTP id bg4mr17764644igb.5.1328647995689; Tue, 07 Feb 2012 12:53:15 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id np10sm21843582igc.0.2012.02.07.12.53.12 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 12:53:14 -0800 (PST) Message-ID: <4F318F36.3000505@gmail.com> Date: Wed, 08 Feb 2012 09:53:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" , Brian E Carpenter , 6man Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> <20120207125849.GC24056@elstar.local> In-Reply-To: <20120207125849.GC24056@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:53:17 -0000 On 2012-02-08 01:58, Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 11:05:20AM +0100, t.petch wrote: >> Juergen >> >> This topic kicked off with >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14975.html >> as a report of some unexpected behaviour in Firefox and the view >> there was that BSD and Linux imposed a limit of 15 characters. > > While 15 characters seem to be a common length restriction in todays > Unix implementations, there does not seem to be an architectural > constraint that it has to be 15 - the socket API functions say there > is a limit but they leave it open what it is. On a really low-end > Juniper router in our lab (without doing anything to it), I find > interface names like sp-0/0/0.16383 - already 14 characters. But then > I also realize that this interface name contains characters that do > not fit the unreserved production of RFC 3986 either. > > So in short, I think we should avoid putting up length restrictions > and we may need to think what to do about interface names that contain > characters not matching the unreserved production of RFC 3986. I don't see any particular value in limiting the ZoneID string to 15. Reserved characters can always be % escaped; that's not an issue, but should be mentioned in the text. > Perhaps > if all characters are digits, we can treat the value as an interface > number as a last resort. The interface number is uint32 anyway, in the MIB and the socket API, which limits it to decimal 4294967295, i.e. ten characters. In any case the name/number mapping is host-specific and has nothing whatever to do with the URI format. Brian From j.schoenwaelder@jacobs-university.de Tue Feb 7 23:18:09 2012 Return-Path: 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 F1DB821F8653 for ; Tue, 7 Feb 2012 23:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 XsowHHvumFeP for ; Tue, 7 Feb 2012 23:18:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0629921F8525 for ; Tue, 7 Feb 2012 23:18:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A366120C03; Wed, 8 Feb 2012 08:18:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dxc8QjFvfDYR; Wed, 8 Feb 2012 08:18:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3ECD420C02; Wed, 8 Feb 2012 08:18:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 647E11D57D03; Wed, 8 Feb 2012 08:17:42 +0100 (CET) Date: Wed, 8 Feb 2012 08:17:42 +0100 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Message-ID: <20120208071741.GA36298@elstar.local> Mail-Followup-To: Brian E Carpenter , "t.petch" , 6man References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> <20120207125849.GC24056@elstar.local> <4F318F36.3000505@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F318F36.3000505@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 6man , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:18:10 -0000 On Wed, Feb 08, 2012 at 09:53:10AM +1300, Brian E Carpenter wrote: > I don't see any particular value in limiting the ZoneID string to 15. Good. > Reserved characters can always be % escaped; that's not an issue, > but should be mentioned in the text. The text currently says ZoneID = 1*15unreserved and my understanding of unreserved is that it does not allow % escaping. So the ZoneID production should likely be changed to something like this: ZoneID = *( unreserved / pct-encoded ) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Wed Feb 8 11:41:47 2012 Return-Path: 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 2B25F11E8094 for ; Wed, 8 Feb 2012 11:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 BB1Pc40O7mdK for ; Wed, 8 Feb 2012 11:41:46 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65311E808A for ; Wed, 8 Feb 2012 11:41:46 -0800 (PST) Received: by eaal12 with SMTP id l12so301635eaa.31 for ; Wed, 08 Feb 2012 11:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OReuYz66cXy+6Sd0N8N9bFbtZlI4Od2W50QqXZPw2Cg=; b=B9VBVunV9gkhbOotDNrwTXZbDAC6WQQb7xQmoCu2gOMs0YxigjrYBfReqXmqQAaKmW XFzTzwUpsUWdg6PXiDDlqoGD15V8BGDlUgLvW5/sgXVWyewTWV/LfrV05rbZrngZb0n4 Ops40gWHXeuHX0CRhJr6YRe0KqGdoYsgJ4LNE= Received: by 10.213.26.198 with SMTP id f6mr4640708ebc.25.1328730105100; Wed, 08 Feb 2012 11:41:45 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id z47sm573252eeh.9.2012.02.08.11.41.41 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 11:41:44 -0800 (PST) Message-ID: <4F32CFED.8040805@gmail.com> Date: Thu, 09 Feb 2012 08:41:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter , "t.petch" , 6man Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> <20120207125849.GC24056@elstar.local> <4F318F36.3000505@gmail.com> <20120208071741.GA36298@elstar.local> In-Reply-To: <20120208071741.GA36298@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:41:47 -0000 Hi Juergen, On 2012-02-08 20:17, Juergen Schoenwaelder wrote: > On Wed, Feb 08, 2012 at 09:53:10AM +1300, Brian E Carpenter wrote: > >> I don't see any particular value in limiting the ZoneID string to 15. > > Good. > >> Reserved characters can always be % escaped; that's not an issue, >> but should be mentioned in the text. > > The text currently says > > ZoneID = 1*15unreserved > > and my understanding of unreserved is that it does not allow % > escaping. So the ZoneID production should likely be changed to > something like this: > > ZoneID = *( unreserved / pct-encoded ) Well, I'd like a URI guru to confirm that, but it makes sense, except that it needs to be 1* since a null string isn't useful. The new draft has ZoneID = 1*unreserved but that's easy to fix. Thanks Brian From brian.e.carpenter@gmail.com Wed Feb 8 11:43:09 2012 Return-Path: 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 5684F21F848C for ; Wed, 8 Feb 2012 11:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7nCgTqxZ0hwS for ; Wed, 8 Feb 2012 11:43:08 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 637E921F8489 for ; Wed, 8 Feb 2012 11:43:08 -0800 (PST) Received: by eaal12 with SMTP id l12so302023eaa.31 for ; Wed, 08 Feb 2012 11:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=L7HJDZw2yUU04i9UGMTq9SDbeaWrQio3SL3y9f7MmnQ=; b=pxYoN2r0IkJybwt13yzUKM26xLesAM5bx7cTKiLhA46cI/gObRvHsteC5CVhc+Xlhn vv8XyHzhmutzew+N7ri824WQowVrxyQ1A9HzhBIKvqQNxKWAA9P9lCNCl2+nWD0aI197 GDYE15SmCkYTlXbYERU2RxDnA39OMYGTobK+k= Received: by 10.213.29.70 with SMTP id p6mr4629430ebc.78.1328730187486; Wed, 08 Feb 2012 11:43:07 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a58sm595415eeb.8.2012.02.08.11.43.05 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 11:43:07 -0800 (PST) Message-ID: <4F32D041.4060702@gmail.com> Date: Thu, 09 Feb 2012 08:42:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-carpenter-6man-uri-zoneid-01.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:43:09 -0000 FYI. This doesn't include the syntax comment that Juergen made. Is this ready for WG adoption? Brian + Bob -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-uri-zoneid-01.txt Date: Wed, 08 Feb 2012 11:23:00 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-carpenter-6man-uri-zoneid-01.txt Pages : 6 Date : 2012-02-08 This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From brian@innovationslab.net Wed Feb 8 11:51:58 2012 Return-Path: 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 1599121E8016 for ; Wed, 8 Feb 2012 11:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 JmXrheGeZ-zu for ; Wed, 8 Feb 2012 11:51:56 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A06F521E8014 for ; Wed, 8 Feb 2012 11:51:55 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 69A09880E7 for ; Wed, 8 Feb 2012 11:51:55 -0800 (PST) Received: from clemson.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1FD4E13680DC for ; Wed, 8 Feb 2012 11:51:55 -0800 (PST) Message-ID: <4F32D259.5030400@innovationslab.net> Date: Wed, 08 Feb 2012 14:51:53 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:51:58 -0000 All, This is a consensus call on adopting: Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-carpenter-6man-uri-zoneid-01.txt Pages : 6 Date : 2012-02-08 as a 6MAN WG document. This last call will end on February 17, 2012. Regards, Brian From kerlyn2001@gmail.com Wed Feb 8 12:07:26 2012 Return-Path: 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 2F4C221F84FF for ; Wed, 8 Feb 2012 12:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YaRRQSuFvpr9 for ; Wed, 8 Feb 2012 12:07:25 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0C21F844B for ; Wed, 8 Feb 2012 12:07:22 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so531145lbb.31 for ; Wed, 08 Feb 2012 12:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/rzcZMArcrRo+dy7l1lJ4vHMDIFfNvBp4kJxEtDrzKM=; b=FQR3zDOmdytTJrd/BUaZWixlfh5nmaGDSgc6tksPcP5mw7LHHrXrA4H4LM6Z6rEc2M FmF2rFIM53fUrG+v4C0iIIgkNGFuGKG6qGjc0IHSm59gbzCAMvCVSXSFXz//Hv1c9Lec Vd/weml+15aSMXCsrJNhxplY720/90QZDVgvo= MIME-Version: 1.0 Received: by 10.152.145.165 with SMTP id sv5mr16364086lab.29.1328731641861; Wed, 08 Feb 2012 12:07:21 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.44.7 with HTTP; Wed, 8 Feb 2012 12:07:21 -0800 (PST) In-Reply-To: <4F32D259.5030400@innovationslab.net> References: <4F32D259.5030400@innovationslab.net> Date: Wed, 8 Feb 2012 15:07:21 -0500 X-Google-Sender-Auth: ZCbJRbCnlzGUN_BJ2ASovWQ3dc8 Message-ID: Subject: Re: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt From: Kerry Lynn To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:07:26 -0000 Aye, -K- On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman w= rote: > All, > =A0 =A0 This is a consensus call on adopting: > > =A0 =A0 Title =A0 =A0 : Representing IPv6 Zone Identifiers in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Uniform Resource Identifiers > =A0 =A0 Author(s) : Brian Carpenter > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Robert M. Hinden > =A0 =A0 Filename =A0: draft-carpenter-6man-uri-zoneid-01.txt > =A0 =A0 Pages =A0 =A0 : 6 > =A0 =A0 Date =A0 =A0 =A0: 2012-02-08 > > as a 6MAN WG document. =A0This last call will end on February 17, 2012. > > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Wed Feb 8 12:33:21 2012 Return-Path: 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 7F09621F8594 for ; Wed, 8 Feb 2012 12:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 R2nVUByT3vb7 for ; Wed, 8 Feb 2012 12:33:21 -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 B221C21F8572 for ; Wed, 8 Feb 2012 12:33:20 -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 q18KXEIK011945 for ; Wed, 8 Feb 2012 20:33:14 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q18KXEIK011945 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1328733194; bh=mukb68BiXso0l9HWOyhE4ZxJHAE=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=LcRoFVT8D8kmQ2Ob6ruF7eYiuvEZDYFZIMqjwcforXRBnhtzUFtFdOFFCJ/IPbnxb xkltY7EOX/VkrUnG36Z0Gy1be7BzrnV0AznskrBN1OJueNSu0cg/YCrfqe3yP2oWEs xlfvb06A03BX170g/L+rvHZw3F+RX/zPmRfQ/syQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o17KXE0543752317Em ret-id none; Wed, 08 Feb 2012 20:33:14 +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 q18KX4KE012166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 Feb 2012 20:33:07 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt From: Tim Chown In-Reply-To: Date: Wed, 8 Feb 2012 20:33:04 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4F32D259.5030400@innovationslab.net> <905557FA-3658-4366-A8BD-2A5B166C44C7@ecs.soton.ac.uk> To: 6man Mailing List X-Mailer: Apple Mail (2.1251.1) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o17KXE054375231700; tid=o17KXE0543752317Em; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q18KXEIK011945 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:33:21 -0000 Adopt. On 8 Feb 2012, at 20:07, Kerry Lynn wrote: > Aye, -K- >=20 > On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman = wrote: >> All, >> This is a consensus call on adopting: >>=20 >> Title : Representing IPv6 Zone Identifiers in >> Uniform Resource Identifiers >> Author(s) : Brian Carpenter >> Robert M. Hinden >> Filename : draft-carpenter-6man-uri-zoneid-01.txt >> Pages : 6 >> Date : 2012-02-08 >>=20 >> as a 6MAN WG document. This last call will end on February 17, 2012. >>=20 >> Regards, >> Brian >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- From rogerj@gmail.com Wed Feb 8 23:39:57 2012 Return-Path: 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 889F421F85C3 for ; Wed, 8 Feb 2012 23:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 niRPFM6KYkB8 for ; Wed, 8 Feb 2012 23:39:56 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D342221F8456 for ; Wed, 8 Feb 2012 23:39:55 -0800 (PST) Received: by lahl5 with SMTP id l5so1437233lah.31 for ; Wed, 08 Feb 2012 23:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=izPJX8XsjbCnYuSTdPKgKo0RvS5weIwJqlug2Gn02ck=; b=aYC5dZjPgXjuDBtdhbakl0u+LK7nabduy1maWFbN0Txkq28gdrnR+Ky4mwRYf/hCEB JIiy1YYLGGoFLQ+WBQ+psgcbmh/1PV9KvF2TBnsWpMXNdWJYGv17DisMmM+y8Kr8p2KG F+5ypF49NlLr/qqqgL2+DmusiJPeuPk8VkHco= MIME-Version: 1.0 Received: by 10.112.29.6 with SMTP id f6mr212528lbh.69.1328773194850; Wed, 08 Feb 2012 23:39:54 -0800 (PST) Received: by 10.112.27.169 with HTTP; Wed, 8 Feb 2012 23:39:54 -0800 (PST) In-Reply-To: <4F32D259.5030400@innovationslab.net> References: <4F32D259.5030400@innovationslab.net> Date: Thu, 9 Feb 2012 08:39:54 +0100 Message-ID: Subject: Re: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 07:39:57 -0000 On Wed, Feb 8, 2012 at 8:51 PM, Brian Haberman w= rote: > All, > =A0 =A0 This is a consensus call on adopting: > > =A0 =A0 Title =A0 =A0 : Representing IPv6 Zone Identifiers in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Uniform Resource Identifiers > =A0 =A0 Author(s) : Brian Carpenter > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Robert M. Hinden > =A0 =A0 Filename =A0: draft-carpenter-6man-uri-zoneid-01.txt > =A0 =A0 Pages =A0 =A0 : 6 > =A0 =A0 Date =A0 =A0 =A0: 2012-02-08 > > as a 6MAN WG document. =A0This last call will end on February 17, 2012. adapt --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From ietfc@btconnect.com Fri Feb 10 04:44:01 2012 Return-Path: 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 11CC321F85D0 for ; Fri, 10 Feb 2012 04:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 kPcH4lYVZJ96 for ; Fri, 10 Feb 2012 04:44:00 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79321F85C4 for ; Fri, 10 Feb 2012 04:43:59 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr14.btconnect.com with SMTP id GFA80988; Fri, 10 Feb 2012 12:43:57 +0000 (GMT) Message-ID: <03cf01cce7e9$4806c060$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Brian E Carpenter" , "6man" References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> <20120207125849.GC24056@elstar.local> <4F318F36.3000505@gmail.com> <20120208071741.GA36298@elstar.local> <4F32CFED.8040805@gmail.com> Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Date: Fri, 10 Feb 2012 12:43:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F35110D.0065, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.2.10.115415:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1400_1499, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4F35110D.01D5,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:44:01 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "Brian E Carpenter" ; "t.petch" ; "6man" Sent: Wednesday, February 08, 2012 8:41 PM > Hi Juergen, > > On 2012-02-08 20:17, Juergen Schoenwaelder wrote: > > On Wed, Feb 08, 2012 at 09:53:10AM +1300, Brian E Carpenter wrote: > > > >> I don't see any particular value in limiting the ZoneID string to 15. > > > > Good. > > > >> Reserved characters can always be % escaped; that's not an issue, > >> but should be mentioned in the text. > > > > The text currently says > > > > ZoneID = 1*15unreserved > > > > and my understanding of unreserved is that it does not allow % > > escaping. So the ZoneID production should likely be changed to > > something like this: > > > > ZoneID = *( unreserved / pct-encoded ) > > Well, I'd like a URI guru to confirm that, but it makes sense, > except that it needs to be 1* since a null string isn't useful. Since this is an update to RFC3986, I think that, once this list has come to a consensus, then the I-D should be mentioned on the URI list, uri@w3.org (being non-IETF, this list can be a bit of a pain to use). Note that this is not the uri-review list, which is for new schemes, which this is not. Tom Petch > The new draft has ZoneID = 1*unreserved but that's easy to fix. > > Thanks > Brian > > From sofiane.imadali.ietf@gmail.com Fri Feb 10 10:52:49 2012 Return-Path: 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 D41E221F860D for ; Fri, 10 Feb 2012 10:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CqfhP4bQ1alw for ; Fri, 10 Feb 2012 10:52:46 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2C21F8611 for ; Fri, 10 Feb 2012 10:52:42 -0800 (PST) Received: by werm10 with SMTP id m10so2968389wer.31 for ; Fri, 10 Feb 2012 10:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=M2LUCbbZ75vZjFuDhRdQkZ/gCTpqTNKk6NO4tylyUZY=; b=szPxezzQ+5a5gMuTz0tpSSuHPOrpp3xsYgWdbR0fvvvzE+A61Q5GZw/nmCdbCwL2bm IkP2vK4JM+BbWEtl2IttkURz9JHIjcbISJH9LSiz34fK0Bb3xibJwl0sZ0WWOTMSkrqk uw5ijTlEnzoeuGjwUuVLZZuUaiq+ydHwATO5M= MIME-Version: 1.0 Received: by 10.180.107.34 with SMTP id gz2mr10948216wib.21.1328899960903; Fri, 10 Feb 2012 10:52:40 -0800 (PST) Received: by 10.180.103.97 with HTTP; Fri, 10 Feb 2012 10:52:40 -0800 (PST) Date: Fri, 10 Feb 2012 19:52:40 +0100 Message-ID: Subject: Announcing new version of draft-petrescu-autoconf-ra-based-routing From: sofiane Imadali To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:52:49 -0000 Hello all, I would like to announce a new version of the Internet Draft "Router Advertisements for Routing between Moving Networks" (draft-petrescu-autoconf-ra-based-routing-02) at: http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-02 ChangeLog from earlier version includes: 1- Unique IPv6 Local Addresses (ULA) as a possible exchanged MNP 2- Addition of a random delay preceding RA exchange to avoid RA storms There has been discussion about ULA and its use in vehicular networks on this email list in September 2011. Thank you for considering it. Your comments are very welcome. Yours sincerely, -- Sofiane Imadali From brian.e.carpenter@gmail.com Fri Feb 10 11:25:20 2012 Return-Path: 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 E9FEA21F87E6 for ; Fri, 10 Feb 2012 11:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 zaYxQ5Z6qLbh for ; Fri, 10 Feb 2012 11:25:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1CB321F87B4 for ; Fri, 10 Feb 2012 11:25:19 -0800 (PST) Received: by eaal12 with SMTP id l12so1031336eaa.31 for ; Fri, 10 Feb 2012 11:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sPYQsr1a4abZQvrX89s4ppW2lzcaRWkxEihz+yEpCX4=; b=RDr9VVFo89xWNzVhdzFwWBgYzRxRxoi/dHY61s7uILkZggugk3gcyJ4sWzgoXBqSk/ PW79aIjew/MDGDm8ic6ZzZ+UsJ/7eSG2BF9bRA7LMby+Jx0aiIf9hAiWi/gqT1yDj2zG toraesJSo2M98tNYbnvOWMUBW5ON5xIILMbB4= Received: by 10.14.98.135 with SMTP id v7mr2506791eef.27.1328901918982; Fri, 10 Feb 2012 11:25:18 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n17sm25468441eei.3.2012.02.10.11.25.16 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 11:25:18 -0800 (PST) Message-ID: <4F356F14.4060105@gmail.com> Date: Sat, 11 Feb 2012 08:25:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> <20120207104058.GA23771@elstar.local> <02a001cce580$02b9b000$4001a8c0@gateway.2wire.net> <20120207125849.GC24056@elstar.local> <4F318F36.3000505@gmail.com> <20120208071741.GA36298@elstar.local> <4F32CFED.8040805@gmail.com> <03cf01cce7e9$4806c060$4001a8c0@gateway.2wire.net> In-Reply-To: <03cf01cce7e9$4806c060$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 19:25:21 -0000 Tom, On 2012-02-11 00:43, t.petch wrote: ... > Since this is an update to RFC3986, I think that, once this list has > come to a consensus, then the I-D should be mentioned on the > URI list, uri@w3.org (being non-IETF, this list can be a bit of a pain > to use). Note that this is not the uri-review list, which is for new > schemes, which this is not. Of course, this draft needs to be checked and I expect we will consult with the Apps ADs and the W3C liaison to ensure that all bases are covered. Brian From dthaler@microsoft.com Fri Feb 10 18:41:45 2012 Return-Path: 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 ; 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 ; 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 ; 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 To: Dave Thaler , Chris Grundemann , Brian E Carpenter 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> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@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" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 lengt= h. 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 rule= s? 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=20 prefix as your own ULA (if any)? I'd argue that (a) is the right answer. The -revise draft's proposal=20 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 From dthaler@microsoft.com Mon Feb 13 10:13:03 2012 Return-Path: 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 CA49421F866C for ; Mon, 13 Feb 2012 10:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.941 X-Spam-Level: X-Spam-Status: No, score=-103.941 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 OekVF-M+uAqK for ; Mon, 13 Feb 2012 10:13:03 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id D39CD21F86BE for ; Mon, 13 Feb 2012 10:13:01 -0800 (PST) Received: from mail119-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Feb 2012 18:12:59 +0000 Received: from mail119-db3 (localhost [127.0.0.1]) by mail119-db3-R.bigfish.com (Postfix) with ESMTP id E3C09600BA; Mon, 13 Feb 2012 18:12:58 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail119-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3 (MessageSwitch) id 1329156776479271_3640; Mon, 13 Feb 2012 18:12:56 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.244]) by mail119-db3.bigfish.com (Postfix) with ESMTP id 66B57140049; Mon, 13 Feb 2012 18:12:56 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Feb 2012 18:12:55 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.247.5; Mon, 13 Feb 2012 10:12:41 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 10:12:41 -0800 From: Dave Thaler To: 'Chris Grundemann' , 'Brian E Carpenter' 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: AQHMmvx1vO8I87vUo0m73gUxdiNcXZXd39qAgAAf8wCAAAn2gIAAFZKAgAAYZICAABHNAIAABeSAgEMv5BCAFhKygIAELeLQ Date: Mon, 13 Feb 2012 18:12:40 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@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.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "'ipv6@ietf.org'" , 'Brian Haberman' , 'Bob Hinden' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:13:04 -0000 One typo below... > -----Original Message----- > From: Dave Thaler > Sent: Friday, February 10, 2012 6:42 PM > To: Dave Thaler; Chris Grundemann; Brian E Carpenter > Cc: Bob Hinden; Brian Haberman; ipv6@ietf.org > Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt >=20 > 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. >=20 > 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 fi= x. > 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 len= gth. > Instead of taking the proposed change, I propose to instead change the > definition of CommonPrefixLen() in section 2.2 as follows: >=20 > 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. >=20 > 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. >=20 > 2) Should ULAs be treated as site-local scope for purpose of the scope ru= les? >=20 > Consider the following two cases. >=20 > 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)? >=20 > I'd argue that (a) is the right answer. The -revise draft's proposal > would instead result in (b). >=20 > 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? >=20 > I'd argue that (b) is the right answer. The -revise draft's proposal wou= ld > instead result in (a). Above was backwards, should be: I'd argue that (a) is the right answer. The -revise draft's proposal would instead result in (b). =20 > 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. >=20 > 2) Was RFC 3484 in error when it said IPv4-translatable addresses > should be treated as always in the "preferred" state? >=20 > 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 witho= ut > 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. >=20 > 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. >=20 > NEW: > IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should > be treated as having "preferred" (in the RFC 4862 sense) > configuration status. >=20 >=20 > (An "IPv4-converted" address is not assigned to any interface, it's the > IPv6 representation of an IPv4 address assigned to someone's interface, j= ust > like IPv4-mapped addresses except that IPv4-converted addresses can appea= r > on the wire. See RFC 6145 for details.) >=20 > -Dave From dthaler@microsoft.com Mon Feb 13 14:01:43 2012 Return-Path: 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 D2BCC21E801E for ; Mon, 13 Feb 2012 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.929 X-Spam-Level: X-Spam-Status: No, score=-103.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qYq0ODcnbd29 for ; Mon, 13 Feb 2012 14:01:43 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA51821F866D for ; Mon, 13 Feb 2012 14:01:42 -0800 (PST) Received: from mail5-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Feb 2012 22:01:39 +0000 Received: from mail5-db3 (localhost [127.0.0.1]) by mail5-db3-R.bigfish.com (Postfix) with ESMTP id 3902A2401FD; Mon, 13 Feb 2012 22:01:39 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail5-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail5-db3 (localhost.localdomain [127.0.0.1]) by mail5-db3 (MessageSwitch) id 1329170496221078_13915; Mon, 13 Feb 2012 22:01:36 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.226]) by mail5-db3.bigfish.com (Postfix) with ESMTP id 31981120049; Mon, 13 Feb 2012 22:01:36 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Feb 2012 22:01:30 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.247.5; Mon, 13 Feb 2012 14:01:27 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 14:01:26 -0800 From: Dave Thaler To: Dave Thaler , 'Chris Grundemann' , 'Brian E Carpenter' 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: AQHMmvx1vO8I87vUo0m73gUxdiNcXZXd39qAgAAf8wCAAAn2gIAAFZKAgAAYZICAABHNAIAABeSAgEMv5BCAFhKygIAELeLQgAA7epA= Date: Mon, 13 Feb 2012 22:01:26 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3F2D73@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@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: 'Bob Hinden' , 'Brian Haberman' , "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:01:43 -0000 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:=20 D set =3D { global IPv6, global IPv4 } S set =3D { 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 =3D { 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 =3D { global IPv4 =3D 1.2.3.4 } S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 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=20 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 From dthaler@microsoft.com Mon Feb 13 15:55:41 2012 Return-Path: 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 21AAE21F8639 for ; Mon, 13 Feb 2012 15:55:41 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...W601.wingroup.windeploy.ntdev.microsoft.com>\n X-Spam-Flag: NO X-Spam-Score: -103.923 X-Spam-Level: X-Spam-Status: No, score=-103.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 O6YQDWqNJVvV for ; Mon, 13 Feb 2012 15:55:40 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id B12FD21F862D for ; Mon, 13 Feb 2012 15:55:36 -0800 (PST) Received: from mail160-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Feb 2012 23:55:34 +0000 Received: from mail160-ch1 (localhost [127.0.0.1]) by mail160-ch1-R.bigfish.com (Postfix) with ESMTP id 6FEE324014D; Mon, 13 Feb 2012 23:55:33 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail160-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail160-ch1 (localhost.localdomain [127.0.0.1]) by mail160-ch1 (MessageSwitch) id 1329177330183772_3580; Mon, 13 Feb 2012 23:55:30 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail160-ch1.bigfish.com (Postfix) with ESMTP id 2AB354C0049; Mon, 13 Feb 2012 23:55:30 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Feb 2012 23:55:29 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.247.5; Mon, 13 Feb 2012 15:55:30 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 15:55:30 -0800 From: Dave Thaler To: 'Chris Grundemann' , 'Brian E Carpenter' 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: AQHMmvx1vO8I87vUo0m73gUxdiNcXZXd39qAgAAf8wCAAAn2gIAAFZKAgAAYZICAABHNAIAABeSAgEMv5BCAFhKygIAELeLQgAA7epCAACP9wA== Date: Mon, 13 Feb 2012 23:55:30 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3F3557@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@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: 'Bob Hinden' , 'Brian Haberman' , "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:55:41 -0000 > -----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 >=20 > Yet another problem in draft-ietf-6man-rfc3484-revise... >=20 > 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. > [...] >=20 > The above sentence is simply not true, it was NOT based on such an assump= tion > 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 em= bed IP > addresses in payloads. > [...] >=20 > > 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. >=20 > 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 lo= ok at 3 > cases. >=20 > Case 1: > D set =3D { global IPv6, global IPv4 } > S set =3D { Teredo IPv6, RFC1918 IPv4 } >=20 > Under RFC 3484 rules, Destination Address Selection would prefer the Tere= do > connectivity under rule 2 (Prefer matching scope). >=20 > Under -revise rules, Destination Address Selection would still prefer the= Teredo > connectivity under rule 6 (Prefer higher precedence), since the precedenc= e 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 p= roblem rather than just move it around. I'll think about this and see if I can come back with a proposal. -Dave >=20 > Case 2: > D set =3D { Teredo IPv6, global IPv4 } >=20 > Not an interesting case because Teredo addressing should be disabled when= a > host has a global IPv4 address. >=20 > Case 3: > D set =3D { global IPv4 =3D 1.2.3.4 } > S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 128.66.3.4 } >=20 > Under RFC 3484 rules, Source Address Selection would prefer the global IP= v4 > address under Rule 2(Prefer appropriate scope). > Under -revise rules, Source Address Selection would instead prefer the NA= T'ed > IPv4 under Rule 8 (Longest matching prefix). >=20 > This is broken. I don't see a real case the proposed change > fixes, I only see real cases it breaks. >=20 > -Dave From tyson.macaulay@bell.ca Mon Feb 13 19:21:43 2012 Return-Path: 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 4801821F8773 for ; Mon, 13 Feb 2012 19:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 6dw5sLy5bw4d for ; Mon, 13 Feb 2012 19:21:41 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0F21F8772 for ; Mon, 13 Feb 2012 19:21:40 -0800 (PST) Received: from [85.158.136.3:19433] by server-1.bemta-5.messagelabs.com id B0/2A-28458-343D93F4; Tue, 14 Feb 2012 03:21:39 +0000 X-Env-Sender: tyson.macaulay@bell.ca X-Msg-Ref: server-6.tower-123.messagelabs.com!1329189698!18000594!1 X-Originating-IP: [206.47.0.177] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32548 invoked from network); 14 Feb 2012 03:21:39 -0000 Received: from bellnexxia.net (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-6.tower-123.messagelabs.com with RC4-SHA encrypted SMTP; 14 Feb 2012 03:21:39 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012 22:21:34 -0500 Received: from MBX08.bell.corp.bce.ca ([142.182.199.89]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Mon, 13 Feb 2012 22:21:38 -0500 From: "tyson.macaulay@bell.ca" To: "ipv6@ietf.org" Date: Mon, 13 Feb 2012 22:21:36 -0500 Subject: New Version Notification for draft-macaulay-6man-packet-stain-00.txt Thread-Topic: New Version Notification for draft-macaulay-6man-packet-stain-00.txt Thread-Index: AczqxnTfT/JxE+VNQnCZULgMKcJtfwAAEW8Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 03:21:43 -0000 UGxlYXNlIG5vdGUgdGhpcyBuZXcgZHJhZnQgcmVsYXRlZCB0byBlbWJlZGRpbmcgY3liZXIgc2Vj dXJpdHkgYW5kIHJlcHV0YXRpb24gaW50ZWxsaWdlbmNlIGludG8gSVB2NiBoZWFkZXJzIGFzIGRl c3RpbmF0aW9uIG9wdGlvbnMuDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hY2F1 bGF5LTZtYW4tcGFja2V0LXN0YWluLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFR5c29uIE1hY2F1bGF5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KRmlsZW5hbWU6CSBkcmFmdC1tYWNhdWxheS02bWFuLXBhY2tldC1zdGFpbg0KUmV2aXNpb246 CSAwMA0KVGl0bGU6CQkgSVB2NiBwYWNrZXQgc3RhaW5pbmcNCkNyZWF0aW9uIGRhdGU6CSAyMDEy LTAyLTE0DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MTANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgYXBwbGljYXRp b24gb2Ygc2VjdXJpdHkgc3RhaW5pbmcgb24gYW4NCiAgIElQdjYgZGF0YWdyYW1zIGFuZCB0aGUg bWluaW11bSByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMgc3RhaW5pbmcNCiAgIGZsb3dzLCBJ UHY2IG5vZGVzIGZvcndhcmRpbmcgc3RhaW5lZCBwYWNrZXRzIGFuZCBpbnRlcnByZXRpbmcgc3Rh aW5zDQogICBvbiBmbG93cy4NCg0KICAgVGhlIHVzYWdlIG9mIHRoZSBwYWNrZXQgc3RhaW5pbmcg ZGVzdGluYXRpb24gb3B0aW9uIGVuYWJsZXMgcHJvYWN0aXZlDQogICBkZWxpdmVyeSBvZiBzZWN1 cml0eSBpbnRlbGxpZ2VuY2UgdG8gSVB2NiBub2RlcyBzdWNoIGFzIGZpcmV3YWxscyBhbmQNCiAg IGludHJ1c2lvbiBwcmV2ZW50aW9uIHN5c3RlbXMsIGFuZCBlbmQtcG9pbnRzIHN1Y2ggc2VydmVy cywNCiAgIHdvcmtzdGF0aW9ucywgbW9iaWxlIGFuZCBzbWFydCBkZXZpY2VzIGFuZCBhbiBpbmZp bml0ZSBhcnJheSBvZiBhcy0NCiAgIHlldC10by1iZS1pbnZlbnRlZCBzZW5zb3JzIGFuZCBjb250 cm9sbGVycy4NCg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW1hY2F1bGF5LTZtYW4t cGFja2V0LXN0YWluLTAwLnR4dA0K From jeanjour@comcast.net Mon Feb 13 19:38:33 2012 Return-Path: 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 7377221F853B for ; Mon, 13 Feb 2012 19:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, 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 pxme-vkyBBCb for ; Mon, 13 Feb 2012 19:38:32 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA121F8546 for ; Mon, 13 Feb 2012 19:38:32 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id Zf4T1i0080bG4ec59feYs6; Tue, 14 Feb 2012 03:38:32 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta03.westchester.pa.mail.comcast.net with comcast id ZfeX1i01D4dorGg3PfeY6J; Tue, 14 Feb 2012 03:38:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 13 Feb 2012 22:35:06 -0500 To: "tyson.macaulay@bell.ca" , "ipv6@ietf.org" From: John Day Subject: Re: New Version Notification for draft-macaulay-6man-packet-stain-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailman-Approved-At: Mon, 13 Feb 2012 23:33:57 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 03:38:33 -0000 Odd you should mention the speeding ticket. Cop pulled Rich over just after they entered OK on the way down. Sauntered up to the car and said, "Do you know how fast you were going?" Rich said, yes. Officer says, 86. Rich says, The heck I was. The cruise control was set on 75" (in a 75 mph zone). To make a long story short, the guy backed down. And Rich went on his way. Kev had stopped to wait for Rich. The cop decided he would hassle Kev to save face about stopping in the breakdown. Kev said they were changing drivers and he went on. But the trip was a typical Kevin trip. We had fire trucks at the Hotel Sunday morning. (someone trapped in the elevator.) Never happens when I am in a hotel, but if Kevin is around. . . . ;-) At 22:21 -0500 2012/02/13, tyson.macaulay@bell.ca wrote: >Please note this new draft related to embedding cyber security and >reputation intelligence into IPv6 headers as destination options. > > >A new version of I-D, draft-macaulay-6man-packet-stain-00.txt has >been successfully submitted by Tyson Macaulay and posted to the IETF >repository. > >Filename: draft-macaulay-6man-packet-stain >Revision: 00 >Title: IPv6 packet staining >Creation date: 2012-02-14 >WG ID: Individual Submission >Number of pages: 10 > >Abstract: > This document specifies the application of security staining on an > IPv6 datagrams and the minimum requirements for IPv6 nodes staining > flows, IPv6 nodes forwarding stained packets and interpreting stains > on flows. > > The usage of the packet staining destination option enables proactive > delivery of security intelligence to IPv6 nodes such as firewalls and > intrusion prevention systems, and end-points such servers, > workstations, mobile and smart devices and an infinite array of as- > yet-to-be-invented sensors and controllers. > > >http://www.ietf.org/id/draft-macaulay-6man-packet-stain-00.txt >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From arifumi@nttv6.net Tue Feb 14 08:51:11 2012 Return-Path: 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 B66F921E8077 for ; Tue, 14 Feb 2012 08:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 OJxTWl+7Pv30 for ; Tue, 14 Feb 2012 08:51:10 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8405B21E8075 for ; Tue, 14 Feb 2012 08:51:10 -0800 (PST) Received: from [127.0.0.1] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1EGq8nH035884; Wed, 15 Feb 2012 01:52:08 +0900 (JST) (envelope-from arifumi@nttv6.net) References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Arifumi Matsumoto Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt Date: Wed, 15 Feb 2012 01:49:49 +0900 To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:51:11 -0000 Dave, one quick question below. On 2012/02/11, at 11:41, Dave Thaler wrote: > 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. >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 2) Should ULAs be treated as site-local scope for purpose of the scope = rules? >=20 > Consider the following two cases. >=20 > 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=20= > prefix as your own ULA (if any)? >=20 > I'd argue that (a) is the right answer. The -revise draft's proposal=20= > would instead result in (b). >=20 > 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? >=20 > I'd argue that (b) is the right answer. The -revise draft's proposal > would instead result in (a). >=20 > 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. So, you are suggesting to map ULAs(fc00::/7) to site-local scope also = for unicast ? Then, I don't see how the former case can be solved by this fix. The ULAs should be chosen for both src and dst addresses, if they have = smaller scope than global addresses, right ? Or, are you suggesting to map only ULAs that is in the same prefix to = site-local scope ? Best regards, >=20 > 2) Was RFC 3484 in error when it said IPv4-translatable addresses > should be treated as always in the "preferred" state? >=20 > 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. >=20 > 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. >=20 > NEW: > IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should > be treated as having "preferred" (in the RFC 4862 sense) > configuration status. >=20 >=20 > (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.) >=20 > -Dave >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From arifumi@nttv6.net Tue Feb 14 09:03:29 2012 Return-Path: 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 4077621F8729 for ; Tue, 14 Feb 2012 09:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, 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 PLrp1Pw2HDmS for ; Tue, 14 Feb 2012 09:03:28 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4521F84B3 for ; Tue, 14 Feb 2012 09:03:25 -0800 (PST) Received: from [127.0.0.1] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1EH4LuT035970; Wed, 15 Feb 2012 02:04:21 +0900 (JST) (envelope-from arifumi@nttv6.net) References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@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> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3F3557@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <1D57B1DC-79A4-4935-961E-830277F29715@nttv6.net> Content-Transfer-Encoding: quoted-printable From: Arifumi Matsumoto Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt Date: Wed, 15 Feb 2012 02:02:01 +0900 To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: 'Bob Hinden' , 'Brian Haberman' , "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:03:29 -0000 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 >>=20 >> Yet another problem in draft-ietf-6man-rfc3484-revise... >>=20 >> 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. >> [...] >>=20 >> 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. >> [...] >>=20 >>> 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. >>>=20 >>> This issue can be fixed by changing the address scope of private = IPv4 >>> addresses to global. >>=20 >> 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. >>=20 >> Case 1: >> D set =3D { global IPv6, global IPv4 } >> S set =3D { Teredo IPv6, RFC1918 IPv4 } >>=20 >> Under RFC 3484 rules, Destination Address Selection would prefer the = Teredo >> connectivity under rule 2 (Prefer matching scope). >>=20 >> 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. >=20 > 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. >=20 > I'll think about this and see if I can come back with a proposal. >> Case 3: >> D set =3D { global IPv4 =3D 1.2.3.4 } >> S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 128.66.3.4 } >>=20 >> 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). >>=20 >> 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 ? Best regards,=20 >=20 > -Dave >=20 >>=20 >> Case 2: >> D set =3D { Teredo IPv6, global IPv4 } >>=20 >> Not an interesting case because Teredo addressing should be disabled = when a >> host has a global IPv4 address. >>=20 >> Case 3: >> D set =3D { global IPv4 =3D 1.2.3.4 } >> S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 128.66.3.4 } >>=20 >> 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). >>=20 >> This is broken. I don't see a real case the proposed change >> fixes, I only see real cases it breaks. >>=20 >> -Dave >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Feb 14 12:10:47 2012 Return-Path: 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 ADA6721F8516 for ; Tue, 14 Feb 2012 12:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 LfbUw2wiQvqu for ; Tue, 14 Feb 2012 12:10:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F47321F850F for ; Tue, 14 Feb 2012 12:10:46 -0800 (PST) Received: by iagf6 with SMTP id f6so411202iag.31 for ; Tue, 14 Feb 2012 12:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xy4mGHqLwd8LzigiasCRSb2Jq7QMebIpQZ5sAY6wxzk=; b=WbntrTFZ0DktlL4mY5O2PaawxD1brNA7ZBAcBx6MK/+L6DDuFbPzsbcrjEIjtHNjQ9 DFUWMptTsl9LBW41nt7etTNTU0RtMK0hFQeOGx9nJ2bpRkwiup7siJLScLepRB+Cba4C MzZCQ9VAUfMu18gfz6yOAvEoLqPuwVqOf/rvM= Received: by 10.50.34.164 with SMTP id a4mr37658428igj.14.1329250246237; Tue, 14 Feb 2012 12:10:46 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ak10sm643729igc.6.2012.02.14.12.10.42 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 12:10:45 -0800 (PST) Message-ID: <4F3ABFBA.8060605@gmail.com> Date: Wed, 15 Feb 2012 09:10:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , "ipv6@ietf.org" , Brian Haberman , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:10:47 -0000 On 2012-02-15 05:49, Arifumi Matsumoto wrote: > Dave, > > one quick question below. > > On 2012/02/11, at 11:41, Dave Thaler wrote: ... >> 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. > > So, you are suggesting to map ULAs(fc00::/7) to site-local scope also for unicast ? > Then, I don't see how the former case can be solved by this fix. > The ULAs should be chosen for both src and dst addresses, if they have smaller > scope than global addresses, right ? IMHO we have to be very careful about messing with the formal scope of ULAs. They are unambiguously defined *architecturally* as having global scope, and address selection rules have to respect that (unless we make a major architectural effort, since IMNSHO our whole concept of unicast scope is broken). In other words - in the unicast domain, ULAs have to stay global, and longest- match or explicit rules are the only solution. Multicast is a different matter, since site-local scope is well defined there. > > Or, are you suggesting to map only ULAs that is in the same prefix to site-local scope ? Not needed; longest match takes care of that. The tricky case is where you have several ULA prefixes in use on the same site. Brian From tjc@ecs.soton.ac.uk Tue Feb 14 14:28:41 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 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: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@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> To: 6man Mailing List 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, >=20 > another point below. >=20 > On 2012/02/14, at 8:55, Dave Thaler wrote: >=20 >>> -----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 >>>=20 >>> Yet another problem in draft-ietf-6man-rfc3484-revise... >>>=20 >>> 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. >>> [...] >>>=20 >>> 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. >>> [...] >>>=20 >>>> 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. >>>>=20 >>>> This issue can be fixed by changing the address scope of private = IPv4 >>>> addresses to global. >>>=20 >>> 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. >>>=20 >>> Case 1: >>> D set =3D { global IPv6, global IPv4 } >>> S set =3D { Teredo IPv6, RFC1918 IPv4 } >>>=20 >>> Under RFC 3484 rules, Destination Address Selection would prefer the = Teredo >>> connectivity under rule 2 (Prefer matching scope). >>>=20 >>> 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. >>=20 >> 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. >>=20 >> I'll think about this and see if I can come back with a proposal. >=20 >>> Case 3: >>> D set =3D { global IPv4 =3D 1.2.3.4 } >>> S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 128.66.3.4 } >>>=20 >>> 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). >>>=20 >>> This is broken. I don't see a real case the proposed change >>> fixes, I only see real cases it breaks. >=20 >=20 > 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. >=20 > 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:=20 "Application of this specification to source address selection in an = IPv4 network=20 layer may be possible but this is not explored further here." Tim >=20 > Best regards,=20 >=20 >>=20 >> -Dave >>=20 >>>=20 >>> Case 2: >>> D set =3D { Teredo IPv6, global IPv4 } >>>=20 >>> Not an interesting case because Teredo addressing should be disabled = when a >>> host has a global IPv4 address. >>>=20 >>> Case 3: >>> D set =3D { global IPv4 =3D 1.2.3.4 } >>> S set =3D { NAT-ed IPv4 =3D 10.2.3.4, global IPv4 =3D 128.66.3.4 } >>>=20 >>> 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). >>>=20 >>> This is broken. I don't see a real case the proposed change >>> fixes, I only see real cases it breaks. >>>=20 >>> -Dave >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Tue Feb 14 14:30:14 2012 Return-Path: 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 EEE8B21E80E1 for ; Tue, 14 Feb 2012 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Jt4ECj3b1MLJ for ; Tue, 14 Feb 2012 14:30:14 -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 0C78C21E80C4 for ; Tue, 14 Feb 2012 14:30:13 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q1EMUCrV024678 for ; Tue, 14 Feb 2012 22:30:12 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q1EMUCrV024678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1329258613; bh=Y/GjB4jjpZzLvRCP2Xh+hswyBhU=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=TIRuHLAmiMXQFI4N5PO2NlfmmMinbZRUv46IVZjIsiNfmRf1QO4GsjqHT14Vcq0L6 bL2UDuQiOV0wRtmk4hHV82fBFORNIBS1GcY88cqux0+Uqv+X4p1WBh+0Q36N/G96bM sGw9F41cFdcGmw1U2My9BXbKAqkDb8XfN89WOJk4= 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 with ESMTP id o1DMUC0543729296qY ret-id none; Tue, 14 Feb 2012 22:30:12 +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 q1EMU7ki003791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Feb 2012 22:30:08 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 In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3F2D73@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 14 Feb 2012 22:30:06 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F1DD6@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3F2D73@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <71B8F286-05BA-4AB1-B767-6C09F22E3E7C@ecs.soton.ac.uk> To: 6man Mailing List X-Mailer: Apple Mail (2.1251.1) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o1DMUC054372929600; tid=o1DMUC0543729296qY; 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: q1EMUCrV024678 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:30:15 -0000 On 13 Feb 2012, at 22:01, Dave Thaler wrote: > 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. > [...] I certainly agree that that wording can be improved. Tim > >> 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 > -------------------------------------------------------------------- From bob.hinden@gmail.com Tue Feb 14 16:38:01 2012 Return-Path: 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 01C8621F8679 for ; Tue, 14 Feb 2012 16:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 sWn9nhu1vPyR for ; Tue, 14 Feb 2012 16:38:00 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1B21F8678 for ; Tue, 14 Feb 2012 16:38:00 -0800 (PST) Received: by obbwd15 with SMTP id wd15so748803obb.31 for ; Tue, 14 Feb 2012 16:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=b9teoKhNeCgFP25dyxpyOoaHaEYCDsE/Ck9s+9xk9LQ=; b=bwptDKVO6xF1E1+RTJ5HmJJyIPtDKeKehN8es4YP6Xa5nfN3pdFcsqWbON9GBiOePd 2+rZ6/ebYPK9zSRKcUKxsX37mx0zSvg7t4GdtrpddwtRXAXYiVKJW5qdRpVEP95WJMy6 TAHry26vpDvqnDCObhikmwYJ3M3/exFh9YBFg= Received: by 10.50.155.170 with SMTP id vx10mr8175935igb.22.1329266279818; Tue, 14 Feb 2012 16:37:59 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id ko6sm22082564igc.2.2012.02.14.16.37.58 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 16:37:59 -0800 (PST) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Changes in 6man working group Date: Tue, 14 Feb 2012 16:37:57 -0800 Message-Id: <9930B805-BB57-42C1-B4AE-23A8E8ABD3CF@gmail.com> To: IETF IPv6 Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:38:01 -0000 I want to publicly congratulate Brian Haberman for being selected as the = new Internet Area Director and thank him for his long service as 6man = co-chair. I am sure he will make an excellent AD and have enjoyed = working with him in 6man. Of course, I also want to thank Jari Arkko = for his long and excellant service as our Internet AD. =20 Ole Tr=F8an will be the new 6man co-chair. Ole has considerable = experience with IPv6 and the IETF, and will make an excellent 6man = co-chair. I am looking forward to working with him. The transition plan is to bring Ole in as a third chair now and have = Brian step down during the 6man session at the Paris IETF. This should = make for an orderly transition and make it easy for Ole to come up to = speed. Please thank Brian and Jari for their service, and welcome Ole as a new = 6man chair. Bob From internet-drafts@ietf.org Wed Feb 15 03:40:13 2012 Return-Path: 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 CEE0921F8656; Wed, 15 Feb 2012 03:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 wJsxPAuV6IFY; Wed, 15 Feb 2012 03:40:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502EC21F8668; Wed, 15 Feb 2012 03:40:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120215114010.14255.26519.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 03:40:10 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 11:40:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Jun-ya Kato Tim Chown Filename : draft-ietf-6man-addr-select-opt-02.txt Pages : 10 Date : 2012-02-15 RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection policy table, and thus control the address selection behavior of nodes in their site. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt From jari.arkko@piuha.net Wed Feb 15 05:58:57 2012 Return-Path: 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 09FF321F86E0 for ; Wed, 15 Feb 2012 05:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 pLtUWHv3IGff for ; Wed, 15 Feb 2012 05:58:56 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 870F921F84DA for ; Wed, 15 Feb 2012 05:58:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7047C2D35A; Wed, 15 Feb 2012 15:58:55 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT4dHfCWQd_Y; Wed, 15 Feb 2012 15:58:55 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EC6612CC3C; Wed, 15 Feb 2012 15:58:54 +0200 (EET) Message-ID: <4F3BBA1E.8070803@piuha.net> Date: Wed, 15 Feb 2012 15:58:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Brian Haberman , =?ISO-8859-1?Q?Ole_Tr=F8?= =?ISO-8859-1?Q?an?= Subject: Re: Changes in 6man working group References: <9930B805-BB57-42C1-B4AE-23A8E8ABD3CF@gmail.com> In-Reply-To: <9930B805-BB57-42C1-B4AE-23A8E8ABD3CF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IPv6 Mailing List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:58:57 -0000 Thank you for taking on this task, Ole! And thanks & congratulations to you Brian! And good luck :-) I'm very happy to have the two of you in these new tasks. Jari On 15.02.2012 02:37, Bob Hinden wrote: > I want to publicly congratulate Brian Haberman for being selected as the new Internet Area Director and thank him for his long service as 6man co-chair. I am sure he will make an excellent AD and have enjoyed working with him in 6man. Of course, I also want to thank Jari Arkko for his long and excellant service as our Internet AD. > > Ole Trøan will be the new 6man co-chair. Ole has considerable experience with IPv6 and the IETF, and will make an excellent 6man co-chair. I am looking forward to working with him. > > The transition plan is to bring Ole in as a third chair now and have Brian step down during the 6man session at the Paris IETF. This should make for an orderly transition and make it easy for Ole to come up to speed. > > Please thank Brian and Jari for their service, and welcome Ole as a new 6man chair. > > Bob > > From brian.e.carpenter@gmail.com Wed Feb 15 11:32:28 2012 Return-Path: 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 BD96421F848B for ; Wed, 15 Feb 2012 11:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 1ZOUkEw4W5PT for ; Wed, 15 Feb 2012 11:32:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF8621F8483 for ; Wed, 15 Feb 2012 11:32:27 -0800 (PST) Received: by eekc41 with SMTP id c41so507472eek.31 for ; Wed, 15 Feb 2012 11:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pL22O+lXZrI/u5Y0QEm3MP1iBwzryNPQUfwMUCfK5So=; b=sHs+iZuA8DIZseWK6JeQ6LScguY3+DEXer/2S0jcc0O/nQ8YFv1Cp+CQGSO0tDqS7f EyHIsDeYRph/KB25Ez8TdnWerT2lsIu4Z3b/weEI3PznuP1JDYqHpfYsztH3UffWBw5B Babm6NJ1bALZ7/xfVPb1jZkAhkB/iK+wy+uHA= Received: by 10.213.28.74 with SMTP id l10mr1469969ebc.125.1329334347205; Wed, 15 Feb 2012 11:32:27 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n52sm14270424eea.5.2012.02.15.11.32.23 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 11:32:26 -0800 (PST) Message-ID: <4F3C083F.50207@gmail.com> Date: Thu, 16 Feb 2012 08:32:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko , Brian Haberman , =?UTF-8?B?T2xlIFRyw7hhbg==?= Subject: Re: Changes in 6man working group References: <9930B805-BB57-42C1-B4AE-23A8E8ABD3CF@gmail.com> <4F3BBA1E.8070803@piuha.net> In-Reply-To: <4F3BBA1E.8070803@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:32:28 -0000 Jari, Brian H and Bob have been a great team to work with, and I'm sure that Brian H, Ole and Bob will be just as great. Thanks! Brian C From brian@innovationslab.net Thu Feb 16 11:45:32 2012 Return-Path: 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 E915121E806D for ; Thu, 16 Feb 2012 11:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, 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 ExOss+d56kuT for ; Thu, 16 Feb 2012 11:45:27 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7802521E8052 for ; Thu, 16 Feb 2012 11:45:27 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 666A1880BB; Thu, 16 Feb 2012 11:45:27 -0800 (PST) Received: from clemson.local (unknown [128.220.159.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B049130009; Thu, 16 Feb 2012 11:45:27 -0800 (PST) Message-ID: <4F3D5CD9.5030305@innovationslab.net> Date: Thu, 16 Feb 2012 14:45:29 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt References: <4F32D259.5030400@innovationslab.net> In-Reply-To: <4F32D259.5030400@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:45:33 -0000 All, I saw strong support for adopting the draft as a WG document. The authors should post the next version of the document as 6man working group document. Regards, Brian On 2/8/12 2:51 PM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Title : Representing IPv6 Zone Identifiers in > Uniform Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-carpenter-6man-uri-zoneid-01.txt > Pages : 6 > Date : 2012-02-08 > > as a 6MAN WG document. This last call will end on February 17, 2012. > > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From s.martin1@lancaster.ac.uk Thu Feb 16 13:23:07 2012 Return-Path: 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 0FDFF21F8731 for ; Thu, 16 Feb 2012 13:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 hl0cpasp9zty for ; Thu, 16 Feb 2012 13:23:04 -0800 (PST) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5427521F8723 for ; Thu, 16 Feb 2012 13:23:04 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Ry8n9-00016N-Ay for ipv6@ietf.org; Thu, 16 Feb 2012 21:23:03 +0000 Received: from EX-1-MB0.lancs.local ([fe80::f083:6530:dfd5:ebc7]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%13]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 21:23:03 +0000 From: "Martin, Steve" To: "ipv6@ietf.org" Subject: draft-macaulay-6man-packet-stain-00 High Level Questions Thread-Topic: draft-macaulay-6man-packet-stain-00 High Level Questions Thread-Index: Aczs8AhinRQbX7jrRoaOqLMHJv2jbw== Date: Thu, 16 Feb 2012 21:23:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.33.133.4] Content-Type: multipart/alternative; boundary="_000_C03F3430284E23419D3BD41E5827FE11891559EX1MB0lancslocal_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Feb 2012 14:58:05 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:47:55 -0000 --_000_C03F3430284E23419D3BD41E5827FE11891559EX1MB0lancslocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tyson, I've just read your ITEF paper on Packet Staining, a very interesting idea = and relevant to an area of research that I'm looking at. Something that I've been considering is how might IPv6 impact individuals, = i.e. home users who typically have limited internet security. Under IPv4 N= AT has provided an "accidental" firewall that has been very beneficial to s= uch subscribers. As the migration to IPv6 takes hold, it strikes me that sp= ecific firewalls will become mandatory (and critical that they are kept up = to date), but those subscribers won't perceive any benefit from such device= s (at least not until it is too late) and will simply connect devices direc= tly to the internet with insufficient protection. So, and this is where you paper is relevant, I have been pondering how IPv6= can be deployed to these subscribers with the added benefit of the "built-= in" security that they have been used to with the likes of NAT. Am I right in understanding that you packet staining could provide service = provision that might include any number of the following: * Spam Assessment * Parental Controls * Malware Detection * Forged Certificates * etc Some of the above would require deep packet inspection, at least as far as = protocol, and in some cases of the actual data. Is this within scope of wh= at you envisage ? It strikes me that your Packet Staining concept could enable the provision = of services that meet the needs of these subscribers in a manner that will = enable them to "configure and forget", much like they already experience wi= th Anti-Virus products which regularly download updates), except that they = would get the benefit of a more intelligent process that has a re timely up= dates and the potential for filtering at the perimeter or the endpoint. Finally, it is not clear to me whether there is any impact if IPsec is invo= lved, which would prevent such a level of packet inspection. Many thanks for you contribution and thoughts. Regards Steve Martin --_000_C03F3430284E23419D3BD41E5827FE11891559EX1MB0lancslocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tyson,
I've just read your ITEF paper on Packet Staining, a very interesting = idea and relevant to an area of research that I'm looking at.

Something that I've been considering is how might IPv6 impact individu= als, i.e. home users who typically have limited internet security.  Un= der IPv4 NAT has provided an "accidental" firewall that has been = very beneficial to such subscribers. As the migration to IPv6 takes hold, it strikes me that specific firewalls will become mand= atory (and critical that they are kept up to date), but those subscribers w= on't perceive any benefit from such devices (at least not until it is too l= ate) and will simply connect devices directly to the internet with insufficient protection.

So, and this is where you paper is relevant, I have been pondering how= IPv6 can be deployed to these subscribers with the added benefit of the &q= uot;built-in" security that they have been used to with the likes of N= AT.

Am I right in understanding that you packet staining could provide ser= vice provision that might include any number of the following:
  • Spam Assessment
  • Parental Controls
  • Malware Detection
  • Forged Certificates
  • etc
Some of the above would require deep packet inspection, at least as fa= r as protocol, and in some cases of the actual data.  Is this within s= cope of what you envisage ?

It strikes me that your Packet Staining concept could enable the provi= sion of services that meet the needs of these subscribers in a manner that = will enable them to "configure and forget", much like they alread= y experience with Anti-Virus products which regularly download updates), except that they would get the benefit of a m= ore intelligent process that has a re timely updates and the potential for = filtering at the perimeter or the endpoint.

Finally, it is not clear to me whether there is any impact if IPsec is= involved, which would prevent such a level of packet inspection.

Many thanks for you contribution and thoughts.

Regards
Steve Martin
--_000_C03F3430284E23419D3BD41E5827FE11891559EX1MB0lancslocal_-- From brian.e.carpenter@gmail.com Thu Feb 16 16:50:12 2012 Return-Path: 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 D930321F8755 for ; Thu, 16 Feb 2012 16:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 XZZpGN2CkiB0 for ; Thu, 16 Feb 2012 16:50:12 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2745C21F8742 for ; Thu, 16 Feb 2012 16:50:11 -0800 (PST) Received: by eekc41 with SMTP id c41so1174726eek.31 for ; Thu, 16 Feb 2012 16:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g8dXCSmDSE6CGQtgflMCCvO91YgiR85xSS9cBvykM+Y=; b=vHFgCzg+jKOjTO68Lt3WWEWu7av7BgInHA4qVIzVI6Kuxf0zJCcqoejPQcIBa3u3mC y1yky7zOoDsD91TH3V+0fUbUXuPcw4qN88KzWxMykS4RIbYiz+5KDgDJ8nc2uRTNLRCU ILk/KEOAKQgcwcLjVROkXxrP+QI8EcC6Fyq+s= Received: by 10.213.14.205 with SMTP id h13mr607072eba.5.1329439811285; Thu, 16 Feb 2012 16:50:11 -0800 (PST) Received: from [10.1.1.3] ([121.98.251.219]) by mx.google.com with ESMTPS id o49sm32150561eeb.7.2012.02.16.16.50.08 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 16:50:10 -0800 (PST) Message-ID: <4F3DA43A.2030303@gmail.com> Date: Fri, 17 Feb 2012 13:50:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Martin, Steve" Subject: Re: draft-macaulay-6man-packet-stain-00 High Level Questions References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:50:13 -0000 On 2012-02-17 10:23, Martin, Steve wrote: ... > So, and this is where you paper is relevant, I have been pondering how IPv6 can be deployed to these subscribers with the added benefit of the "built-in" security that they have been used to with the likes of NAT. This was the subject matter of RFC 4864. Also see RFC 6092. I will refrain from the standard rant about the assertion that NAT is a security mechanism, since that is covered in RFC 4864. Brian From dwing@cisco.com Thu Feb 16 17:53:00 2012 Return-Path: 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 33E4E21E8080 for ; Thu, 16 Feb 2012 17:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 K7xXwL8zRQ83 for ; Thu, 16 Feb 2012 17:52:56 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7B21E807E for ; Thu, 16 Feb 2012 17:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2950; q=dns/txt; s=iport; t=1329443576; x=1330653176; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=br1Lt0S494RIFeOEGPCHvAH8vx0MAJvcfHo/rtyBlDo=; b=jyBEe1LYNeWjj1jx+ThI/dUS4+It6woOe+uTqgWPo9RT0ra5s/xIIH3O kluhLl8x0H6HpZVpmUC1fXlKMpUuguHEgEHZVhF+lp6Idbl9AtAts5wGG uoB9B8Cw/q/pswYGQu5re91plLIvwWFn7pLqir5GT1NybNnVnbNKicWcL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGCyPU+tJXHB/2dsb2JhbABEDqExjy2BB4FyAQEBAwEICgEXEEQHAQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHXZpaAZ5Si24EAgIMEg4BAS4ECQkCAYdYBIhOhQeaE1g X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208";a="59641166" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 17 Feb 2012 01:52:55 +0000 Received: from dwingWS (rtp-vpn3-1212.cisco.com [10.82.220.193]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1H1qsFT030233; Fri, 17 Feb 2012 01:52:54 GMT From: "Dan Wing" To: "'Martin, Steve'" , References: In-Reply-To: Subject: RE: draft-macaulay-6man-packet-stain-00 High Level Questions Date: Thu, 16 Feb 2012 17:52:54 -0800 Message-ID: <049801cced16$ddc8f5a0$995ae0e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczs8AhinRQbX7jrRoaOqLMHJv2jbwAJcagQ Content-Language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 01:53:00 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Martin, Steve > Sent: Thursday, February 16, 2012 1:23 PM > To: ipv6@ietf.org > Subject: draft-macaulay-6man-packet-stain-00 High Level Questions > > Hi Tyson, > I've just read your ITEF paper on Packet Staining, a very interesting > idea and relevant to an area of research that I'm looking at. > > Something that I've been considering is how might IPv6 impact > individuals, i.e. home users who typically have limited internet > security. Under IPv4 NAT has provided an "accidental" firewall that > has been very beneficial to such subscribers. As the migration to IPv6 > takes hold, it strikes me that specific firewalls will become mandatory > (and critical that they are kept up to date), but those subscribers > won't perceive any benefit from such devices (at least not until it is > too late) and will simply connect devices directly to the internet with > insufficient protection. RFC6092, "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", recommends that equipment filter by default. And I know both Apple and Linksys ship with IPv6 filters by default. I expect other vendors (e.g., D-Link) have IPv6 filters by default, too. The proverbial "Grandma" does not want her IPv6 NAS or IPv6 television accessed by someone on the Internet by default. Grandma should have to do something on the NAS or the television to enable that remote access if she wanted it. -d > So, and this is where you paper is relevant, I have been pondering how > IPv6 can be deployed to these subscribers with the added benefit of the > "built-in" security that they have been used to with the likes of NAT. > > Am I right in understanding that you packet staining could provide > service provision that might include any number of the following: > > * Spam Assessment > * Parental Controls > * Malware Detection > * Forged Certificates > * etc > > Some of the above would require deep packet inspection, at least as far > as protocol, and in some cases of the actual data. Is this within > scope of what you envisage ? > > It strikes me that your Packet Staining concept could enable the > provision of services that meet the needs of these subscribers in a > manner that will enable them to "configure and forget", much like they > already experience with Anti-Virus products which regularly download > updates), except that they would get the benefit of a more intelligent > process that has a re timely updates and the potential for filtering at > the perimeter or the endpoint. > > Finally, it is not clear to me whether there is any impact if IPsec is > involved, which would prevent such a level of packet inspection. > > Many thanks for you contribution and thoughts. > > Regards > Steve Martin From tyson.macaulay@bell.ca Fri Feb 17 12:37:47 2012 Return-Path: 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 2899921E8066 for ; Fri, 17 Feb 2012 12:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 2f-phowhADjC for ; Fri, 17 Feb 2012 12:37:46 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id BAC071F0C4E for ; Fri, 17 Feb 2012 12:37:45 -0800 (PST) Received: from [85.158.137.83:21172] by server-1.bemta-3.messagelabs.com id CF/BC-02415-89ABE3F4; Fri, 17 Feb 2012 20:37:44 +0000 X-Env-Sender: tyson.macaulay@bell.ca X-Msg-Ref: server-13.tower-140.messagelabs.com!1329511053!16250498!19 X-Originating-IP: [206.47.0.173] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22742 invoked from network); 17 Feb 2012 20:37:44 -0000 Received: from srp004376srs (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-13.tower-140.messagelabs.com with RC4-SHA encrypted SMTP; 17 Feb 2012 20:37:44 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012 15:37:24 -0500 Received: from MBX08.bell.corp.bce.ca ([142.182.199.89]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Fri, 17 Feb 2012 15:37:28 -0500 From: "tyson.macaulay@bell.ca" To: "ipv6@ietf.org" Date: Fri, 17 Feb 2012 15:37:27 -0500 Subject: RE: ipv6 Digest, Vol 94, Issue 17 Thread-Topic: ipv6 Digest, Vol 94, Issue 17 Thread-Index: AcztrsfIw4jbCtgmRmyBox2Qt0HvXAABDyRQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:37:47 -0000 >=20 > Hi Tyson, HI Steve, First - thanks for your comments and questions They are on topic and on t= arget. > I've just read your ITEF paper on Packet Staining, a very interesting > idea and relevant to an area of research that I'm looking at. >=20 > Something that I've been considering is how might IPv6 impact > individuals, i.e. home users who typically have limited internet > security. Under IPv4 NAT has provided an "accidental" firewall that > has been very beneficial to such subscribers. As the migration to IPv6 > takes hold, it strikes me that specific firewalls will become mandatory > (and critical that they are kept up to date), but those subscribers > won't perceive any benefit from such devices (at least not until it is > too late) and will simply connect devices directly to the internet with > insufficient protection. >=20 > So, and this is where you paper is relevant, I have been pondering how > IPv6 can be deployed to these subscribers with the added benefit of the > "built-in" security that they have been used to with the likes of NAT. >=20 > Am I right in understanding that you packet staining could provide > service provision that might include any number of the following: >=20 > * Spam Assessment Staining will insert a reputation score into each packet. The reputation t= axonomy is variable (at least at this time) and could include sub-classes j= ust for spam. In such a case, those stains may only be used by email syste= ms while other assets such as web servers choose to ignore them (because th= ey are email-specific stains). This is at the discretion of the implemente= r. > * Parental Controls This is a core function of staining. Certain type of content will fall int= o a reputation category. It is certainly possible that an ISP may elect to= stain traffic entering the distribution network for residential customers = and then allow the customers to in effect filter the traffic on the edge de= vice (DSL/DOCSIS router) or end-point device. Much the same thing can be d= one with DNS services now - but it applies to every device in the house. S= taining could be applied device by device - though the network stack would = need to read the stains or third-party software would need to read the stai= ns. > * Malware Detection This is a core function. The idea is that a carrier/ISP will stain traffic= from known malware sites/locations as it enters the network and then allow= subscribers to filter quickly on their end. The ISP in this case may elec= t to filter traffic from malware sites at the access layer of the ISP, or l= et the subscriber endpoints do it as part of a subscription services. > * Forged Certificates A forged cert, once discovered, would affect the reputation of the site usi= ng the certificate and probably the CA itself. Their reputations would be = stained accordingly and traffic filtered on this basis. Staining devices w= ill generally not make decisions about whether certificate is forged or no= t - they use intelligence supplied by various different means that is outsi= de the scope of the DRAFT right now. > * etc Another use-case we tried to describe (briefly) is that staining can also c= reated walled-gardens. Traffic from "approved" sites has a specific stain a= nd only packets with that stain may enter (network, endpoint, whatever). S= chools might like this - where only traffic from approved educational sites= get into the network. True - firewalls can do this now but it's a problem= and a hassle to maintain such devices, and DNS-type filtering can be defea= ted by simply re-configuring your host DNS IP. Staining can be used to do = firewalling and content filtering in the carrier or ISP cloud, at least in = part. These days we need all the layers of security we can get. >=20 > Some of the above would require deep packet inspection, at least as far > as protocol, and in some cases of the actual data. Is this within > scope of what you envisage ? DPI is partially in scope when the reputation of large portals is at stake.= For instance, Facebook. One of the staining options is to indicate if th= e reputation stain includes a URL. When the stain includes a URL, the stai= ning-reading element (FW, etc) may need to do DPI to see if the URL is pres= ent. =20 >=20 > It strikes me that your Packet Staining concept could enable the > provision of services that meet the needs of these subscribers in a > manner that will enable them to "configure and forget", much like they > already experience with Anti-Virus products which regularly download > updates), except that they would get the benefit of a more intelligent > process that has a re timely updates and the potential for filtering at > the perimeter or the endpoint. Yes - in addition to more timely threat intelligence, the solution itself i= s possibly more scalable, since massive list of threat signatures and/or ex= tracts from a virtually unlimited IP-space would not need to be managed. Thanks for your comments and collaboration as we refine the draft. >=20 > Finally, it is not clear to me whether there is any impact if IPsec is > involved, which would prevent such a level of packet inspection. >=20 > Many thanks for you contribution and thoughts. >=20 > Regards > Steve Martin From internet-drafts@ietf.org Tue Feb 21 01:14:43 2012 Return-Path: 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 B32B221F84AE; Tue, 21 Feb 2012 01:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 Jbb2aEULj6zN; Tue, 21 Feb 2012 01:14:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512A21F84C3; Tue, 21 Feb 2012 01:14:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-uri-zoneid-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221091434.26970.33378.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 01:14:34 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:14:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Representing IPv6 Zone Identifiers in Uniform Resource I= dentifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-00.txt Pages : 7 Date : 2012-02-17 This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-uri-zoneid-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-uri-zoneid-00.txt From internet-drafts@ietf.org Tue Feb 21 02:35:16 2012 Return-Path: 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 600A921F8602; Tue, 21 Feb 2012 02:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1+qf4TU2cYEa; Tue, 21 Feb 2012 02:34:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB6421F8548; Tue, 21 Feb 2012 02:34:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221103457.16891.40315.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 02:34:57 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:35:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Jun-ya Kato Tim Chown Filename : draft-ietf-6man-addr-select-opt-03.txt Pages : 10 Date : 2012-02-21 RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection policy table, and thus control the address selection behavior of nodes in their site. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-03.txt From v6ops@globis.net Tue Feb 21 09:56:34 2012 Return-Path: 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 B6B5D21F87D5 for ; Tue, 21 Feb 2012 09:56:34 -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 YV5aXaNnZYOO for ; Tue, 21 Feb 2012 09:56:30 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF021F87AB for ; Tue, 21 Feb 2012 09:56:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AA94E8700AE for ; Tue, 21 Feb 2012 18:56:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgz5IvXXNUBH for ; Tue, 21 Feb 2012 18:56:18 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 17EF4870069 for ; Tue, 21 Feb 2012 18:56:18 +0100 (CET) Message-ID: <4F43DAC1.8070407@globis.net> Date: Tue, 21 Feb 2012 18:56:17 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: 6man Mailing List Subject: [6MAN] I-D Action: draft-ietf-6man-addr-select-opt-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:56:34 -0000 I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks. Some comments. 1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status "single-homed" and "only one upstream line" is time dependent. A highly-mobile device may have a semi-permanent 4G uplink, and a temporary wifi uplink dependent on the user's current location. Whether a new Address Selection Policy table is installed or not should not depend primarily on the order that the interfaces are brought up. 2) Suggest splitting transport of policy/configuration information from actual use of the policy/configuration information by the end node. I'm thinking of how routers may have multiple sources of routing information (derived from various sources: static, RIPng, OSPFv3) but they may only install subsets of the total known information into the single active forwarding table using local policy configuration concepts such as Administrative Distance and locally defined route filters. 3) MIF RFC 6419 identifies that address selection and interface selection mechanisms are not consistently applied across various implementations. Humbly suggest adding an Informative Reference, whilst leaving solving such selection and consistency problems to the MIF WG. 4) MIF RFC 6418 defines the concepts of "Provisioning Domain" & "Administrative Domain" Humbly suggest adding an Informative Reference and adopting this terminology in your draft. 5) DHCPv6 RFC 3315 Section 16 states "a client .. SHOULD send the message through the interface for which configuration information is being requested." Since a highly-mobile node may communicate with multiple (inconsistent) sources of DHCPv6 information via different interfaces, depending on the selected DHCPv6 server(s)/ relays, and which interfaces are active at any particular time, is it worth discussing a mechanism to track the provenance of the received "node-global information"? I think it may be useful to be able to tag DHCPv6 derived policy/configuration information (such as the Address Selection Policy table) with a provenance, so that an end node may associate the configuration/ policy information learned from an interface/DHCPv6 server combination with a "Provisioning Domain" and/or "Administrative Domain." Otherwise how do you know which Address Selection Policy table is appropriate to install/ de-install as the active table as each interface goes up/down? And if the MIF WG defines a way of selecting a Provisioning Domain, the Address Selection Policy info learned via DHCPv6 will already be appropriately tagged (before being processed/installed into any active node-global table). regards, RayH > Message: 5 > Date: Wed, 15 Feb 2012 03:40:10 -0800 > From:internet-drafts@ietf.org > To:i-d-announce@ietf.org > Cc:ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt > Message-ID:<20120215114010.14255.26519.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Distributing Address Selection Policy using DHCPv6 > Author(s) : Arifumi Matsumoto > Tomohiro Fujisaki > Jun-ya Kato > Tim Chown > Filename : draft-ietf-6man-addr-select-opt-02.txt > Pages : 10 > Date : 2012-02-15 > > RFC 3484 defines default address selection mechanisms for IPv6 that > allow nodes to select appropriate address when faced with multiple > source and/or destination addresses to choose between. The RFC 3484 > allowed for the future definition of methods to administratively > configure the address selection policy information. This document > defines a new DHCPv6 option for such configuration, allowing a site > administrator to distribute address selection policy overriding the > default address selection policy table, and thus control the address > selection behavior of nodes in their site. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt > From brian.e.carpenter@gmail.com Tue Feb 21 12:13:39 2012 Return-Path: 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 9DCD621F83EF for ; Tue, 21 Feb 2012 12:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 MHA36BG0d-Af for ; Tue, 21 Feb 2012 12:13:35 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 619D821E809A for ; Tue, 21 Feb 2012 12:13:35 -0800 (PST) Received: by iagf6 with SMTP id f6so11717796iag.31 for ; Tue, 21 Feb 2012 12:13:35 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.150.200 as permitted sender) client-ip=10.42.150.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.150.200 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.42.150.200]) by 10.42.150.200 with SMTP id b8mr29248205icw.43.1329855215146 (num_hops = 1); Tue, 21 Feb 2012 12:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A4QPmZFfAR6Tq0ywX/+IRi3ZieSBUDww36AzfDcDQK4=; b=qSDeKbDsJAv87QIbUUHyy0HPEX77MVQYzCxe/n8fVmZ/FGBW/k05TfWFF1Pww+3lyT GiWEz9JzsH75YT9zKfEptBrNreGdcOtmJqx5JO8Bl3tJo3BHVzytKsOdagTuzTHZ1O4E tpt6IvGHNGCsC0Of2MTHFTtKRcimFKtJ3yG64= Received: by 10.42.150.200 with SMTP id b8mr23354598icw.43.1329855215079; Tue, 21 Feb 2012 12:13:35 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id em2sm10998291igc.0.2012.02.21.12.13.32 (version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 12:13:34 -0800 (PST) Message-ID: <4F43FAE9.8040401@gmail.com> Date: Wed, 22 Feb 2012 09:13:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-ietf-6man-uri-zoneid-00.txt References: <20120221091434.26970.33378.idtracker@ietfa.amsl.com> In-Reply-To: <20120221091434.26970.33378.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:13:39 -0000 Hi, All comments have been incorporated in this version. Should we seek comments from the URI community before asking for a WGLC? Regards Brian Carpenter On 2012-02-21 22:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-ietf-6man-uri-zoneid-00.txt > Pages : 7 > Date : 2012-02-17 > > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a Uniform Resource Identifier that > includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-uri-zoneid-00.txt > From dthaler@microsoft.com Wed Feb 22 18:20:29 2012 Return-Path: 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 0D55221E8020 for ; Wed, 22 Feb 2012 18:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.765 X-Spam-Level: X-Spam-Status: No, score=-103.765 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 gB1wASMUMRZI for ; Wed, 22 Feb 2012 18:20:27 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4031321E8013 for ; Wed, 22 Feb 2012 18:20:27 -0800 (PST) Received: from mail59-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 Feb 2012 02:20:20 +0000 Received: from mail59-db3 (localhost [127.0.0.1]) by mail59-db3-R.bigfish.com (Postfix) with ESMTP id 1D92F4036B; Thu, 23 Feb 2012 02:20:20 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zzbb2dI9371Ic89bh936eK542M1432N4015Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail59-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3 (MessageSwitch) id 1329963617921688_3295; Thu, 23 Feb 2012 02:20:17 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.235]) by mail59-db3.bigfish.com (Postfix) with ESMTP id D2AC74E0067; Thu, 23 Feb 2012 02:20:17 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 Feb 2012 02:20:17 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.247.5; Thu, 23 Feb 2012 02:19:47 +0000 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.70]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Wed, 22 Feb 2012 18:19:47 -0800 From: Dave Thaler To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: RE: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt Thread-Index: AQHMmChmRg+u/LYUvEGYyyDnLOG75pWhtQyAgAKEuwCAAn3ygICjuiag Date: Thu, 23 Feb 2012 02:19:47 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4397EA@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <20111031235203.11203.64958.idtracker@ietfa.amsl.com> <1320658117.39943.YahooMailNeo@web126007.mail.ne1.yahoo.com> <1320933569.67232.YahooMailNeo@web126003.mail.ne1.yahoo.com> In-Reply-To: <1320933569.67232.YahooMailNeo@web126003.mail.ne1.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Arifumi Matsumoto , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 02:20:29 -0000 Going back through all these old threads while I'm working on rfc3484bis... If anycast addresses are no longer prohibited in general, I don't see why we should call out any in particular. If an implementation wants to includ= e them or exclude them, it's up to the implementation. Previously RFC 3484 said anycast MUST NOT be included in the candidate source addresses set. It did not contain any MUSTs about what *is* includ= ed. It has a RECOMMENDED statement, and statements about what not to include. So once the MUST NOT is removed, it's already implementation specific and becomes a quality-of-implementation issue. If someone has a way to make some anycast address work, then it's fine to include as a source addre= ss. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fran=E7ois-Xavier Le Bail > Sent: Thursday, November 10, 2011 5:59 AM > To: Arifumi Matsumoto > Cc: ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt >=20 > ----- Original Message ----- >=20 > > From: Arifumi Matsumoto > > To: Fran=E7ois-Xavier Le Bail > > Cc: "ipv6@ietf.org" > > Sent: Wednesday, November 9, 2011 12:56 AM > > Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt > > > > Hi, > > > > Thanks for your suggestion. > > > > , and also we should also mention about Reserved IPv6 Subnet Anycast > Addresses ? > > http://tools.ietf.org/html/rfc2526 >=20 > Hi, >=20 > I had a look at RFC 2526. >=20 > It's seems it's the same case than SRaa, but I have no practical experien= ce with > such a reserved subnet anycast address. >=20 > has someone an experience with these ? >=20 > Fran=E7ois-Xavier >=20 > > > > 2011/11/7 Fran=E7ois-Xavier Le Bail : > >> > >> Hi, > >> > >> The draft has taken into account anycast addresses. > >> > >> http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05#section- > >> 2.6 > >> > >> It remains to handle the special case of Subnet-Router anycast addres= s. > >> (http://tools.ietf.org/html/rfc4291#section-2.6.1) > >> "The Subnet-Router anycast address is intended to be used for > >> applications where a node needs to communicate with any one of the > >> set of routers." > >> > >> So, I think a SRaa must be excluded from the candidate set of source > > address > >> for a new communication. > >> The SRaa as source address must be reserved for a reply to a packet > >> sent to > > this SRaa. > >> > >> Text proposal (to add section 2.6) : > >> "As an exception, a Subnet-Router anycast address MUST NOT be > >> included > > in the > >> candidate set of source address when initiating communication. > >> The Subnet-Router anycast address as source address MUST be used in > >> a reply to a packet sent to this Subnet-Router anycast address". > >> > >> Thanks, > >> Fran=E7ois-Xavier > >> > >> > >> ----- Original Message ----- > >>> From: "internet-drafts@ietf.org" > > > >>> To: i-d-announce@ietf.org > >>> Cc: ipv6@ietf.org > >>> Sent: Tuesday, November 1, 2011 12:52 AM > >>> Subject: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>> This draft is a work item of the IPv6 Maintenance Working Group of > >>> the > > IETF. > >>> > >>> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 =A0: Update to RFC 3484 Default A= ddress Selection > >>> for > > IPv6 > >>> =A0=A0=A0 Author(s)=A0 =A0 =A0 =A0: Arifumi Matsumoto > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jun-ya Kato > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tomohiro Fujisak= i > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Chown > >>> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-6man-rfc3484-revise-0= 5.txt > >>> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 12 > >>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2011-10-31 > >>> > >>> =A0 =A0RFC 3484 describes algorithms for source address selection an= d > >>> for > >>> =A0 =A0destination address selection.=A0 The algorithms specify defa= ult > >>> =A0 =A0behavior for all Internet Protocol version 6 (IPv6) implement= ations. > >>> =A0 =A0This document specifies a set of updates that modify the > >>> algorithms > >>> =A0 =A0and fix the known defects. > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> > > http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05. > > txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> This Internet-Draft can be retrieved at: > >>> > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.t > > xt > >>> > >>> -------------------------------------------------------------------- > >>> 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 > -------------------------------------------------------------------- From internet-drafts@ietf.org Thu Feb 23 00:50:58 2012 Return-Path: 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 F23E121F85D0; Thu, 23 Feb 2012 00:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 vi6kSAzXykkN; Thu, 23 Feb 2012 00:50:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2921F85CF; Thu, 23 Feb 2012 00:50:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rfc3484bis-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120223085054.14526.31735.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 00:50:54 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 08:50:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Default Address Selection for Internet Protocol version = 6 (IPv6) Author(s) : Dave Thaler Richard Draves Tim Chown Filename : draft-ietf-6man-rfc3484bis-00.txt Pages : 30 Date : 2012-02-22 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484bis-00.txt From bob.hinden@gmail.com Thu Feb 23 15:22:12 2012 Return-Path: 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 5500221F88CC for ; Thu, 23 Feb 2012 15:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.522 X-Spam-Level: X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 rYXOlumtyJVC for ; Thu, 23 Feb 2012 15:22:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 621D421F88CA for ; Thu, 23 Feb 2012 15:22:07 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1996833pbc.31 for ; Thu, 23 Feb 2012 15:22:07 -0800 (PST) Received-SPF: pass (google.com: domain of bob.hinden@gmail.com designates 10.68.138.194 as permitted sender) client-ip=10.68.138.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bob.hinden@gmail.com designates 10.68.138.194 as permitted sender) smtp.mail=bob.hinden@gmail.com; dkim=pass header.i=bob.hinden@gmail.com Received: from mr.google.com ([10.68.138.194]) by 10.68.138.194 with SMTP id qs2mr184214pbb.138.1330039327286 (num_hops = 1); Thu, 23 Feb 2012 15:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZSfcn5vFO/lSH9bT4rA2jb7nI9ymzCpnqMSfAskz+iQ=; b=EYCWhm2uLnW5YHlImTDIU8LiKOOIlCbOJ6wwu0YnWXhcrLK2NPGIHl5YuFC7cF7Sam s6SZqVdHsGb4Pt1+pjBlsehgDMy4fe6wtbyyi42KfncAXyDBEUkidcaXMFnlyXEJ306K vqVbXQ3GqOFxwDSQ0RhP5aDpu4bYNT5Js7pSg= Received: by 10.68.138.194 with SMTP id qs2mr150885pbb.138.1330039327199; Thu, 23 Feb 2012 15:22:07 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id j3sm2652027pbb.29.2012.02.23.15.22.05 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 15:22:06 -0800 (PST) Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bob Hinden In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4397EA@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 23 Feb 2012 15:22:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCC1188-F080-45C5-88AF-0D2E521BD0DB@gmail.com> References: <20111031235203.11203.64958.idtracker@ietfa.amsl.com> <1320658117.39943.YahooMailNeo@web126007.mail.ne1.yahoo.com> <1320933569.67232.YahooMailNeo@web126003.mail.ne1.yahoo.com> <9B57C850BB53634CACEC56EF4853FF653B4397EA@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: Arifumi Matsumoto , Bob Hinden , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:22:12 -0000 On Feb 22, 2012, at 6:19 PM, Dave Thaler wrote: > Going back through all these old threads while I'm working on = rfc3484bis... >=20 > If anycast addresses are no longer prohibited in general, I don't see = why > we should call out any in particular. If an implementation wants to = include > them or exclude them, it's up to the implementation. >=20 > Previously RFC 3484 said anycast MUST NOT be included in the candidate > source addresses set. It did not contain any MUSTs about what *is* = included. > It has a RECOMMENDED statement, and statements about what not to = include. >=20 > So once the MUST NOT is removed, it's already implementation specific = and > becomes a quality-of-implementation issue. If someone has a way to > make some anycast address work, then it's fine to include as a source = address. Works for me. Bob >=20 > -Dave >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >> Fran=E7ois-Xavier Le Bail >> Sent: Thursday, November 10, 2011 5:59 AM >> To: Arifumi Matsumoto >> Cc: ipv6@ietf.org >> Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt >>=20 >> ----- Original Message ----- >>=20 >>> From: Arifumi Matsumoto >>> To: Fran=E7ois-Xavier Le Bail >>> Cc: "ipv6@ietf.org" >>> Sent: Wednesday, November 9, 2011 12:56 AM >>> Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt >>>=20 >>> Hi, >>>=20 >>> Thanks for your suggestion. >>>=20 >>> , and also we should also mention about Reserved IPv6 Subnet Anycast >> Addresses ? >>> http://tools.ietf.org/html/rfc2526 >>=20 >> Hi, >>=20 >> I had a look at RFC 2526. >>=20 >> It's seems it's the same case than SRaa, but I have no practical = experience with >> such a reserved subnet anycast address. >>=20 >> has someone an experience with these ? >>=20 >> Fran=E7ois-Xavier >>=20 >>>=20 >>> 2011/11/7 Fran=E7ois-Xavier Le Bail : >>>>=20 >>>> Hi, >>>>=20 >>>> The draft has taken into account anycast addresses. >>>>=20 >>>> = http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05#section- >>>> 2.6 >>>>=20 >>>> It remains to handle the special case of Subnet-Router anycast = address. >>>> (http://tools.ietf.org/html/rfc4291#section-2.6.1) >>>> "The Subnet-Router anycast address is intended to be used for >>>> applications where a node needs to communicate with any one of the >>>> set of routers." >>>>=20 >>>> So, I think a SRaa must be excluded from the candidate set of = source >>> address >>>> for a new communication. >>>> The SRaa as source address must be reserved for a reply to a packet >>>> sent to >>> this SRaa. >>>>=20 >>>> Text proposal (to add section 2.6) : >>>> "As an exception, a Subnet-Router anycast address MUST NOT be >>>> included >>> in the >>>> candidate set of source address when initiating communication. >>>> The Subnet-Router anycast address as source address MUST be used in >>>> a reply to a packet sent to this Subnet-Router anycast address". >>>>=20 >>>> Thanks, >>>> Fran=E7ois-Xavier >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>>> From: "internet-drafts@ietf.org" >>> >>>>> To: i-d-announce@ietf.org >>>>> Cc: ipv6@ietf.org >>>>> Sent: Tuesday, November 1, 2011 12:52 AM >>>>> Subject: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the IPv6 Maintenance Working Group of >>>>> the >>> IETF. >>>>>=20 >>>>> Title : Update to RFC 3484 Default Address Selection >>>>> for >>> IPv6 >>>>> Author(s) : Arifumi Matsumoto >>>>> Jun-ya Kato >>>>> Tomohiro Fujisaki >>>>> Tim Chown >>>>> Filename : draft-ietf-6man-rfc3484-revise-05.txt >>>>> Pages : 12 >>>>> Date : 2011-10-31 >>>>>=20 >>>>> RFC 3484 describes algorithms for source address selection and >>>>> for >>>>> destination address selection. The algorithms specify default >>>>> behavior for all Internet Protocol version 6 (IPv6) = implementations. >>>>> This document specifies a set of updates that modify the >>>>> algorithms >>>>> and fix the known defects. >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>>=20 >>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05. >>> txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>>=20 >>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.t >>> xt >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list ipv6@ietf.org = Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From arifumi@nttv6.net Thu Feb 23 22:15:13 2012 Return-Path: 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 3196321F883B for ; Thu, 23 Feb 2012 22:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, 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 EZ+tvRMxLdmI for ; Thu, 23 Feb 2012 22:15:12 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8556E21F87C9 for ; Thu, 23 Feb 2012 22:15:10 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1O6G55N083720; Fri, 24 Feb 2012 15:16:05 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <4F3ABFBA.8060605@gmail.com> Date: Fri, 24 Feb 2012 15:13:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: Bob Hinden , "ipv6@ietf.org" , Brian Haberman , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 06:15:13 -0000 Dave, in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the response to this issue of ULA scope. 10.6. Configuring ULA Preference ... Since ULAs are defined to have a /48 site prefix, an implementation might choose to add such a row automatically on a machine with a ULA. It is also worth noting that ULAs are assigned global scope. As such, the existence of one or more rows in the prefix policy table is important so that source address selection does not choose a ULA purely based on longest match: Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Destination Address List: ff00:1 Result: 2001:db8:1::1 (prefer matching label) IMO, this implicit specification causes several problems. First of all, if you leave it to implementation, this creates an interoperability problem. In the sense that a site administrator, an application developer, a network designer, have to take care of the nodes with different address selection behavior. Second, when a user configures his policy table, the configured table is overwritten by this implementation dependent policy injection behavior ? Can the user suppress this behavior of policy injection ? This issue should arise also when a policy distributing mechanism is ready. Kindest regards, On 2012/02/15, at 5:10, Brian E Carpenter wrote: > On 2012-02-15 05:49, Arifumi Matsumoto wrote: >> Dave, >>=20 >> one quick question below. >>=20 >> On 2012/02/11, at 11:41, Dave Thaler wrote: >=20 > ... >>> 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. >>=20 >> So, you are suggesting to map ULAs(fc00::/7) to site-local scope also = for unicast ? >> Then, I don't see how the former case can be solved by this fix. >> The ULAs should be chosen for both src and dst addresses, if they = have smaller >> scope than global addresses, right ? >=20 > IMHO we have to be very careful about messing with the formal scope of = ULAs. > They are unambiguously defined *architecturally* as having global = scope, > and address selection rules have to respect that (unless we make a = major > architectural effort, since IMNSHO our whole concept of unicast scope = is > broken). >=20 > In other words - in the unicast domain, ULAs have to stay global, and = longest- > match or explicit rules are the only solution. >=20 > Multicast is a different matter, since site-local scope is well = defined there. >=20 >>=20 >> Or, are you suggesting to map only ULAs that is in the same prefix to = site-local scope ? >=20 > Not needed; longest match takes care of that. The tricky case is where = you > have several ULA prefixes in use on the same site. >=20 > Brian -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From arifumi@nttv6.net Fri Feb 24 00:21:14 2012 Return-Path: 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 10BC321E804D for ; Fri, 24 Feb 2012 00:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, 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 uS7Em7EYxDgA for ; Fri, 24 Feb 2012 00:21:00 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id CF3FB21E804A for ; Fri, 24 Feb 2012 00:20:41 -0800 (PST) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q1O8KBXh084414; Fri, 24 Feb 2012 17:20:12 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: [6MAN] I-D Action: draft-ietf-6man-addr-select-opt-02.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <4F43DAC1.8070407@globis.net> Date: Fri, 24 Feb 2012 17:17:55 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <86702FAA-6DD4-4423-8EF2-B62ED35A0CE5@nttv6.net> References: <4F43DAC1.8070407@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1257) Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:21:15 -0000 Ray, thank you for your comments. On 2012/02/22, at 2:56, Ray Hunter wrote: > I have read draft-ietf-6man-addr-select-opt-03. I support this work. = Thanks. >=20 > Some comments. >=20 > 1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the = status "single-homed" and "only one upstream line" is time dependent. A = highly-mobile device may have a semi-permanent 4G uplink, and a = temporary wifi uplink dependent on the user's current location. Whether = a new Address Selection Policy table is installed or not should not = depend primarily on the order that the interfaces are brought up. If we think about the routing table, the entries related to a certain = network interface will also be added and deleted, when the interface = goes up and down. So, it seems to me that this issue is not too new, or strange for = implementors. > 2) Suggest splitting transport of policy/configuration information = from actual use of the policy/configuration information by the end node. = I'm thinking of how routers may have multiple sources of routing = information (derived from various sources: static, RIPng, OSPFv3) but = they may only install subsets of the total known information into the = single active forwarding table using local policy configuration concepts = such as Administrative Distance and locally defined route filters. Do you suggest splitting them into different documents, or just defining = the transport information format and leaving others to implementation = dependent ? I do not see much value in just dividing this into two documents. It = just makes it troublesome to understand this mechanism. Regarding the latter case, IMO, this mechanism is so new, and no operational experiences are gained = by administrators, implementors, and so on. So, we first have to propose = the expected /recommended way to use this mechanism. If you find the = current specification goes beyond recommendation in some points, please = tell it to me. > 3) MIF RFC 6419 identifies that address selection and interface = selection mechanisms are not consistently applied across various = implementations. >=20 > Humbly suggest adding an Informative Reference, whilst leaving solving = such selection and consistency problems to the MIF WG. agree. > 4) MIF RFC 6418 defines the concepts of "Provisioning Domain" & = "Administrative Domain" >=20 > Humbly suggest adding an Informative Reference and adopting this = terminology in your draft. agree. >=20 > 5) DHCPv6 RFC 3315 Section 16 states "a client .. SHOULD send the = message through the interface for which configuration information is = being requested." >=20 > Since a highly-mobile node may communicate with multiple = (inconsistent) sources of DHCPv6 information via different interfaces, = depending on the selected DHCPv6 server(s)/ relays, and which interfaces = are active at any particular time, is it worth discussing a mechanism to = track the provenance of the received "node-global information"? >=20 > I think it may be useful to be able to tag DHCPv6 derived = policy/configuration information (such as the Address Selection Policy = table) with a provenance, so that an end node may associate the = configuration/ policy information learned from an interface/DHCPv6 = server combination with a "Provisioning Domain" and/or "Administrative = Domain." >=20 > Otherwise how do you know which Address Selection Policy table is = appropriate to install/ de-install as the active table as each interface = goes up/down? >=20 > And if the MIF WG defines a way of selecting a Provisioning Domain, = the Address Selection Policy info learned via DHCPv6 will already be = appropriately tagged (before being processed/installed into any active = node-global table). I think it is a matter of implementation, and common for several other = DHCPv6 options. It may be helpful for implementors, but this document should not be the = right place for this generic issue. Thanks ! >=20 > regards, > RayH >=20 >> Message: 5 >> Date: Wed, 15 Feb 2012 03:40:10 -0800 >> From:internet-drafts@ietf.org >> To:i-d-announce@ietf.org >> Cc:ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt >> Message-ID:<20120215114010.14255.26519.idtracker@ietfa.amsl.com> >> Content-Type: text/plain; charset=3D"utf-8" >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >>=20 >> Title : Distributing Address Selection Policy using = DHCPv6 >> Author(s) : Arifumi Matsumoto >> Tomohiro Fujisaki >> Jun-ya Kato >> Tim Chown >> Filename : draft-ietf-6man-addr-select-opt-02.txt >> Pages : 10 >> Date : 2012-02-15 >>=20 >> RFC 3484 defines default address selection mechanisms for IPv6 = that >> allow nodes to select appropriate address when faced with multiple >> source and/or destination addresses to choose between. The RFC = 3484 >> allowed for the future definition of methods to administratively >> configure the address selection policy information. This document >> defines a new DHCPv6 option for such configuration, allowing a = site >> administrator to distribute address selection policy overriding = the >> default address selection policy table, and thus control the = address >> selection behavior of nodes in their site. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt= >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt >> =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From v6ops@globis.net Fri Feb 24 02:27:07 2012 Return-Path: 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 8279021F87B5 for ; Fri, 24 Feb 2012 02:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Uf++ceWY6Qhd for ; Fri, 24 Feb 2012 02:27:06 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5764C21F8919 for ; Fri, 24 Feb 2012 02:27:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 251A88700EC; Fri, 24 Feb 2012 11:27:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYbrb5slGXWY; Fri, 24 Feb 2012 11:26:53 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5F4CE870069; Fri, 24 Feb 2012 11:26:53 +0100 (CET) Message-ID: <4F4765ED.2080504@globis.net> Date: Fri, 24 Feb 2012 11:26:53 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: [6MAN] I-D Action: draft-ietf-6man-addr-select-opt-02.txt References: <4F43DAC1.8070407@globis.net> <86702FAA-6DD4-4423-8EF2-B62ED35A0CE5@nttv6.net> In-Reply-To: <86702FAA-6DD4-4423-8EF2-B62ED35A0CE5@nttv6.net> Content-Type: multipart/alternative; boundary="------------010903090901050204080404" Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:27:07 -0000 This is a multi-part message in MIME format. --------------010903090901050204080404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Answers in line Arifumi Matsumoto wrote: > Ray, > > thank you for your comments. > > On 2012/02/22, at 2:56, Ray Hunter wrote: > > >> I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks. >> >> Some comments. >> >> 1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status "single-homed" and "only one upstream line" is time dependent. A highly-mobile device may have a semi-permanent 4G uplink, and a temporary wifi uplink dependent on the user's current location. Whether a new Address Selection Policy table is installed or not should not depend primarily on the order that the interfaces are brought up. >> > > If we think about the routing table, the entries related to a certain network interface will also be added and deleted, when the interface goes up and down. > > So, it seems to me that this issue is not too new, or strange for implementors. > > My concern is that the guidance in this draft is not correctly formulated IMHO. I agree that incorrect use of the addr-select-opt may lead to a security issue, in that node-global behavior is affected by the proposed option. Thus traffic intended for interface 1/ network 1 may be misdirected to interface 2 / network 2 by receiving an address-selection policy option from network 2. However, this security risk is not directly correlated to the number of active interfaces at the time the policy is received IMHO. In some situations I can think of, you may well want to trust a particular DHCPv6 server to configure a link address on an interface, plus maybe some hints about which name servers or time servers to use to set up an initial connection, but not to set a policy for which address ranges and hence interfaces to select for which traffic. Even receiving policy information over one active interface may not be considered a reasonable risk by some e.g. if a second interface is brought up later (e.g. a tunnel), and (some of) the old policy information from the first interface is not flushed because that first interface is still up and the second interface does not provide a policy update. In a corporate environment, it may well be desirable to receive policy updates on multiple interfaces without having to explicitly configure this, because all updates ultimately have been derived from a trusted AS source. Therefore I think the risk is more closely related to the consistency and provenance of the DHCPv6 derived address selection policy information i.e. whether the device is receiving the option from more than one Autonomous System simultaneously, or from an AS source that is not trusted. I'd be happy if the draft contained a warning of the risk, without getting into details of how to mitigate the risk in implementation. >> 2) Suggest splitting transport of policy/configuration information from actual use of the policy/configuration information by the end node. I'm thinking of how routers may have multiple sources of routing information (derived from various sources: static, RIPng, OSPFv3) but they may only install subsets of the total known information into the single active forwarding table using local policy configuration concepts such as Administrative Distance and locally defined route filters. >> > > Do you suggest splitting them into different documents, or just defining the transport information format and leaving others to implementation dependent ? > I do not see much value in just dividing this into two documents. It just makes it troublesome to understand this mechanism. > > Regarding the latter case, > IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism. If you find the current specification goes beyond recommendation in some points, please tell it to me. > > I humbly suggest considering which WG is appropriate for defining which portion of the overall mechanism. There seems to be a very large overlap with MIF, and one possible way to handle this would be to have the pure transport of the option defined in your 6man draft (which I guess could be pretty non-contentious), and defining the use of the information in the MIF workflow. Another option might be simply to co-post the draft to the MIF WG. > I think it is a matter of implementation, and common for several other DHCPv6 options. > > It may be helpful for implementors, but this document should not be the right place for this generic issue. > > Thanks ! > > Agree. This is off topic for your draft, but maybe someone will take up the generic challenge in another draft. regards, RayH --------------010903090901050204080404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Answers in line

Arifumi Matsumoto wrote: 
Ray,

thank you for your comments.

On 2012/02/22, at 2:56, Ray Hunter wrote:

  
I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks.

Some comments.

1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status "single-homed" and "only one upstream line" is time dependent. A highly-mobile device may have a semi-permanent 4G uplink, and a temporary wifi uplink dependent on the user's current location. Whether a new Address Selection Policy table is installed or not should not depend primarily on the order that the interfaces are brought up.
    

If we think about the routing table, the entries related to a certain network interface will also be added and deleted, when the interface goes up and down.

So, it seems to me that this issue is not too new, or strange for implementors.
My concern is that the guidance in this draft is not correctly formulated IMHO.

I agree that incorrect use of the addr-select-opt may lead to a security issue, in that node-global behavior is affected by the proposed option. Thus traffic intended for interface 1/ network 1 may be misdirected to interface 2 / network 2 by receiving an address-selection policy option from network 2.

However, this security risk is not directly correlated to the number of active interfaces at the time the policy is received IMHO.

In some situations I can think of, you may well want to trust a particular DHCPv6 server to configure a link address on an interface, plus maybe some hints about which name servers or time servers to use to set up an initial connection, but not to set a policy for which address ranges and hence interfaces to select for which traffic. Even receiving policy information over one active interface may not be considered a reasonable risk by some e.g. if a second interface is brought up later (e.g. a tunnel), and (some of) the old policy information from the first interface is not flushed because that first interface is still up and the second interface does not provide a policy update.

In a corporate environment, it may well be desirable to receive policy updates on multiple interfaces without having to explicitly configure this, because all updates ultimately have been derived from a trusted AS source.

Therefore I think the risk is more closely related to the consistency and provenance of the DHCPv6 derived address selection policy information i.e. whether the device is receiving the option from more than one Autonomous System simultaneously, or from an AS source that is not trusted.

I'd be happy if the draft contained a warning of the risk, without getting into details of how to mitigate the risk in implementation.

  

    
2) Suggest splitting transport of policy/configuration information from actual use of the policy/configuration information by the end node. I'm thinking of how routers may have multiple sources of routing information (derived from various sources: static, RIPng, OSPFv3) but they may only install subsets of the total known information into the single active forwarding table using local policy configuration concepts such as Administrative Distance and locally defined route filters.
    

  

  

Do you suggest splitting them into different documents, or just defining the transport information format and leaving others to implementation dependent ?
I do not see much value in just dividing this into two documents. It just makes it troublesome to understand this mechanism.

Regarding the latter case,
IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism. If you find the current specification goes beyond recommendation in some points, please tell it to me.

  



I humbly suggest considering which WG is appropriate for defining which
portion of the overall mechanism. There seems to be a very large
overlap with MIF, and one possible way to handle this would be to have
the pure transport of the option defined in your 6man draft (which I
guess could be pretty non-contentious), and defining the use of the
information in the MIF workflow. Another option might be simply to
co-post the draft to the MIF WG.



<snip>





  
I think it is a matter of implementation, and common for several other DHCPv6 options.

It may be helpful for implementors, but this document should not be the right place for this generic issue.

Thanks !

  



Agree. This is off topic for your draft, but maybe someone will take up
the generic challenge in another draft.



<snip>



regards,

RayH




--------------010903090901050204080404--

From brian@innovationslab.net  Fri Feb 24 05:21:50 2012
Return-Path: 
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 1175F21F8748 for ; Fri, 24 Feb 2012 05:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.694
X-Spam-Level: 
X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, 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 igNzhDeU9a6N for ; Fri, 24 Feb 2012 05:21:49 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 818E721F86EA for ; Fri, 24 Feb 2012 05:21:49 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 674168812B; Fri, 24 Feb 2012 05:21:49 -0800 (PST)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 20866130009; Fri, 24 Feb 2012 05:21:49 -0800 (PST)
Message-ID: <4F478EEC.1020203@innovationslab.net>
Date: Fri, 24 Feb 2012 08:21:48 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Consensus call on adopting: draft-hsingh-6man-enhance-dad
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <6man-chairs@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 13:21:50 -0000

All,
      This is a consensus call on adopting:

      Filename: draft-hsingh-6man-enhanced-dad
      Revision: 04
      Title:    Enhanced Duplicate Address Detection

as a 6MAN WG document.  Statements of support or opposition should be 
sent to the mailing list.  This last call will end on March 9, 2012.

Regards,
Brian, Bob, & Ole

From dart@es.net  Fri Feb 24 11:01:43 2012
Return-Path: 
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 0758F21F87D7 for ; Fri, 24 Feb 2012 11:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FIsU5j-BjtSU for ; Fri, 24 Feb 2012 11:01:42 -0800 (PST)
Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84A21F86E2 for ; Fri, 24 Feb 2012 11:01:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=cZ9kTdc6cNhPHPKGZwgJH6tFDE3u3Le4NFBLzJo0MHk=; b=ZAnkUMbT1LsK+MzZ9P+VoKAbrYYCyOJl+HRPXQ4HZ7WeTlaWk4JabNK92KeNl7ErL62o +XP1Ybs4dG7AfTtrfuGmZ6ihKdrJNGu811Om59YZWrqYqNW6ZUNxGbFz8sexSSg21dn4 CcF/1Kf7BQcTyjSI4pMyVYLkIOKia/TfESI= 
Received: from e4-ce-8f-6-ab-c8.dhcp.lbnl.us (e4-ce-8f-6-ab-c8.dhcp.lbnl.us [198.128.197.62]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id q1OJ1egd021472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2012 11:01:41 -0800
Message-ID: <4F47DE94.9060406@es.net>
Date: Fri, 24 Feb 2012 11:01:40 -0800
From: Eli Dart 
Organization: Energy Sciences Network
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Brian Haberman 
Subject: Re: Consensus call on adopting: draft-hsingh-6man-enhance-dad
References: <4F478EEC.1020203@innovationslab.net>
In-Reply-To: <4F478EEC.1020203@innovationslab.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-02-24_06:2012-02-24, 2012-02-24, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202240176
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dart@es.net
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 19:01:43 -0000

I support the adoption of draft-hsingh-6man-enhanced-dad as a 6MAN WG 
document.

Thanks,

		--eli


On 2/24/12 5:21 AM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Filename: draft-hsingh-6man-enhanced-dad
> Revision: 04
> Title: Enhanced Duplicate Address Detection
>
> as a 6MAN WG document. Statements of support or opposition should be
> sent to the mailing list. This last call will end on March 9, 2012.
>
> Regards,
> Brian, Bob, & Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Eli Dart                                            NOC: (510) 486-7600
ESnet Network Engineering Group (AS293)                  (800) 333-7638
Lawrence Berkeley National Laboratory
PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3

From randy@psg.com  Sat Feb 25 04:11:52 2012
Return-Path: 
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 D27C921F8656 for ; Sat, 25 Feb 2012 04:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.193
X-Spam-Level: 
X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 qiywEVVIDx8Y for ; Sat, 25 Feb 2012 04:11:52 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4B19421F8655 for ; Sat, 25 Feb 2012 04:11:52 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S1GTW-000CQk-Bv; Sat, 25 Feb 2012 12:11:42 +0000
Date: Sat, 25 Feb 2012 17:41:39 +0530
Message-ID: 
From: Randy Bush 
To: Brian Haberman 
Subject: Re: Consensus call on adopting: draft-hsingh-6man-enhance-dad
In-Reply-To: <4F478EEC.1020203@innovationslab.net>
References: <4F478EEC.1020203@innovationslab.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2012 12:11:53 -0000

i scanned draft-hsingh-6man-enhanced-dad-04.txt and it certainly looks
like 6man fodder to me.  i would have suggested v6ops until i got to
section 3, which proposes protocol change.

randy

From kauer@biplane.com.au  Mon Feb 27 06:09:50 2012
Return-Path: 
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 0DDF821F856A for ; Mon, 27 Feb 2012 06:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.003
X-Spam-Level: *
X-Spam-Status: No, score=1.003 tagged_above=-999 required=5 tests=[AWL=-0.802,  BAYES_40=-0.185, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39]
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 SMtE8ZeYqcSm for ; Mon, 27 Feb 2012 06:09:48 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52821F85BE for ; Mon, 27 Feb 2012 06:09:46 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoEACWLS0+WZX+7/2dsb2JhbAAMNoUnrXKDMYEzAl8TrWKRco0JeQMDAwKFVAoBHoIVgRYEoFeHaA
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 28 Feb 2012 00:39:45 +1030
Subject: RFC5952 - actually a standard?!?
From: Karl Auer 
To: IETF IPv6 
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yvxZRn/gwJbK6lK7tM4B"
Date: Tue, 28 Feb 2012 01:09:42 +1100
Message-ID: <1330351782.2584.98.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 14:09:50 -0000

--=-yvxZRn/gwJbK6lK7tM4B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is a silly question I know but I have to ask - is RFC 5952 "A
Recommendation for IPv6 Address Text Representation" a standard that
people are expected to follow?

This from the abstract:

  "It is expected that the canonical format
   will be followed by humans and systems when representing IPv6
   addresses as text, but all implementations must accept and be able to
   handle any legitimate RFC 4291 format."

They are pretty much common sense (except for 4.2.2), and probably
represent common practice anyway, but I'd still like to know whether
people are consciously following these guidelines.

Regards, K.

--=20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

--=-yvxZRn/gwJbK6lK7tM4B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iF4EABEIAAYFAk9Ljp4ACgkQFpl7eE7uYBfj5QD+PYvP9cLzrz7RMbM8QKgeXhjg
ArZFbEfLYgduc2K0jHYBAJ23MNI1yhlhbBTwEDpThcf6iLw2d4pCkg8UeAbyyatQ
=PQjT
-----END PGP SIGNATURE-----

--=-yvxZRn/gwJbK6lK7tM4B--


From nordmark@acm.org  Mon Feb 27 09:13:57 2012
Return-Path: 
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 ADB5621F86BB for ; Mon, 27 Feb 2012 09:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.169
X-Spam-Level: 
X-Spam-Status: No, score=-104.169 tagged_above=-999 required=5 tests=[AWL=-1.570, BAYES_00=-2.599, 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 JxWYaSuFpUQj for ; Mon, 27 Feb 2012 09:13:57 -0800 (PST)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4105221F867E for ; Mon, 27 Feb 2012 09:13:57 -0800 (PST)
Received: from Erik-Nordmarks-MacBook-Pro-2.local (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q1RHDp11021957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 09:13:52 -0800
Message-ID: <4F4BB9D1.9020909@acm.org>
Date: Mon, 27 Feb 2012 09:13:53 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Brian Haberman 
Subject: Re: Consensus call on adopting: draft-hsingh-6man-enhance-dad
References: <4F478EEC.1020203@innovationslab.net>
In-Reply-To: <4F478EEC.1020203@innovationslab.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 17:13:57 -0000

On 2/24/12 5:21 AM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Filename: draft-hsingh-6man-enhanced-dad
> Revision: 04
> Title: Enhanced Duplicate Address Detection
>
> as a 6MAN WG document. Statements of support or opposition should be
> sent to the mailing list. This last call will end on March 9, 2012.

I support this as a WG document.

At first I was going to suggest a slightly different title ("Adding 
loopback tolerance to DAD" or something like it), but then I realized 
there is additional DAD behavioral changes in section 5 which are in 
addition to making DAD tolerant to loopback.

Regards,
     Erik


From brian.e.carpenter@gmail.com  Mon Feb 27 12:29:02 2012
Return-Path: 
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 4733C21F87CB for ; Mon, 27 Feb 2012 12:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.743
X-Spam-Level: 
X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, 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 J-U5B87volID for ; Mon, 27 Feb 2012 12:29:01 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD49321F8794 for ; Mon, 27 Feb 2012 12:29:01 -0800 (PST)
Received: by iagf6 with SMTP id f6so8211367iag.31 for ; Mon, 27 Feb 2012 12:29:01 -0800 (PST)
Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.195.231 as permitted sender) client-ip=10.50.195.231; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.195.231 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com
Received: from mr.google.com ([10.50.195.231]) by 10.50.195.231 with SMTP id ih7mr234704igc.45.1330374541529 (num_hops = 1); Mon, 27 Feb 2012 12:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TU3fOJ9oZhu1Nchb7ia5CAXSYMP/V0YHe+V/xf5zHio=; b=Ee8MFD7Y6Bcd04jxF5wPuBARGXsp2gMxEf7OEGQIyNjL8eF85pnUqfvyRffFSPw19m TAVWmIGmwcYQWy4awwbJE/B+u/z4sO7zu0uMH5c/ZyN0TlcjUbJ4dpEirBvR9HAKhP5g HjU9/8pPY/x/x5xl++8Mf2pSYOMw9OjOx0G4E=
Received: by 10.50.195.231 with SMTP id ih7mr207186igc.45.1330374541472; Mon, 27 Feb 2012 12:29:01 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id b6sm11436057igj.7.2012.02.27.12.28.58 (version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 12:29:00 -0800 (PST)
Message-ID: <4F4BE788.70300@gmail.com>
Date: Tue, 28 Feb 2012 09:28:56 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Karl Auer 
Subject: Re: RFC5952 - actually a standard?!?
References: <1330351782.2584.98.camel@karl>
In-Reply-To: <1330351782.2584.98.camel@karl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 20:29:02 -0000

Yes, according to the RFC index it is a Proposed Standard.

You can always check this at the RFC Editor site, e.g. from
the search page: http://www.rfc-editor.org/rfcsearch.html

Whether people are following the standard is of course another
question entirely.

Regards
   Brian Carpenter

On 2012-02-28 03:09, Karl Auer wrote:
> This is a silly question I know but I have to ask - is RFC 5952 "A
> Recommendation for IPv6 Address Text Representation" a standard that
> people are expected to follow?
> 
> This from the abstract:
> 
>   "It is expected that the canonical format
>    will be followed by humans and systems when representing IPv6
>    addresses as text, but all implementations must accept and be able to
>    handle any legitimate RFC 4291 format."
> 
> They are pretty much common sense (except for 4.2.2), and probably
> represent common practice anyway, but I'd still like to know whether
> people are consciously following these guidelines.
> 
> Regards, K.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From brian@innovationslab.net  Mon Feb 27 13:08:30 2012
Return-Path: 
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 23B4A21E802F for ; Mon, 27 Feb 2012 13:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.686
X-Spam-Level: 
X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, 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 i2TPXquJbeD8 for ; Mon, 27 Feb 2012 13:08:29 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7137B21E801A for ; Mon, 27 Feb 2012 13:08:29 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4746B881CF for ; Mon, 27 Feb 2012 13:08:29 -0800 (PST)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F422F130009 for ; Mon, 27 Feb 2012 13:08:28 -0800 (PST)
Message-ID: <4F4BF0CA.8030701@innovationslab.net>
Date: Mon, 27 Feb 2012 16:08:26 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-uri-zoneid-00.txt
References: <20120221091434.26970.33378.idtracker@ietfa.amsl.com> <4F43FAE9.8040401@gmail.com>
In-Reply-To: <4F43FAE9.8040401@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 21:08:30 -0000

Brian,
      Hi chatted with an APP AD and it was suggested to request a review 
of the draft by the URI review team.  Can you send a pointer to this 
draft to the URI review mailing list (uri-review@ietf.org) and ask for 
feedback?

Regards,
Brian

On 2/21/12 3:13 PM, Brian E Carpenter wrote:
> Hi,
>
> All comments have been incorporated in this version. Should we seek comments
> from the URI community before asking for a WGLC?
>
> Regards
>     Brian Carpenter
>
> On 2012-02-21 22:14, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>>
>> 	Title           : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers
>> 	Author(s)       : Brian Carpenter
>>                            Robert M. Hinden
>> 	Filename        : draft-ietf-6man-uri-zoneid-00.txt
>> 	Pages           : 7
>> 	Date            : 2012-02-17
>>
>>     This document describes how the Zone Identifier of an IPv6 scoped
>>     address can be represented in a Uniform Resource Identifier that
>>     includes a literal IPv6 address.  It updates RFC 3986 and RFC 4007.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-6man-uri-zoneid-00.txt
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From brian.e.carpenter@gmail.com  Mon Feb 27 13:22:21 2012
Return-Path: 
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 C131221E8046 for ; Mon, 27 Feb 2012 13:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.435
X-Spam-Level: 
X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 L0n53mDUEdIc for ; Mon, 27 Feb 2012 13:22:21 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 139F921E8044 for ; Mon, 27 Feb 2012 13:22:21 -0800 (PST)
Received: by ggnp2 with SMTP id p2so640427ggn.31 for ; Mon, 27 Feb 2012 13:22:18 -0800 (PST)
Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.12.170 as permitted sender) client-ip=10.50.12.170; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.12.170 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com
Received: from mr.google.com ([10.50.12.170]) by 10.50.12.170 with SMTP id z10mr359359igb.55.1330377738346 (num_hops = 1); Mon, 27 Feb 2012 13:22:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Hku0pKymclwNIilJg5E9FfBzgtjU3F/iIwRtXxcWLEU=; b=RjcPfp//CN1G51HzDus2btX4RLgg8S8hSkaDsHqRBFCOTUlMczCsto97QrD+V4Nl4v 1y+wZ0B0ECeGHa/Us8vJcWJqtVtDbD7+oghlcLR4j+P9BI8aCfm5g+SRVapLyAhwhUnH 1jXTbwZQZfAgF97gJKgZ2iVJYOvM5XCn6WotA=
Received: by 10.50.12.170 with SMTP id z10mr315987igb.55.1330377738288; Mon, 27 Feb 2012 13:22:18 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id hz3sm6161563igc.6.2012.02.27.13.22.15 (version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 13:22:17 -0800 (PST)
Message-ID: <4F4BF405.5060100@gmail.com>
Date: Tue, 28 Feb 2012 10:22:13 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian Haberman 
Subject: Re: I-D Action: draft-ietf-6man-uri-zoneid-00.txt
References: <20120221091434.26970.33378.idtracker@ietfa.amsl.com>	<4F43FAE9.8040401@gmail.com> <4F4BF0CA.8030701@innovationslab.net>
In-Reply-To: <4F4BF0CA.8030701@innovationslab.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 21:22:21 -0000

Done!

Regards
   Brian Carpenter

On 2012-02-28 10:08, Brian Haberman wrote:
> Brian,
>      Hi chatted with an APP AD and it was suggested to request a review
> of the draft by the URI review team.  Can you send a pointer to this
> draft to the URI review mailing list (uri-review@ietf.org) and ask for
> feedback?
> 
> Regards,
> Brian
> 
> On 2/21/12 3:13 PM, Brian E Carpenter wrote:
>> Hi,
>>
>> All comments have been incorporated in this version. Should we seek
>> comments
>> from the URI community before asking for a WGLC?
>>
>> Regards
>>     Brian Carpenter
>>
>> On 2012-02-21 22:14, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the IPv6 Maintenance
>>> Working Group of the IETF.
>>>
>>>     Title           : Representing IPv6 Zone Identifiers in Uniform
>>> Resource Identifiers
>>>     Author(s)       : Brian Carpenter
>>>                            Robert M. Hinden
>>>     Filename        : draft-ietf-6man-uri-zoneid-00.txt
>>>     Pages           : 7
>>>     Date            : 2012-02-17
>>>
>>>     This document describes how the Zone Identifier of an IPv6 scoped
>>>     address can be represented in a Uniform Resource Identifier that
>>>     includes a literal IPv6 address.  It updates RFC 3986 and RFC 4007.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-uri-zoneid-00.txt
>>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
> 

From jeroen@unfix.org  Tue Feb 28 05:12:57 2012
Return-Path: 
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 7B45121F861F for ; Tue, 28 Feb 2012 05:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3TYESRsvQXAb for ; Tue, 28 Feb 2012 05:12:56 -0800 (PST)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9021F85E6 for ; Tue, 28 Feb 2012 05:12:52 -0800 (PST)
Received: from yomi.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id E68F6801C2A2 for ; Tue, 28 Feb 2012 14:12:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1330434769; bh=9CwJHDAFsysXBmCce+fmvTWv8Qk5CLc678pBgWYAgAU=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=l/eoSki2CJFRdymoW1cFerq5F1jpMc4kIfg+hwhO9GTIKSlYNTC6hHeKuWcoVwLlq c94KJDQkwPO3bsVCSOb+Qo7vegOzDWnTfh+xGHdoaihUZfwW1LE+jy7PqjGAEG9Glf jTKPe8qlw0S7XOHx/DOGZiq6eSDDBFgIfvyMTliSjUY5DT3QXVZD7LOxeWjQmuC0Me y8OndnJ2PrgbrnAfrcZlmNXyBeRlWabR93Wb5kowqJcQCjBaxvWRQeDnzAWaBcbfpP TTfr6jis3apDouBDA2QbU/nZkGUDGd6q8ihL/kbcZlo/iEXEAPHBCtHSm8zLvHUAx7 F8j+aIdEiT2Og==
Message-ID: <4F4CD2CB.9010604@unfix.org>
Date: Tue, 28 Feb 2012 14:12:43 +0100
From: Jeroen Massar 
Organization: Unfix
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: MLDv1 still in the wild?
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 13:12:57 -0000

Hi,

I was wondering, if anybody had a rough idea how many MLDv1-only
listeners are still out there in the wild. My assumption by now is that
current code out there (thus not stuff that has been up and running and
never upgraded for the last 5 years orso ;) all supports MLDv2... or is
there a major platform which does not do MLDv2?

Greets,
 Jeroen

From stig@venaas.com  Tue Feb 28 11:08:56 2012
Return-Path: 
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 9A38F21F86C7 for ; Tue, 28 Feb 2012 11:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 jEPwvpxPrnu4 for ; Tue, 28 Feb 2012 11:08:56 -0800 (PST)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E819221F866C for ; Tue, 28 Feb 2012 11:08:55 -0800 (PST)
Received: from [10.33.12.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5FE707FF4; Tue, 28 Feb 2012 20:08:53 +0100 (CET)
Message-ID: <4F4D2643.6050200@venaas.com>
Date: Tue, 28 Feb 2012 11:08:51 -0800
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jeroen Massar 
Subject: Re: MLDv1 still in the wild?
References: <4F4CD2CB.9010604@unfix.org>
In-Reply-To: <4F4CD2CB.9010604@unfix.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 19:08:56 -0000

On 2/28/2012 5:12 AM, Jeroen Massar wrote:
> Hi,
>
> I was wondering, if anybody had a rough idea how many MLDv1-only
> listeners are still out there in the wild. My assumption by now is that
> current code out there (thus not stuff that has been up and running and
> never upgraded for the last 5 years orso ;) all supports MLDv2... or is
> there a major platform which does not do MLDv2?

Not sure, but Apple only just now started supporting SSM, and I think
perhaps it was all MLDv1 until then. So there might be a lot of MLDv1
Apples out there still.

Stig

>
> Greets,
>   Jeroen
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From simon.perreault@viagenie.ca  Wed Feb 29 06:38:17 2012
Return-Path: 
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 B7BC921F8638 for ; Wed, 29 Feb 2012 06:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 cYV8CaGsTiZy for ; Wed, 29 Feb 2012 06:38:17 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2315F21F862A for ; Wed, 29 Feb 2012 06:38:17 -0800 (PST)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:ed18:7ce1:b71d:607c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8651620E80 for ; Wed, 29 Feb 2012 09:38:16 -0500 (EST)
Message-ID: <4F4E3857.6000403@viagenie.ca>
Date: Wed, 29 Feb 2012 09:38:15 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: MLDv1 still in the wild?
References: <4F4CD2CB.9010604@unfix.org>
In-Reply-To: <4F4CD2CB.9010604@unfix.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 14:38:17 -0000

On 2012-02-28 08:12, Jeroen Massar wrote:
> I was wondering, if anybody had a rough idea how many MLDv1-only
> listeners are still out there in the wild. My assumption by now is that
> current code out there (thus not stuff that has been up and running and
> never upgraded for the last 5 years orso ;) all supports MLDv2... or is
> there a major platform which does not do MLDv2?

On the open-source side, I know of OpenBSD and NetBSD which are still 
MLDv1 only.

FreeBSD and Linux have MLDv2.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From wwwrun@rfc-editor.org  Wed Feb 29 11:19:55 2012
Return-Path: 
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 1858F21F86BD; Wed, 29 Feb 2012 11:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 i4XKjvNGdXkg; Wed, 29 Feb 2012 11:19:54 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A05BE21F86B1; Wed, 29 Feb 2012 11:19:54 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 8F58C72E114; Wed, 29 Feb 2012 10:59:21 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 6547 on RFC 3627 to Historic Status
From: rfc-editor@rfc-editor.org
Message-Id: <20120229185925.8F58C72E114@rfc-editor.org>
Date: Wed, 29 Feb 2012 10:59:21 -0800 (PST)
Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 19:19:55 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6547

        Title:      RFC 3627 to Historic Status 
        Author:     W. George
        Status:     Informational
        Stream:     IETF
        Date:       February 2012
        Mailbox:    wesley.george@twcable.com
        Pages:      3
        Characters: 4917
        Obsoletes:  RFC3627
        Updates:    RFC6164

        I-D Tag:    draft-ietf-6man-3627-historic-01.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6547.txt

This document moves "Use of /127 Prefix Length Between Routers
Considered Harmful" (RFC 3627) to Historic status to reflect the
updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter-
Router Links" (RFC 6164).  A Standards Track document supersedes an
informational document; therefore, guidance provided in RFC 6164 is
to be followed when the two documents are in conflict.  This document
links the two RFCs so that the IETF's updated guidance on this topic
is clearer.  This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the IPv6 Maintenance Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From brian@innovationslab.net  Wed Feb 29 12:34:15 2012
Return-Path: 
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 6A88C21E803C for ; Wed, 29 Feb 2012 12:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.806
X-Spam-Level: 
X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, 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 dzjq6nRRYM9k for ; Wed, 29 Feb 2012 12:34:15 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id F3B9021E8017 for ; Wed, 29 Feb 2012 12:34:14 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E414688170; Wed, 29 Feb 2012 12:34:14 -0800 (PST)
Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7D8A0130015; Wed, 29 Feb 2012 12:34:14 -0800 (PST)
Message-ID: <4F4E8BC5.6030109@innovationslab.net>
Date: Wed, 29 Feb 2012 15:34:13 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: IPv6 WG Mailing List 
Subject: Request for review: draft-ietf-mboned-64-multicast-address-format
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, mboned-chairs@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 20:34:15 -0000

All,
     The MBoneD WG has just completed a WG Last Call on a document
defining a method to embed IPv4 multicast addresses in IPv6 multicast
addresses.  It should be noted that this draft updated RFC 4291, the
IPv6 Addressing Architecture.  Please review this draft and provide
comments by March 14, 2012.


  Title           : IPv4-Embedded IPv6 Multicast Address Format
  Author(s)       : Mohamed Boucadair
                    Jacni Qin
                    Yiu L. Lee
                    Stig Venaas
                    Xing Li
                    Mingwei Xu
  Filename        : draft-ietf-mboned-64-multicast-address-format-01.txt
  Pages           : 12
  Date            : 2012-02-29

Regards,
Brian

From fgont@si6networks.com  Wed Feb 29 12:43:26 2012
Return-Path: 
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 75A3821E8089 for ; Wed, 29 Feb 2012 12:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 D6WO0wpHs5QU for ; Wed, 29 Feb 2012 12:43:25 -0800 (PST)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BA18621E807A for ; Wed, 29 Feb 2012 12:43:25 -0800 (PST)
Received: from [2001:5c0:1000:a::293] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S2qMn-0006Gu-Ch; Wed, 29 Feb 2012 21:43:19 +0100
Message-ID: <4F4E8DD0.2040802@si6networks.com>
Date: Wed, 29 Feb 2012 17:42:56 -0300
From: Fernando Gont 
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Simon Perreault 
Subject: Re: MLDv1 still in the wild?
References: <4F4CD2CB.9010604@unfix.org> <4F4E3857.6000403@viagenie.ca>
In-Reply-To: <4F4E3857.6000403@viagenie.ca>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 20:43:26 -0000

On 02/29/2012 11:38 AM, Simon Perreault wrote:
> On 2012-02-28 08:12, Jeroen Massar wrote:
>> I was wondering, if anybody had a rough idea how many MLDv1-only
>> listeners are still out there in the wild. My assumption by now is that
>> current code out there (thus not stuff that has been up and running and
>> never upgraded for the last 5 years orso ;) all supports MLDv2... or is
>> there a major platform which does not do MLDv2?
> 
> On the open-source side, I know of OpenBSD and NetBSD which are still
> MLDv1 only.

Even if they implemented MLDv2, I'd argue that the default should
probably be MLDv1 rather than MLDv2: unless non-local multicast is
employed, MLDv2 is unnecessarily complex if it's just for the purpose of
ND and the like.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




From sarikaya2012@gmail.com  Wed Feb 29 13:17:44 2012
Return-Path: 
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 2012821F87B3 for ; Wed, 29 Feb 2012 13:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level: 
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 a9Z5mpmK0cN8 for ; Wed, 29 Feb 2012 13:17:43 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40C0D21F8797 for ; Wed, 29 Feb 2012 13:17:43 -0800 (PST)
Received: by yenm5 with SMTP id m5so1856408yen.31 for ; Wed, 29 Feb 2012 13:17:42 -0800 (PST)
Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.201.232 as permitted sender) client-ip=10.236.201.232; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.201.232 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com
Received: from mr.google.com ([10.236.201.232]) by 10.236.201.232 with SMTP id b68mr3028135yho.129.1330550262949 (num_hops = 1); Wed, 29 Feb 2012 13:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EEyYL6mxhFknlM6P+6m3DVxtjL1XANEjQ9caXuOKKKs=; b=BbfCO+IunJ6kP3fNdLaD8IwzyREZg+HoK25Y4J42tGuTMN8NAgGafHH6CFl+c45axU ZowGsy/TWXanEU/vmRdxt8ZnFiiO71FMBmcK+xUlaYDFpTJ/on7+FtAXuTzrmWPOsPe5 H1zjDgRebwzjLpF/UyuqPzB7zwMRfW/uh6UHw=
MIME-Version: 1.0
Received: by 10.236.201.232 with SMTP id b68mr2385939yho.129.1330550262838; Wed, 29 Feb 2012 13:17:42 -0800 (PST)
Received: by 10.236.9.73 with HTTP; Wed, 29 Feb 2012 13:17:42 -0800 (PST)
In-Reply-To: <4F4E8DD0.2040802@si6networks.com>
References: <4F4CD2CB.9010604@unfix.org> <4F4E3857.6000403@viagenie.ca> <4F4E8DD0.2040802@si6networks.com>
Date: Wed, 29 Feb 2012 15:17:42 -0600
Message-ID: 
Subject: Re: MLDv1 still in the wild?
From: Behcet Sarikaya 
To: Fernando Gont 
Content-Type: text/plain; charset=ISO-8859-1
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 21:17:44 -0000

On Wed, Feb 29, 2012 at 2:42 PM, Fernando Gont  wrote:
> On 02/29/2012 11:38 AM, Simon Perreault wrote:
>> On 2012-02-28 08:12, Jeroen Massar wrote:
>>> I was wondering, if anybody had a rough idea how many MLDv1-only
>>> listeners are still out there in the wild. My assumption by now is that
>>> current code out there (thus not stuff that has been up and running and
>>> never upgraded for the last 5 years orso ;) all supports MLDv2... or is
>>> there a major platform which does not do MLDv2?
>>
>> On the open-source side, I know of OpenBSD and NetBSD which are still
>> MLDv1 only.
>
> Even if they implemented MLDv2, I'd argue that the default should
> probably be MLDv1 rather than MLDv2: unless non-local multicast is
> employed, MLDv2 is unnecessarily complex if it's just for the purpose of
> ND and the like.

This is true.

However, RFC 5790, on Lightweight IGMP/MLD makes it easy to support
SSM. I think there is open source support for 5790 somewhere.

Behcet

From stig@venaas.com  Wed Feb 29 14:10:33 2012
Return-Path: 
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 F175321F86AB for ; Wed, 29 Feb 2012 14:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tWBh2IMMnnKw for ; Wed, 29 Feb 2012 14:10:32 -0800 (PST)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5821F86A7 for ; Wed, 29 Feb 2012 14:10:32 -0800 (PST)
Received: from [10.33.12.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6EDFB8001; Wed, 29 Feb 2012 23:10:30 +0100 (CET)
Message-ID: <4F4EA253.4000408@venaas.com>
Date: Wed, 29 Feb 2012 14:10:27 -0800
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: sarikaya@ieee.org
Subject: Re: MLDv1 still in the wild?
References: <4F4CD2CB.9010604@unfix.org> <4F4E3857.6000403@viagenie.ca> <4F4E8DD0.2040802@si6networks.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org, Behcet Sarikaya 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 22:10:33 -0000

On 2/29/2012 1:17 PM, Behcet Sarikaya wrote:
> On Wed, Feb 29, 2012 at 2:42 PM, Fernando Gont  wrote:
>> On 02/29/2012 11:38 AM, Simon Perreault wrote:
>>> On 2012-02-28 08:12, Jeroen Massar wrote:
>>>> I was wondering, if anybody had a rough idea how many MLDv1-only
>>>> listeners are still out there in the wild. My assumption by now is that
>>>> current code out there (thus not stuff that has been up and running and
>>>> never upgraded for the last 5 years orso ;) all supports MLDv2... or is
>>>> there a major platform which does not do MLDv2?
>>>
>>> On the open-source side, I know of OpenBSD and NetBSD which are still
>>> MLDv1 only.
>>
>> Even if they implemented MLDv2, I'd argue that the default should
>> probably be MLDv1 rather than MLDv2: unless non-local multicast is
>> employed, MLDv2 is unnecessarily complex if it's just for the purpose of
>> ND and the like.
>
> This is true.

I think the main reason OpenBSD and NetBSD don't support SSM is
Apple's IPR claim. Without SSM support, there is little reason to
support MLDv2.

I'm a bit curious about the reason for the question. At least MLDv2
routers are supposed to support MLDv1 compatibility mode.

> However, RFC 5790, on Lightweight IGMP/MLD makes it easy to support
> SSM. I think there is open source support for 5790 somewhere.

What it does is basically removing exclude mode for a non-empty
source list. It is still a lot of work compared to IGMPv2/MLDv1.
Apart from hosts in general, I can imagine a lot of special purpose
devices that never needs SSM to only implement MLDv1.

Stig

> Behcet
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From dthaler@microsoft.com  Wed Feb 29 18:21:10 2012
Return-Path: 
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 B941321E8014 for ; Wed, 29 Feb 2012 18:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.869
X-Spam-Level: 
X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 wM-7HEM254PU for ; Wed, 29 Feb 2012 18:21:10 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6904E21E803A for ; Wed, 29 Feb 2012 18:21:09 -0800 (PST)
Received: from mail68-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Mar 2012 02:21:09 +0000
Received: from mail68-ch1 (localhost [127.0.0.1])	by mail68-ch1-R.bigfish.com (Postfix) with ESMTP id D4DAD4001C1; Thu,  1 Mar 2012 02:21:08 +0000 (UTC)
X-SpamScore: -42
X-BigFish: VS-42(zz9371I1102K542M1432Ndf7Ozz1202hzz1033ILz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail68-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail68-ch1 (localhost.localdomain [127.0.0.1]) by mail68-ch1 (MessageSwitch) id 1330568467808218_32643; Thu,  1 Mar 2012 02:21:07 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252])	by mail68-ch1.bigfish.com (Postfix) with ESMTP id BF226460045;	Thu,  1 Mar 2012 02:21:07 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Mar 2012 02:21:07 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 1 Mar 2012 02:20:58 +0000
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.17]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Wed, 29 Feb 2012 18:20:58 -0800
From: Dave Thaler 
To: Arifumi Matsumoto , Brian E Carpenter 
Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Topic: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Index: AQHM61TBqpyDXQSHVE+cgiqvxUSI2pZMJnCAgAiknaA=
Date: Thu, 1 Mar 2012 02:20:58 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <4EB3F3D6.4090302@innovationslab.net>  <4EEA3D20.7020603@innovationslab.net>  <4EEA5793.8080800@gmail.com>  <4EEA7AF8.2090508@gmail.com>  <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>  <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net>
In-Reply-To: <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net>
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" , Brian Haberman , Bob Hinden 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Mar 2012 02:21:10 -0000

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:arifumi@nttv6.net]
> Sent: Thursday, February 23, 2012 10:14 PM
> To: Brian E Carpenter
> Cc: Dave Thaler; Chris Grundemann; ipv6@ietf.org; Brian Haberman; Bob
> Hinden
> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
>=20
> Dave,
>=20
> in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the resp=
onse to
> this issue of ULA scope.
>=20
> 10.6.  Configuring ULA Preference
> ...
>    Since ULAs are defined to have a /48 site prefix, an implementation
>    might choose to add such a row automatically on a machine with a ULA.
>=20
>    It is also worth noting that ULAs are assigned global scope.  As
>    such, the existence of one or more rows in the prefix policy table is
>    important so that source address selection does not choose a ULA
>    purely based on longest match:
>=20
>    Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
>    Destination Address List: ff00:1
>    Result: 2001:db8:1::1 (prefer matching label)
>=20
>=20
> IMO, this implicit specification causes several problems.
>=20
> First of all, if you leave it to implementation, this creates an interope=
rability
> problem. In the sense that a site administrator, an application developer=
, a
> network designer, have to take care of the nodes with different address
> selection behavior.

Are you arguing it should be mandatory, not optional?  (I'm guessing so bas=
ed
on the previous discussion of "macros" in the table.)

But still, you have to take care of nodes with different address selection =
behavior
anyway if you allow heterogeneous hosts, since you'll have
a) hosts that don't do RFC 3484
b) hosts that do RFC 3484
c) hosts that do 3484bis

And even within a category above, the IPv4 source address selection behavio=
r
will vary since that's not specified.

At best you can argue to minimize the problem as much as possible, but
you can't make it go away.
=20
> Second,
> when a user configures his policy table, the configured table is overwrit=
ten by
> this implementation dependent policy injection behavior ?
> Can the user suppress this behavior of policy injection ?
> This issue should arise also when a policy distributing mechanism is read=
y.

Good questions.  Do you have suggested answers to those questions?
I might throw out a strawman of:

Any automatic rows added by the implementation as a result of address
acquisition MUST NOT override a row for the same prefix configured
via other means.   That is, rows can be added but never updated
automatically.   An implementation SHOULD provide a means for
an administrator to disable automatic row additions.

-Dave