From nobody Thu Jul 3 07:56:15 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6E51A0162 for ; Thu, 3 Jul 2014 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08C_ZayYGHPW for ; Thu, 3 Jul 2014 07:56:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59241A00F8 for <6man@ietf.org>; Thu, 3 Jul 2014 07:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2197; q=dns/txt; s=iport; t=1404399367; x=1405608967; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=/uwVgJKDsF94XOweD1+7MkpHdfAOtXH56CoX+09EbMc=; b=TNm652VxyVI2Zxbne9vnitOLRtIPDKyWyxvB1+HL0+2B1OFmN7TmF2l1 cFaHBIhLL7GmhV4RmvaXNZYMMiuQAi556PdsfvretOHWP7ny0l4Lf/Ofx PjAvi4iSbPET9N8jBSE5OJQvAyf/emoT+1HY52UBQ57hdetcMiLgL3xI2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAJ9utVOtJA2L/2dsb2JhbABagw1SWqswDAECAQEBBQECbAGZZoEKFnWEAwEBAQMBOj0HCwIBGQMBAh8QMhsCCAIEEwmIMQgNySEXhXCJP4MngRYFmm2BSJJCggGBQmyBRA X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="337525031" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2014 14:56:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s63Eu58c030290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Thu, 3 Jul 2014 14:56:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:56:05 -0500 From: "Stefano Previdi (sprevidi)" To: 6MAN <6man@ietf.org> Subject: Fwd: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt Thread-Topic: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt Thread-Index: AQHPlsVPZVl9C4Wq3k2v4OyZldAypg== Date: Thu, 3 Jul 2014 14:56:04 +0000 Message-ID: <589E8AA0-B5D5-4E04-B339-7CA0DC3B85CF@cisco.com> References: <20140703134709.19452.24677.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.207.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <81CC5A209FBD5D49B0C7402707279A1E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/z0UdVCynKgxxILjwW28nIQRvQAk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:56:12 -0000 Begin forwarded message: > From: > Subject: New Version Notification for draft-vyncke-6man-segment-routing-s= ecurity-00.txt > Date: July 3, 2014 3:47:09 PM GMT+02:00 > To: Eric Vyncke , Ida Leung = , Brian Field , Stefano Previdi , Eric Vyncke , Stefano Previdi , Brian Field , Ida Leung >=20 >=20 > A new version of I-D, draft-vyncke-6man-segment-routing-security-00.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-vyncke-6man-segment-routing-security > Revision: 00 > Title: IPv6 Segment Routing Header (SRH) Security Considerations > Document date: 2014-07-03 > Group: Individual Submission > Pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-vyncke-6man-seg= ment-routing-security-00.txt > Status: https://datatracker.ietf.org/doc/draft-vyncke-6man-segmen= t-routing-security/ > Htmlized: http://tools.ietf.org/html/draft-vyncke-6man-segment-rout= ing-security-00 >=20 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending a SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > analyses the security aspects the Segment Routing Extension Header > Type and how it is used by SR capable nodes to deliver a secure > service. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu Jul 3 07:56:20 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD51A0162 for ; Thu, 3 Jul 2014 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgqmfzKfzrLZ for ; Thu, 3 Jul 2014 07:56:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425951A0103 for <6man@ietf.org>; Thu, 3 Jul 2014 07:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2224; q=dns/txt; s=iport; t=1404399374; x=1405608974; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=P1452P6JLmygLQV1+eGrPnVg3gqnuAeGSNJthjWo2vU=; b=dKfBextDrXg6ghSPSGNZghqmbVp6aX59cFTllbKV+Eav1NwNfHkZCd3T wEFbTTLrpDsuXX02+0Jw4Luq4Zv5Qt3uWZYgpR2qshiJCgC5ZZ4J6/4dX j3ZygtuhbC35j3fV90goRYZG6eo7fSa0CsEVldNkWtWW0CT6GwlUatv0+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkKAJNutVOtJA2G/2dsb2JhbABagw1SUwerMAwBAgEBAQUBAmwBmWaBChZ1hAMBAQEDATo9BwsCARkDAQIfEDIbAggCBBMJiDEICAXJIReFcIk/gyeBFgWabYFIkkKCAYFCbIFE X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="58080103" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 03 Jul 2014 14:56:13 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s63EuDJH007527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6man@ietf.org>; Thu, 3 Jul 2014 14:56:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:56:13 -0500 From: "Stefano Previdi (sprevidi)" To: 6MAN <6man@ietf.org> Subject: Fwd: New Version Notification for draft-previdi-6man-segment-routing-header-02.txt Thread-Topic: New Version Notification for draft-previdi-6man-segment-routing-header-02.txt Thread-Index: AQHPlsX72yWpCzKt70OMlz5WTeSFrw== Date: Thu, 3 Jul 2014 14:56:13 +0000 Message-ID: References: <20140703135025.18040.62470.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.207.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <17E11132C40A134F9524A93083505722@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/aVhcxYPJ2BtEoi6NgtvdCeW7Z_o X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:56:16 -0000 Begin forwarded message: > From: > Subject: New Version Notification for draft-previdi-6man-segment-routing-= header-02.txt > Date: July 3, 2014 3:50:25 PM GMT+02:00 > To: Stefano Previdi , Ida Leung , Brian Field , Clarence Filsfils , Stefano Previdi , Ida Leung , Brian Field , Clarence Fil= sfils >=20 >=20 > A new version of I-D, draft-previdi-6man-segment-routing-header-02.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-previdi-6man-segment-routing-header > Revision: 02 > Title: IPv6 Segment Routing Header (SRH) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-previdi-6man-se= gment-routing-header-02.txt > Status: https://datatracker.ietf.org/doc/draft-previdi-6man-segme= nt-routing-header/ > Htmlized: http://tools.ietf.org/html/draft-previdi-6man-segment-rou= ting-header-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-6man-seg= ment-routing-header-02 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending a SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > describes the Segment Routing Extension Header Type and how it is > used by SR capable nodes. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Jul 4 11:15:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4724D1B2DFB; Fri, 4 Jul 2014 11:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyzF5a06FphC; Fri, 4 Jul 2014 11:15:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C01B2E04; Fri, 4 Jul 2014 11:15:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-addr-arch-update-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704181508.25365.55202.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 11:15:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/GrH5TkkAVp8cTPkOzZgsK2dyabI Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:15:09 -0000 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 : Updates to the IPv6 Multicast Addressing Architecture Authors : Mohamed Boucadair Stig Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-06.txt Pages : 9 Date : 2014-07-04 Abstract: This document updates the IPv6 multicast addressing architecture by re-defining the reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 00:24:03 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625ED1A036C for ; Sat, 5 Jul 2014 00:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGAqyGs6otzl for ; Sat, 5 Jul 2014 00:24:00 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 01DA71A036A for <6man@ietf.org>; Sat, 5 Jul 2014 00:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B4E6F871515; Sat, 5 Jul 2014 09:23:58 +0200 (CEST) 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 Tq40ssvwEE9z; Sat, 5 Jul 2014 09:23:58 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 8D509870021; Sat, 5 Jul 2014 09:23:58 +0200 (CEST) Message-ID: <53B7A7FA.9060501@globis.net> Date: Sat, 05 Jul 2014 09:23:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Stefano Previdi (sprevidi)" Subject: Re: Fwd: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt References: <20140703134709.19452.24677.idtracker@ietfa.amsl.com> <589E8AA0-B5D5-4E04-B339-7CA0DC3B85CF@cisco.com> In-Reply-To: <589E8AA0-B5D5-4E04-B339-7CA0DC3B85CF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/9cmJGRiBwbD3GQyuu1GDHVfZweQ Cc: 6MAN <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 07:24:02 -0000 Stefano Previdi (sprevidi) wrote: > Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt >> Date: July 3, 2014 3:47:09 PM GMT+02:00 >> To: Eric Vyncke, Ida Leung, Brian Field, Stefano Previdi, Eric Vyncke, Stefano Previdi, Brian Field, Ida Leung >> >> >> A new version of I-D, draft-vyncke-6man-segment-routing-security-00.txt >> has been successfully submitted by Stefano Previdi and posted to the >> IETF repository. >> >> Name: draft-vyncke-6man-segment-routing-security >> Revision: 00 >> Title: IPv6 Segment Routing Header (SRH) Security Considerations >> Document date: 2014-07-03 >> Group: Individual Submission >> Pages: 11 >> URL: http://www.ietf.org/internet-drafts/draft-vyncke-6man-segment-routing-security-00.txt >> Status: https://datatracker.ietf.org/doc/draft-vyncke-6man-segment-routing-security/ >> Htmlized: http://tools.ietf.org/html/draft-vyncke-6man-segment-routing-security-00 >> >> >> Abstract: >> Segment Routing (SR) allows a node to steer a packet through a >> controlled set of instructions, called segments, by prepending a SR >> header to the packet. A segment can represent any instruction, >> topological or service-based. SR allows to enforce a flow through >> any path (topological, or application/service based) while >> maintaining per-flow state only at the ingress node to the SR domain. >> >> Segment Routing can be applied to the IPv6 data plane with the >> addition of a new type of Routing Extension Header. This draft >> analyses the security aspects the Segment Routing Extension Header >> Type and how it is used by SR capable nodes to deliver a secure >> service. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > I have read this draft. I admit the content is currently beyond me. Polite request: can you please tweak the layout of a future version to make it clear what exactly is normative in the standards track portion, or provide some clear separation of normative text from discussion (or even removal of the discussion)? e.g. Section 4. is background information but 4.1 appears normative and 4.2 is discussion mixed with normative text Thanks. -- Regards, RayH From nobody Sat Jul 5 14:15:34 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3081B2873 for ; Sat, 5 Jul 2014 14:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFxzzVyIZHMz for ; Sat, 5 Jul 2014 14:15:31 -0700 (PDT) Received: from poczta.agh.edu.pl (poczta.agh.edu.pl [IPv6:2001:6d8:10:1060::6023]) by ietfa.amsl.com (Postfix) with ESMTP id DAB351B2872 for ; Sat, 5 Jul 2014 14:15:30 -0700 (PDT) Received: from poczta.agh.edu.pl (localhost [127.0.0.1]) by poczta.agh.edu.pl (Postfix) with ESMTP id 554683813C for ; Sat, 5 Jul 2014 23:15:26 +0200 (CEST) Received: from user-31-174-190-245.play-internet.pl ([31.174.190.245]) by poczta.agh.edu.pl with HTTP (HTTP/1.1 POST); Sat, 05 Jul 2014 23:15:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 05 Jul 2014 23:15:26 +0200 From: Robert Chodorek To: Subject: draft-chodorek-multigroup-multicast-addr-00 Message-ID: <731186a856fda550672039861b9002b1@agh.edu.pl> X-Sender: chodorek@agh.edu.pl User-Agent: Roundcube Webmail/0.7.2 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/iPun3hzHwCqUhxKcFFfFMEciuMc X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 21:15:32 -0000 A new version of I-D, draft-chodorek-multigroup-multicast-addr-00.txt has been successfully submitted by Robert R. Chodorek and posted to the IETF repository. Name: draft-chodorek-multigroup-multicast-addr Revision: 00 Title: Multiple multicast addressing architecture Document date: 2014-03-28 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-chodorek-multigroup-multicast-addr-00.txt Status: https://datatracker.ietf.org/doc/draft-chodorek-multigroup-multicast-addr/ Htmlized: http://tools.ietf.org/html/draft-chodorek-multigroup-multicast-addr-00 Abstract: This document introduces a new class of IPv6 multicast addresses called "multiple multicast". We define multiple multicast as a set of multicast addresses belonging to one multicast session. From nobody Mon Jul 7 02:56:20 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157B91B2805 for ; Mon, 7 Jul 2014 02:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_L9J3fjv7mp for ; Mon, 7 Jul 2014 02:56:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0DE1B2806 for ; Mon, 7 Jul 2014 02:56:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS04094; Mon, 07 Jul 2014 09:56:15 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 10:56:13 +0100 From: Hosnieh Rafiee To: "ipv6@ietf.org" Subject: RE: I-D Action: draft-jiang-6man-cga-sec-option-00.txt Thread-Topic: I-D Action: draft-jiang-6man-cga-sec-option-00.txt Thread-Index: AQHPl11FmrcxRe6b0UGYLR500wsZBJuUYbKQ Date: Mon, 7 Jul 2014 09:56:14 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A0C8DC@lhreml513-mbb.china.huawei.com> References: <20140704075441.19774.85374.idtracker@ietfa.amsl.com> In-Reply-To: <20140704075441.19774.85374.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7zZko3XJLvJMLT73iO0k6KIhrlE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 09:56:19 -0000 Hi, I've read this document and I have some questions It was for purpose that in CGA document, they used 3 bits sec values as a p= art of an IP address. However, based on the current CGA specification docum= ent, this value has been ignored during the verification process and that w= as the result that I wrote http://tools.ietf.org/html/draft-rafiee-6man-cga-attack-01 But when you add new option but not a part of a CGA IP address, then the at= tack explained in my document can be applicable like with current CGA speci= fication document. In other words, the attacker easily can try to match dif= ferent CGA sec values with the CGA value of the legitimate node.=20 So, I guess you need to somehow protect CGA from this attack. Best, Hosnieh=20 -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, July 04, 2014 9:55 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-jiang-6man-cga-sec-option-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CGA SEC Option for Secure Neighbor Discovery Prot= ocol Authors : Sheng Jiang Dacheng Zhang Suresh Krishnan Filename : draft-jiang-6man-cga-sec-option-00.txt Pages : 5 Date : 2014-07-04 Abstract: A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. It is a vital component of Secure Neighbor Discovery (SeND) protocol. The current SeND specifications are lack of procedures to specify the Sec bits. A new SEC option is defined accordingly to address this issue. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jiang-6man-cga-sec-option/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jiang-6man-cga-sec-option-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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.ie= tf.org/ietf/1shadow-sites.txt From nobody Mon Jul 7 09:44:57 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232D81A035E for ; Mon, 7 Jul 2014 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuuZ0s3da97q for ; Mon, 7 Jul 2014 09:44:47 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCAA1A0377 for ; Mon, 7 Jul 2014 09:44:35 -0700 (PDT) Received: from [192.168.10.16] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s67GiO87029377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Jul 2014 09:44:26 -0700 Message-ID: <53BACE68.7030206@acm.org> Date: Mon, 07 Jul 2014 18:44:24 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF IPv6 Subject: FYI: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-06.txt References: <20140704170538.17514.75671.idtracker@ietfa.amsl.com> In-Reply-To: <20140704170538.17514.75671.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140704170538.17514.75671.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;7IkT9PUF5BGoq2uUdPQXfw== M;rrm39PUF5BGoq2uUdPQXfw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/TQgHpBAO0cxD4is3eCHobE8cbmY X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:44:50 -0000 -------- Original Message -------- Subject: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-06.txt Date: Fri, 04 Jul 2014 10:05:38 -0700 From: internet-drafts@ietf.org To: Pascal Thubert , Erik Nordmark , Pascal Thubert , Margaret Wasserman , Samita Chakrabarti , Erik Nordmark , Samita Chakrabarti , Margaret Wasserman A new version of I-D, draft-chakrabarti-nordmark-6man-efficient-nd-06.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Name: draft-chakrabarti-nordmark-6man-efficient-nd Revision: 06 Title: IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks Document date: 2014-07-04 Group: Individual Submission Pages: 34 URL: http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-06.txt Status: https://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/ Htmlized: http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-chakrabarti-nordmark-6man-efficient-nd-06 Abstract: IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined at a time when link-local multicast was as reliable and with the same network cost (send a packet on a yellow-coax Ethernet) as unicast and where the hosts were assumed to be always on and connected. Since 1996 we've seen a significant change with both an introduction of wireless networks and battery operated devices, which poses significant challenges for the old assumptions. We are also seeing datacenter networks where virtual machines are not always on and connected, and scaling of multicast can be challenging. This specification contains extensions to IPv6 Neighbor Discovery which remove most use of multicast and make sleeping hosts more efficient. The specification includes a default mixed mode where a link can have an arbitrary mix of hosts and/or routers - some implementing legacy Neighbor Discovery and some implementing the optimizations in this specification. The optimizations provide incremental benefits to hosts as soon as the first updated routers are deployed on a link. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 7 10:42:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F7F1A0547; Mon, 7 Jul 2014 10:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpB_eLswwZZY; Mon, 7 Jul 2014 10:42:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0E01A0522; Mon, 7 Jul 2014 10:42:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-6man-multicast-addr-arch-update-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707174228.6892.22341.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 10:42:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/NMOvE4AlC_VAZLXzBvtzn_HUvr8 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:42:29 -0000 --NextPart 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 : Updates to the IPv6 Multicast Addressing Architecture Author(s) : M. Boucadair, et al Filename : draft-ietf-6man-multicast-addr-arch-update Pages : 10 Date : 2014-07-07 This document updates the IPv6 multicast addressing architecture by re-defining the reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-addr-arch-update-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-multicast-addr-arch-update"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-07104228.I-D@ietf.org> --NextPart-- From nobody Tue Jul 8 07:19:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C3B1B2AD7 for ; Tue, 8 Jul 2014 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ADKfeR2wNC for ; Tue, 8 Jul 2014 07:19:16 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076B91B27A9 for ; Tue, 8 Jul 2014 07:19:16 -0700 (PDT) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s68EJ8aa025189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 07:19:10 -0700 Message-ID: <53BBFDDC.3090703@acm.org> Date: Tue, 08 Jul 2014 16:19:08 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ole Troan , Dmitry Anipko Subject: Re: draft-ietf-6man-resilient-rs update References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> In-Reply-To: <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;qFVC06oG5BGynE2zUc16mQ== M;InxV1KoG5BGynE2zUc16mQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/AhL1ekiBjg8MPz-AjIFfuLoS6zM Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:19:17 -0000 On 6/20/14, 2:46 PM, Ole Troan wrote: >> My impression from the discussion in London that the consensus was closer to (2) than (1) - that on such links the hosts should be allowed to restart transmissions in a reasonable / rate-limited manner, when connectivity parameters expire. And that we should add MAY text for that. > that's also fine with me. if there was a text proposal it would most likely be easier for the working group to come to a decision. > is that something the authors can take on? There wasn't a consensus call from the discussion in London, but my take is that what would be needed (in any document which wants to specify how to do RS refresh) is a lot more than adding a "MAY" sentence. We need to avoid a tragedy of the commons - I can make my host implementation be more robust by sending relatively frequent RSs but that would be harmful to the overall network and hosts' battery if other hosts do it as well. One of the negative interactions is that most (all?) router implementations respond to a unicast RS with a multicast RA, hence having hosts do RS refresh would result in a lot more multicast RAs in deployed networks. Furthermore, care is needed to avoid ending up with too frequent RSs from lots of hosts as lifetime naturally get lower for information that is supposed to expire. There is some discussion/suggestions on how to handle that in section 8.9 in http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-06.txt I don't know if the WG has consensus to include all of that in the resilent-rs. To me it seems like a significant expansion of the scope of the document. Note that the cited section 8.9 isn't sufficient to allow a network to operate without multicast RAs. Even if all hosts on a link send RSs to refresh information there is still a need for multicast RAs when when routers have new or changed information (such as prefix withdrawal or prefix addition) which they quickly want to disseminate to hosts. Thus the claim (or interpretation of the claim) in the abstract in resilent-rs that it allows operation on links where there are no unsolicited multicast RAs doesn't seem to have any basis in reality. The resilience mechanism does work on such links to reliably get an initial RA, but does not handle the cases of RA updates. But if the WG wants to take this document back to the drawing board and expand its scope, we can figure out what text that needs to be added. Or we can do that as part of a separate document - the efficient ND design team has been discussing these issues but there are not any drafts yet from that effort. Regards, Erik > > cheers, > Ole > > >> The minutes seem to be consistent with my impression: >> >> >> Andrew: I agree with both Erik and Lorenzo. We should not explicitly >> prohibit hosts from 1.b. >> >> Suresh: If we keep 1.b., we would need to address it. >> >> Andrew: Don't prohibit it, so that it may be addressed in another >> document. >> ... >> >> Dave Thaler: Keep scenario 1.b. Do constraints on rate-limiting. We have >> cases where ND varies by a specific ling-layer. Indeed, the mechanisms >> in this document comes from one of those documents. I think I'm in >> agreement with what I think is the consensus. >> >> >> ________________________________________ >> From: Ole Troan >> Sent: Thursday, June 19, 2014 5:08 AM >> To: 6man WG; draft-ietf-6man-resilient-rs@tools.ietf.org >> Cc: <6man-chairs@tools.ietf.org> >> Subject: draft-ietf-6man-resilient-rs update >> >> all, >> >> we have had this document in a WGLC for quite a while. there has been one outstanding issue. >> the document as currently written states: >> >> Abstract: >> Furthermore, on some links, unsolicited multicast >> Router Advertisements are never sent and the mechanism in this >> document is intended to work even in such scenarios. >> >> Introduction: >> b. Access networks/links that turn off periodic RAs and only send >> RAs in response to RSs. In this case, if the link between the >> Access Point (AP) and the host comes up before the link between >> the AP and the Controller/Router, the host will never be able to >> connect. This technique of turning off periodic RAs is commonly >> used in several wireless LAN and datacenter networks to reduce >> the amount of multicast traffic. >> >> in the specification part of the document it states: >> On multicast-capable links, the hosts following this specification >> SHOULD stop retransmitting the RSs when Router Discovery is >> successful (i.e. an RA with a non-zero Router Lifetime that results >> in a default route is received). >> >> as written a host connected to a link with the properties described in b, would lose its default router after the initial RA lifetime, and would not recover. >> >> there are two solutions to this: >> 1) remove the text in the abstract and introduction implying that this is a solution to links with multicast RA turned off >> 2) modify the algorithm to restart router solicitations when required >> >> after discussing this issue with the authors, there appears to be agreement to we resolve this issue by focusing the document on initial connection to the link only (1). >> >> unless this is contentious, the authors will publish an updated revision with these changes, that we'll run a short WGLC on, and then we will advance the document to the IESG. >> >> Best regards, >> Ole >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jul 8 08:13:18 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB41B2B0B for ; Tue, 8 Jul 2014 08:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tscxnD2D7Ubn for ; Tue, 8 Jul 2014 08:13:13 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D65A1B2811 for ; Tue, 8 Jul 2014 08:13:13 -0700 (PDT) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s68FD1sf004652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 08:13:03 -0700 Message-ID: <53BC0A7D.70905@acm.org> Date: Tue, 08 Jul 2014 17:13:01 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Suresh Krishnan , Ole Troan , Dmitry Anipko Subject: Re: draft-ietf-6man-resilient-rs update References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> In-Reply-To: <53A4AE11.5040900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;SLQZWrIG5BGsj02zUc16mQ== M;rtQKW7IG5BGsj02zUc16mQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FGGYSNSGYBq3UmW17mfIPGJ-vig Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:13:15 -0000 On 6/20/14, 11:56 PM, Suresh Krishnan wrote: > Hi Ole, > > On 06/20/2014 08:46 AM, Ole Troan wrote: >> >>> My impression from the discussion in London that the consensus was >>> closer to (2) than (1) - that on such links the hosts should be >>> allowed to restart transmissions in a reasonable / rate-limited >>> manner, when connectivity parameters expire. And that we should add >>> MAY text for that. >> >> that's also fine with me. if there was a text proposal it would most >> likely be easier for the working group to come to a decision. >> is that something the authors can take on? > > In my view, the text in the draft already reflects something akin to > what Dmitry was talking about (but not exactly option 2 from your > original mail on this thread). This is the relevant text from the draft. > > Hosts MAY continue retransmitting the RSs even after router discovery > is successful. If the host continues to retransmit RSs, it is > RECOMMENDED that such retransmissions be rate-limited to one every MRT. If hosts implement that MAY and they operate on a network with existing routers (that multicast the solicited RAs) we will see lots of multicast RAs. MRT=3600 seconds, thus as 1200 hosts we will have on average one RS every 3 seconds, resulting in a multicast RA every 3 seconds. (Can't be more frequent since the multicast RAs are rate limited to 1 per 3 seconds by 4861.) Such frequent multicast RAs will not help with battery life, and will also use up wifi multicast bandwidth. Coupling the hosts' use of RS refresh with the routers responding with unicast RA would help, but the resilent-rs draft doesn't do that. Hence that MAY is dangerous. Regards, Erik > > Cheers > Suresh > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jul 10 20:30:45 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8671A028B for ; Thu, 10 Jul 2014 20:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNfhn5QKA623 for ; Thu, 10 Jul 2014 20:30:42 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECE31B29AB for ; Thu, 10 Jul 2014 20:30:40 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so625610pdi.18 for ; Thu, 10 Jul 2014 20:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LtvkjlRweBZ1zcbrFE37XO0g2qr9kf1E+0Aj81f/8dE=; b=UIqUkj8W7W8SdxTKJpMoIj+Am2zvmXfa0s6K6SymyDmXlpapjge0D6JaJa4eNEA57a nl4OsWOxvITqNaOWlklUY3Hq1V94mggs9rkezUL3TR9dfH/6VU6tac7LaEQWTgBo3T/6 NfiB0l/LRytWk+L6Us5klc0FGGWQKeEzLvDczYCUP/zuS8E/W5wF7edYiUBXY76GYQlA nD9ksVyMquCEWjt1vlflzhJoXOIf3G9u8nR+3TBlCtPeaEUCb0SpWke19QWMsz8M56JS LEc/n57xZ0OtuL13n9OcLbH3bI65FABMCG7Lecd6BkyXvuIEBQaDCSwMyDrPxGwe+yjp df6A== X-Received: by 10.66.136.131 with SMTP id qa3mr50578798pab.77.1405049439930; Thu, 10 Jul 2014 20:30:39 -0700 (PDT) Received: from [192.168.178.23] (22.198.69.111.dynamic.snap.net.nz. [111.69.198.22]) by mx.google.com with ESMTPSA id jt7sm704085pbc.46.2014.07.10.20.30.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 20:30:38 -0700 (PDT) Message-ID: <53BF5A67.7050401@gmail.com> Date: Fri, 11 Jul 2014 15:30:47 +1200 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-vyncke-6man-segment-routing-security-00.txt References: <20140703134709.19452.78442.idtracker@ietfa.amsl.com> In-Reply-To: <20140703134709.19452.78442.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/qvnoo2G8ZkheX1w6Z51UjH2JN04 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 03:30:43 -0000 Hi, This draft says: > The SRH is simply another version of the routing header as described > in [RFC2460] and is: > > o inserted when entering the segment routing domain which could be > done by a node or by a router; There is no provision for routers to insert headers in an IPv6 packet, because this changes the packet size (and the payload length) and therefore breaks PMTU mechanisms. Only the host that originates a packet can insert headers. It seems that draft-previdi-6man-segment-routing-header-01 has the same problem. It says: > When creating the SRH (either at ingress node or in the SDN > controller) the following is done: > > Next Header and Hdr Ext Len fields are set according to [RFC2460]. > > Routing Type field is set as TBD (SRH). > > The DA of the packet is set with the address of the FIRST segment > of the path. (etc.) These are operations that can only be done by the host that creates the IPv6 packet, which is also the only place that a fragment header can be included if needed. As I understand it, the "ingress node" is a router, not the originating host. So this seems to be broken. Brian From nobody Fri Jul 11 00:54:36 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D405E1B2A9E for ; Fri, 11 Jul 2014 00:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeojv_otaGNw for ; Fri, 11 Jul 2014 00:54:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEB31A02E7 for ; Fri, 11 Jul 2014 00:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2363; q=dns/txt; s=iport; t=1405065310; x=1406274910; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kXxHUAyg1pK44XYnl09A0OFR5KXIglgvAgjb8LHP8t4=; b=I3nOpCGWSy49Kb8hjIni038BkwDOGaEKd7sqv7b8l+agj8G0VC61ByhE Yf/bDOuw+bJAtm/86W6tQSl6KVlgkpTNK6MRO+oVDipRk122xbKvCyRNa 9fMgylByH6H0S2x0CN8xsmnMWTJ3JurhMb4mzPXEl0sWNJiDq4zVGi1bl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAOmXv1OtJV2U/2dsb2JhbABZgw5SWsBoCodCAYELFnWEBAEBBAEBAWsbAgEIRiEGCyUCBAESiC4DEQ2/PQ2HGBMEjRqCM4RDBYoejmeCAI4FhhaDRGyBRA X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="59954984" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 11 Jul 2014 07:55:09 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6B7sUlQ019374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 07:54:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 02:54:29 -0500 From: "Eric Vyncke (evyncke)" To: Brian E Carpenter , 6man Subject: Re: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt Thread-Topic: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt Thread-Index: AQHPnLiIOom6lJ1CEEmPvO1GYIePJZua9pSA Date: Fri, 11 Jul 2014 07:54:28 +0000 Message-ID: References: <20140703134709.19452.78442.idtracker@ietfa.amsl.com> <53BF5A67.7050401@gmail.com> In-Reply-To: <53BF5A67.7050401@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F5DBCCA0BF4E244A595D4525305301B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fyfQyBYAyPCAe_SUF1ozdIlPPpA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 07:54:33 -0000 Brian Thanks for your review. You are right extension headers are _usually_ inserted by the source. But, this is not _always_ the case, for instance, we can argue that ESP/AH in tunnel mode can be added by a security gateway. So, inserting a SRH is not that exceptional. Of course, special care must be taken for MTU but in the use case this would not be a problem as SRH is used mainly within a single operator, so, a prerequisite is to have a larger MTU on all internal links. Note: I just quickly read again RFC 2460, and, I did not find any place where it is specified that extension header must be inserted only by the source. If my reading is wrong, then this is another reason to propose this I-D to 6MAN ;-) -=E9ric On 11/07/14 05:30, "Brian E Carpenter" wrote: >Hi, > >This draft says: > >> The SRH is simply another version of the routing header as described >> in [RFC2460] and is: >>=20 >> o inserted when entering the segment routing domain which could be >> done by a node or by a router; > >There is no provision for routers to insert headers in an IPv6 packet, >because this changes the packet size (and the payload length) and >therefore breaks PMTU mechanisms. Only the host that originates a packet >can insert headers. > >It seems that draft-previdi-6man-segment-routing-header-01 has the >same problem. It says: > >> When creating the SRH (either at ingress node or in the SDN >> controller) the following is done: >>=20 >> Next Header and Hdr Ext Len fields are set according to [RFC2460]. >>=20 >> Routing Type field is set as TBD (SRH). >>=20 >> The DA of the packet is set with the address of the FIRST segment >> of the path. > >(etc.) > >These are operations that can only be done by the host that creates >the IPv6 packet, which is also the only place that a fragment header >can be included if needed. As I understand it, the "ingress node" is >a router, not the originating host. So this seems to be broken. > > Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From nobody Fri Jul 11 01:35:47 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC561A03A0 for ; Fri, 11 Jul 2014 01:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgl3Yntdv2bw for ; Fri, 11 Jul 2014 01:35:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40B91A0392 for ; Fri, 11 Jul 2014 01:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2201; q=dns/txt; s=iport; t=1405067765; x=1406277365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/f90O8Lp46wC1r9VPEWDYklGXcGMMgb0No+9iSgxVrE=; b=P1evr+kg982Y929F7JsWniECzGwhYacNHUpeGPaiHgiauhXlldbe4n1/ ddIj0c+DzJrbBk/6tEYddh3ODuJyyLOlOOUeiv/P8ByErwlYJq16YtrtU IQnhgWbnqa39o5g9wx1fw8kBn5v2Vm/1HtWFK2uQMp1ZdDmKcn8vQG79/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAEqhv1OtJV2a/2dsb2JhbABZgw5SWsBoCodCAYELFnWEAwEBAQMBAQEBNzQLEAIBCBgeECcLJQIEDgWIOggNxlATBI9GB4MtgRYFmwWUG4NEgjA X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="339243016" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2014 08:36:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6B8ZhOQ032180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 08:35:43 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 03:35:43 -0500 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter Subject: Re: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt Thread-Topic: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt Thread-Index: AQHPnOMauVU2QqzUP0eHD2Rv42A+eA== Date: Fri, 11 Jul 2014 08:35:42 +0000 Message-ID: <2DEFC6B9-0978-4EB0-9B79-9F774450D7FC@cisco.com> References: <20140703134709.19452.78442.idtracker@ietfa.amsl.com> <53BF5A67.7050401@gmail.com> In-Reply-To: <53BF5A67.7050401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.206.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <408EDE1C9B1F684B956C226F5DD7E208@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/trGTFFgMikBCN8k12CZiRZbFqBU Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:35:46 -0000 On Jul 11, 2014, at 5:30 AM, Brian E Carpenter wrote: > Hi, >=20 > This draft says: >=20 >> The SRH is simply another version of the routing header as described >> in [RFC2460] and is: >>=20 >> o inserted when entering the segment routing domain which could be >> done by a node or by a router; >=20 > There is no provision for routers to insert headers in an IPv6 packet, > because this changes the packet size (and the payload length) and > therefore breaks PMTU mechanisms. Only the host that originates a packet > can insert headers. >=20 > It seems that draft-previdi-6man-segment-routing-header-01 has the > same problem. It says: >=20 >> When creating the SRH (either at ingress node or in the SDN >> controller) the following is done: >>=20 >> Next Header and Hdr Ext Len fields are set according to [RFC2460]. >>=20 >> Routing Type field is set as TBD (SRH). >>=20 >> The DA of the packet is set with the address of the FIRST segment >> of the path. >=20 > (etc.) >=20 > These are operations that can only be done by the host that creates > the IPv6 packet, which is also the only place that a fragment header > can be included if needed. As I understand it, the "ingress node" is > a router, not the originating host. So this seems to be broken. well, unless the multiple interoperable implementations we have are=20 also broken, I can tell you (and show you) it's a reality that works=20 well, that address a set of requirements (especially in terms of=20 service chaining) and "routers" can happily insert extensions headers. Now, let's agree on the definition of "router". If it's a device=20 acting at layer 3 and that "routes" packets based on DA and FIB=20 instructions, then it is obvious that a router can insert an SRH. However, it is also obvious that we do not expect core routers do so. s. >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jul 11 13:50:04 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB21B2BD1 for ; Fri, 11 Jul 2014 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB4RqsC6cLrW for ; Fri, 11 Jul 2014 13:50:00 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8F71B29FB for ; Fri, 11 Jul 2014 13:50:00 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so1991886pde.3 for ; Fri, 11 Jul 2014 13:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8npcbtRpFkcVoLnK/eHC9IOW+o8OYvPAk08ra4ODAdg=; b=QzmmgifX1SwWcUIA/gGusKDykCCCVJpQu6pYrMLDFleJjonfG+Nv6R7wsg9h1UQp99 rB5zfpSiYkw9ySAg5V28w67Ekawhm93TEO1S0FgUADpD5s1a4Wcsb1WDI46RVv1REsVD Td6e6anr3f929rUne6DarRMuQSzWxQOYXxAL5GxdihxJ5sm8zlUNpXZMvVFYEi/mFHJk +frX16+qjR3QYfjbvbwLtuvCpPK3iP8CsBnaUpQMFq/cSwd1WxHkh/KD5VSF/zyroE9c rVkyXNGeORAp522LA8xG92x+WycilCrSNb2a+aaF9+x+3uJRrLgAt5GTkgdXVOQgzHhn z3Ug== X-Received: by 10.68.252.41 with SMTP id zp9mr1075216pbc.65.1405111800421; Fri, 11 Jul 2014 13:50:00 -0700 (PDT) Received: from [192.168.178.23] (217.199.69.111.dynamic.snap.net.nz. [111.69.199.217]) by mx.google.com with ESMTPSA id qu5sm13179576pab.10.2014.07.11.13.49.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 13:49:59 -0700 (PDT) Message-ID: <53C04E01.40300@gmail.com> Date: Sat, 12 Jul 2014 08:50:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" Subject: Re: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt References: <20140703134709.19452.78442.idtracker@ietfa.amsl.com> <53BF5A67.7050401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/YM6u0BqkSbe_-hqlQ9wPEYbLoNI Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 20:50:02 -0000 Eric, On 11/07/2014 19:54, Eric Vyncke (evyncke) wrote: > Brian > > Thanks for your review. > > You are right extension headers are _usually_ inserted by the source. When we were working on RFC 7045, I went through various RFCs very carefully to check on this point. There is nothing anywhere that allows intermediate nodes to insert headers. The whole mechanism is designed on the assumption that the source node creates all headers, and performs fragmentation if needed, as well as being responsible for PMTUD of course. > But, > this is not _always_ the case, for instance, we can argue that ESP/AH in > tunnel mode can be added by a security gateway. Tunnel mode is irrelevant, because the outer header (that includes an IPsec header) encapsulates the inner header, which is unchanged. It's very clear in section 5.1.2.2 of RFC 4301. (There are two fields in the inner header, ECN and hop limit, that get updated by the decapsulator.) > So, inserting a SRH is not that exceptional. On the contrary, it's completely exceptional. > Of course, special care must > be taken for MTU but in the use case this would not be a problem as SRH is > used mainly within a single operator, so, a prerequisite is to have a > larger MTU on all internal links. "Mainly" is not good enough. I agree that we sometimes specify things that only work within a single administrative domain, but that has to be spelled out and architecturally clear. > Note: I just quickly read again RFC 2460, and, I did not find any place > where it is specified that extension header must be inserted only by the > source. If my reading is wrong, then this is another reason to propose > this I-D to 6MAN ;-) It's true that it isn't stated in those words. It's just clearly implied. Stefano, On 11/07/2014 20:35, Stefano Previdi (sprevidi) wrote: > On Jul 11, 2014, at 5:30 AM, Brian E Carpenter wrote: ... >> > It seems that draft-previdi-6man-segment-routing-header-01 has the >> > same problem. It says: >> > >>> >> When creating the SRH (either at ingress node or in the SDN >>> >> controller) the following is done: >>> >> >>> >> Next Header and Hdr Ext Len fields are set according to [RFC2460]. >>> >> >>> >> Routing Type field is set as TBD (SRH). >>> >> >>> >> The DA of the packet is set with the address of the FIRST segment >>> >> of the path. >> > >> > (etc.) >> > >> > These are operations that can only be done by the host that creates >> > the IPv6 packet, which is also the only place that a fragment header >> > can be included if needed. As I understand it, the "ingress node" is >> > a router, not the originating host. So this seems to be broken. > > > well, unless the multiple interoperable implementations we have are > also broken, I can tell you (and show you) it's a reality that works > well, that address a set of requirements (especially in terms of > service chaining) and "routers" can happily insert extensions headers. Well, it would be interesting to know how those implementations work when there is a marginal MTU inolved and/or when the hosts are using IPsec. It doesn't alter the fact that as far as the design of IPv6 extension headers goes, this is a hack. > Now, let's agree on the definition of "router". If it's a device > acting at layer 3 and that "routes" packets based on DA and FIB > instructions, then it is obvious that a router can insert an SRH. No it isn't; it's obvious that routing headers were designed to be created by the originating host, before calculating the payload length and before deciding whether a fragment header is needed. I can imagine in an SDN context that the source host is instructed by the SDN controller to insert a specific SRH. I can imagine a model where the source host includes an blank SRH that can be updated by the ingress router. But the model suggested in these two drafts where an ingress router inserts an SRH is definitely incompatible with RFC 2460. Brian From nobody Thu Jul 17 08:29:49 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080ED1A0199 for ; Thu, 17 Jul 2014 08:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY8uDIMfbwmW for ; Thu, 17 Jul 2014 08:29:47 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2E61A0181 for ; Thu, 17 Jul 2014 08:29:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HFTk29027678; Thu, 17 Jul 2014 10:29:46 -0500 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HFTZRm027080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 17 Jul 2014 10:29:36 -0500 Received: from XCH-BLV-108.nw.nos.boeing.com (2002:82f7:19bc::82f7:19bc) by XCH-PHX-309.sw.nos.boeing.com (2002:82f7:19a3::82f7:19a3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 17 Jul 2014 08:29:35 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.62]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 08:29:35 -0700 From: "Templin, Fred L" To: 6man WG Subject: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuw== Date: Thu, 17 Jul 2014 15:29:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4HIMEhMIXFIgH8caagXgXQOGe-c X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:29:48 -0000 Hi, Sometimes, an IPv6 node may have nothing useful to say but wants to make a little noise anyway. In those cases, it should be able to fire off a "blank" that gets through the network to the final destination but then gets dropped at the destination's doorstep. Here, I define a blank as any IPv6 packet that contains the value "No Next Header" in the ultimate (i.e., outermost) Next Header field. The IPv6 input process of the destination will receive the packet and delete it once it sees that there is no upper layer header following the IPv6 header. As I said, on the surface all this does is makes a little noise. But in some cases, useful information can be conveyed such as in a Destination Option. Is it worth writing a little 2-3 page informational document describing this? Thanks - Fred fred.l.templin@boeing.com From nobody Thu Jul 17 08:36:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20A61A01F6 for ; Thu, 17 Jul 2014 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stObv5ay85dG for ; Thu, 17 Jul 2014 08:36:49 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE651A0176 for ; Thu, 17 Jul 2014 08:36:49 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9132888110 for ; Thu, 17 Jul 2014 08:36:49 -0700 (PDT) Received: from 1025297193.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 61A6271B0001 for ; Thu, 17 Jul 2014 08:36:49 -0700 (PDT) Message-ID: <53C7ED88.1060909@innovationslab.net> Date: Thu, 17 Jul 2014 11:36:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: blanks References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JS3aJ4U6r3FAU9ROFGae9VttNFBBVBX4T" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/30mgYUmsB0bn70cAtNCYbfJ4EIY X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:36:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JS3aJ4U6r3FAU9ROFGae9VttNFBBVBX4T Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please don't. There is no need to standardize such a mechanism. On 7/17/14 11:29 AM, Templin, Fred L wrote: > Hi, >=20 > Sometimes, an IPv6 node may have nothing useful to say but wants > to make a little noise anyway. In those cases, it should be able > to fire off a "blank" that gets through the network to the final > destination but then gets dropped at the destination's doorstep. > Here, I define a blank as any IPv6 packet that contains the value > "No Next Header" in the ultimate (i.e., outermost) Next Header > field. The IPv6 input process of the destination will receive the > packet and delete it once it sees that there is no upper layer > header following the IPv6 header. >=20 > As I said, on the surface all this does is makes a little noise. > But in some cases, useful information can be conveyed such as in > a Destination Option. Is it worth writing a little 2-3 page > informational document describing this? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --JS3aJ4U6r3FAU9ROFGae9VttNFBBVBX4T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTx+2OAAoJEBOZRqCi7goqNbEIAI/WO4TdkLUqzp39evchKnC6 ZR3h5fkcf0uNy/jjVBvWRCmUkD8ganRJWISR/5yAuZa9p/BF1W6utHRkbidLT6U8 pSVehgwRQMPaYgnKeb9NYFCQ9sONgQpqitqvfMsPk2l73lIU7XNhjhtd61suGvYQ cNXjTbhApoGFrfnOYm3WkLrTyElDBJo1T+h+mTDphy1QXWQ5PYamMkh+v/QRzZj+ +lvD89iKjFSnNpTY6o/MQcnVs/n2l/fXIb5RVBs/NXs1lX9Trpv5Li2lAZ5/OqpP 8gwEJJ7FjTGIIwLiditKL4uLcxzIOu4Apd2jn0kIlzqlL4niEPwFHNydW6Zayow= =Bp3W -----END PGP SIGNATURE----- --JS3aJ4U6r3FAU9ROFGae9VttNFBBVBX4T-- From nobody Thu Jul 17 08:38:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07F1A0176 for ; Thu, 17 Jul 2014 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCYOjOHGDtpI for ; Thu, 17 Jul 2014 08:38:16 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987CA1A0AE3 for ; Thu, 17 Jul 2014 08:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HFcF7w019203; Thu, 17 Jul 2014 10:38:15 -0500 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HFcD3I019173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 10:38:13 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-PHX-111.sw.nos.boeing.com ([169.254.11.242]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 08:38:12 -0700 From: "Templin, Fred L" To: Brian Haberman , "ipv6@ietf.org" Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCA= Date: Thu, 17 Jul 2014 15:38:12 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> In-Reply-To: <53C7ED88.1060909@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vkMNKHXOuCWye7C0CIpqEe03b20 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:38:21 -0000 Hi, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Thursday, July 17, 2014 8:37 AM > To: ipv6@ietf.org > Subject: Re: blanks >=20 > Please don't. There is no need to standardize such a mechanism. Agreed; that is why I said "informational". Thanks - Fred fred.l.templin@boeing.com > On 7/17/14 11:29 AM, Templin, Fred L wrote: > > Hi, > > > > Sometimes, an IPv6 node may have nothing useful to say but wants > > to make a little noise anyway. In those cases, it should be able > > to fire off a "blank" that gets through the network to the final > > destination but then gets dropped at the destination's doorstep. > > Here, I define a blank as any IPv6 packet that contains the value > > "No Next Header" in the ultimate (i.e., outermost) Next Header > > field. The IPv6 input process of the destination will receive the > > packet and delete it once it sees that there is no upper layer > > header following the IPv6 header. > > > > As I said, on the surface all this does is makes a little noise. > > But in some cases, useful information can be conveyed such as in > > a Destination Option. Is it worth writing a little 2-3 page > > informational document describing this? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > From nobody Thu Jul 17 08:41:34 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1BE1B27B5 for ; Thu, 17 Jul 2014 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q8qyVH31RzA for ; Thu, 17 Jul 2014 08:41:21 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14121ABB1D for ; Thu, 17 Jul 2014 08:41:15 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8E7FE88110 for ; Thu, 17 Jul 2014 08:41:15 -0700 (PDT) Received: from 1025297193.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5CC7971B0001 for ; Thu, 17 Jul 2014 08:41:15 -0700 (PDT) Message-ID: <53C7EE9C.9000703@innovationslab.net> Date: Thu, 17 Jul 2014 11:41:16 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Re: blanks References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EG8QVeQDrxBRXPldKcWlrcWRBgODDTsBN" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vQgLtf0epMmjEolIiPPZwiWdTe8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:41:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EG8QVeQDrxBRXPldKcWlrcWRBgODDTsBN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let me try again... On 7/17/14 11:38 AM, Templin, Fred L wrote: > Hi, >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman >> Sent: Thursday, July 17, 2014 8:37 AM >> To: ipv6@ietf.org >> Subject: Re: blanks >> >> Please don't. There is no need to standardize such a mechanism. >=20 > Agreed; that is why I said "informational". Regardless of the status, there are a myriad of ways to send a "blank" packet. Why document one way? I see no benefit to writing a document on how to send such a packet. If you want to send such a packet, go for it. There is nothing stopping you and there is no need to publish how you did so. Regards, Brian >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> On 7/17/14 11:29 AM, Templin, Fred L wrote: >>> Hi, >>> >>> Sometimes, an IPv6 node may have nothing useful to say but wants >>> to make a little noise anyway. In those cases, it should be able >>> to fire off a "blank" that gets through the network to the final >>> destination but then gets dropped at the destination's doorstep. >>> Here, I define a blank as any IPv6 packet that contains the value >>> "No Next Header" in the ultimate (i.e., outermost) Next Header >>> field. The IPv6 input process of the destination will receive the >>> packet and delete it once it sees that there is no upper layer >>> header following the IPv6 header. >>> >>> As I said, on the surface all this does is makes a little noise. >>> But in some cases, useful information can be conveyed such as in >>> a Destination Option. Is it worth writing a little 2-3 page >>> informational document describing this? >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> --EG8QVeQDrxBRXPldKcWlrcWRBgODDTsBN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTx+6cAAoJEBOZRqCi7goqWO0H/2PrRwDX4rqsc6C2r5Zdv1GX 1EcnbcBs7hbEoeDfspWxxpPyYKD/Fwg05h6A8UhePYbhKaxqlOkHfsRJa8llZuVu qQZYsSQwtlvHUsSZUQqt6fBlq3PV0fkRaL0blpvsvJi53MQYXgXrAVXevJtgSbrO IPaHs80Q2O7EHtUbTgP+zlmnBrH2IEtZN5tdPmLsz4oCbdq0BX/KSkoxWM0yMIcz uHHxEpZyLmOcE93zGPXu/2q315F6lVLo9KKHeiC5NsQo64Kkxiuc6W3XWD1dHnlF ILewG9d04k7M/EwwTwobmU6JJN0BmDQ3c6baLBz07bg8PaI6x1n1xF1s/v15PuM= =VZhO -----END PGP SIGNATURE----- --EG8QVeQDrxBRXPldKcWlrcWRBgODDTsBN-- From nobody Thu Jul 17 08:52:26 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CA71A0301 for ; Thu, 17 Jul 2014 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAywHpWJR7jz for ; Thu, 17 Jul 2014 08:52:18 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37391A0176 for ; Thu, 17 Jul 2014 08:52:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HFqIog016343; Thu, 17 Jul 2014 08:52:18 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HFqA3w016265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 08:52:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.165]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 08:52:10 -0700 From: "Templin, Fred L" To: Brian Haberman , "ipv6@ietf.org" Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA Date: Thu, 17 Jul 2014 15:52:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> In-Reply-To: <53C7EE9C.9000703@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0hqJdNlY4NlYBChup9X_LL_7cns X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:52:24 -0000 Hi Brian, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Thursday, July 17, 2014 8:41 AM > To: ipv6@ietf.org > Subject: Re: blanks >=20 > Let me try again... >=20 > On 7/17/14 11:38 AM, Templin, Fred L wrote: > > Hi, > > > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman > >> Sent: Thursday, July 17, 2014 8:37 AM > >> To: ipv6@ietf.org > >> Subject: Re: blanks > >> > >> Please don't. There is no need to standardize such a mechanism. > > > > Agreed; that is why I said "informational". >=20 > Regardless of the status, there are a myriad of ways to send a "blank" > packet. Why document one way? This way has I think a fairly unique property that the packet makes it through the network to the IP layer of the final destination where it can be examined for things such as Destination Options, but is then dropped without ever disturbing any upper layer protocols. The network sees a flow of packets, the destination's interface input counters get incremented, etc. exactly as if the thing was a live IPv6 packet, but then the blank falls harmlessly into the bit bucket.=20 > I see no benefit to writing a document > on how to send such a packet. I was thinking more of a document that says "why" instead of "how". As in a few potential use cases. > If you want to send such a packet, go for > it. There is nothing stopping you and there is no need to publish how > you did so. Right; not how but why. Thanks - Fred fred.l.templin@boeing.com=20 =20 > Regards, > Brian >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> On 7/17/14 11:29 AM, Templin, Fred L wrote: > >>> Hi, > >>> > >>> Sometimes, an IPv6 node may have nothing useful to say but wants > >>> to make a little noise anyway. In those cases, it should be able > >>> to fire off a "blank" that gets through the network to the final > >>> destination but then gets dropped at the destination's doorstep. > >>> Here, I define a blank as any IPv6 packet that contains the value > >>> "No Next Header" in the ultimate (i.e., outermost) Next Header > >>> field. The IPv6 input process of the destination will receive the > >>> packet and delete it once it sees that there is no upper layer > >>> header following the IPv6 header. > >>> > >>> As I said, on the surface all this does is makes a little noise. > >>> But in some cases, useful information can be conveyed such as in > >>> a Destination Option. Is it worth writing a little 2-3 page > >>> informational document describing this? > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> From nobody Thu Jul 17 08:54:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3673C1A0176 for ; Thu, 17 Jul 2014 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6duQ4RPmUvW for ; Thu, 17 Jul 2014 08:54:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0454F1A0181 for ; Thu, 17 Jul 2014 08:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1376; q=dns/txt; s=iport; t=1405612443; x=1406822043; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DE4zpiEE2ezml+jK+Ktc/iWhK0TSRqtdQcG2Td2e0sA=; b=ezWGCei0alD1FkwqejH8rsbVJFyTQndgqIXF+3FUkwpt49itUKK8MS5+ 1ExDI23hETAquT+NxXGOOtJm6AgfhFWZRmmusm1PAv5qtYFHH8v8cmssI UfgK+MI0zj/JNG4rra5WsyAPaeteRoMrk3EAywjmr0jvKiJe6ZlqS+sOC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAMnwx1OtJA2N/2dsb2JhbABZgw5SVwTDRgqHQgGBBhZ2hAQBAQQBAQFrGwIBCEYnCyUBAQQBEohCDcVtEwSPUgKERAWKKpB1lCyDRGwBgUQ X-IronPort-AV: E=Sophos;i="5.01,679,1400025600"; d="scan'208";a="61695378" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 17 Jul 2014 15:54:02 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6HFs2Ow028477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 15:54:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 10:53:57 -0500 From: "Eric Vyncke (evyncke)" To: "Templin, Fred L" , 6man WG Subject: Re: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAPhZMA Date: Thu, 17 Jul 2014 15:54:01 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6BDCC143CF5E1440878FBA93EB6CAA20@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xWANVAFkKGIEE5vuJYIiqAT7MgM X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:54:09 -0000 Fred Perhaps worth describing on this list and with a couple of sentences, the 'why' as you wrote... Teredo bubbles have there for a while ;-) -=E9ric On 17/07/14 17:29, "Templin, Fred L" wrote: >Hi, > >Sometimes, an IPv6 node may have nothing useful to say but wants >to make a little noise anyway. In those cases, it should be able >to fire off a "blank" that gets through the network to the final >destination but then gets dropped at the destination's doorstep. >Here, I define a blank as any IPv6 packet that contains the value >"No Next Header" in the ultimate (i.e., outermost) Next Header >field. The IPv6 input process of the destination will receive the >packet and delete it once it sees that there is no upper layer >header following the IPv6 header. > >As I said, on the surface all this does is makes a little noise. >But in some cases, useful information can be conveyed such as in >a Destination Option. Is it worth writing a little 2-3 page >informational document describing this? > >Thanks - Fred >fred.l.templin@boeing.com > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From nobody Thu Jul 17 08:58:37 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE11A01F6 for ; Thu, 17 Jul 2014 08:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8hI0Wcl-tps for ; Thu, 17 Jul 2014 08:58:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13AE1A0176 for ; Thu, 17 Jul 2014 08:58:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A754388118 for ; Thu, 17 Jul 2014 08:58:32 -0700 (PDT) Received: from 1025297193.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7598E71B0001 for ; Thu, 17 Jul 2014 08:58:32 -0700 (PDT) Message-ID: <53C7F2A3.3070301@innovationslab.net> Date: Thu, 17 Jul 2014 11:58:27 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Re: blanks References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ow5jjDmLeDu6LOKVBNI0Css163KxqDxUG" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/_JNdWsrV9aWE_ChtMJ7PelkC258 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:58:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ow5jjDmLeDu6LOKVBNI0Css163KxqDxUG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fred, On 7/17/14 11:52 AM, Templin, Fred L wrote: > Hi Brian, >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman >> Sent: Thursday, July 17, 2014 8:41 AM >> To: ipv6@ietf.org >> Subject: Re: blanks >> >> Let me try again... >> >> On 7/17/14 11:38 AM, Templin, Fred L wrote: >>> Hi, >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberma= n >>>> Sent: Thursday, July 17, 2014 8:37 AM >>>> To: ipv6@ietf.org >>>> Subject: Re: blanks >>>> >>>> Please don't. There is no need to standardize such a mechanism. >>> >>> Agreed; that is why I said "informational". >> >> Regardless of the status, there are a myriad of ways to send a "blank"= >> packet. Why document one way? >=20 > This way has I think a fairly unique property that the packet makes > it through the network to the IP layer of the final destination where > it can be examined for things such as Destination Options, but is then > dropped without ever disturbing any upper layer protocols. The network > sees a flow of packets, the destination's interface input counters get > incremented, etc. exactly as if the thing was a live IPv6 packet, but > then the blank falls harmlessly into the bit bucket.=20 >=20 >> I see no benefit to writing a document >> on how to send such a packet. >=20 > I was thinking more of a document that says "why" instead of "how". > As in a few potential use cases. >=20 >> If you want to send such a packet, go for >> it. There is nothing stopping you and there is no need to publish how= >> you did so. >=20 > Right; not how but why. Still don't see the benefit. --ow5jjDmLeDu6LOKVBNI0Css163KxqDxUG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTx/KpAAoJEBOZRqCi7goqLY8H/20BtHPc3I5Gpp9GH6YTgVNK lTPi3KsWebV3+YLszQQncU9XjM4yRB0Yl+vJMaJcS/arwoaLpX/+DnTz5OPyk4ce gzjX/iAyxDhz31xDg2HC2paVm9d30tdrL/+GPdNMcwYWvsgqrxERS3zRjOlbd+V6 1QP4s7Df89v5vKW1Pq6XO9i8TE4lu12PZzS2i8Aq3dsgKe3d9rEL5cNLFTO/Zx9U BCXc377C5YuwwGiG+tq0OHj3CmrP9th8oqqF5784fcL7D9KQPBX2aa60vNcUYxMS tRHfLC0rEEt4BBOCiwbJ7oTwQDN8PpAc2zG9sFpo9+8N5JtAaTu+IvSS/mB6uvk= =abVL -----END PGP SIGNATURE----- --ow5jjDmLeDu6LOKVBNI0Css163KxqDxUG-- From nobody Thu Jul 17 09:13:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462E1B279C for ; Thu, 17 Jul 2014 09:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgZYQ-fDLOLT for ; Thu, 17 Jul 2014 09:13:01 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B2D1B27BC for ; Thu, 17 Jul 2014 09:13:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HGD0uP011456; Thu, 17 Jul 2014 11:13:00 -0500 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HGCvLH011419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 11:12:58 -0500 Received: from XCH-BLV-306.nw.nos.boeing.com (2002:82f7:19da::82f7:19da) by XCH-PHX-313.sw.nos.boeing.com (2002:82f7:19af::82f7:19af) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 17 Jul 2014 09:12:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.86]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 09:12:56 -0700 From: "Templin, Fred L" To: Brian Haberman , "ipv6@ietf.org" Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA//+QG4CAAHJ2sA== Date: Thu, 17 Jul 2014 16:12:55 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> In-Reply-To: <53C7F2A3.3070301@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/pENI1B8qjgahIbatJpCSi2XOBxE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:13:05 -0000 > Still don't see the benefit. Blanks can be sent at the discretion of the sender for the benefit of the receiver(s). Just a little blip to let the receiver(s) know that the sender is still alive and w/o having to disturb any upper layer protocols. The network path(s) between the sender and receiver(s) may also be interested to see some occasional traffic. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Jul 17 09:17:31 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28B1A01F6 for ; Thu, 17 Jul 2014 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrOsefeBYGG1 for ; Thu, 17 Jul 2014 09:17:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972091A0033 for ; Thu, 17 Jul 2014 09:17:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 804FD88118 for ; Thu, 17 Jul 2014 09:17:05 -0700 (PDT) Received: from 1025297193.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4C4D071B0001 for ; Thu, 17 Jul 2014 09:17:05 -0700 (PDT) Message-ID: <53C7F6FC.7010604@innovationslab.net> Date: Thu, 17 Jul 2014 12:17:00 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Re: blanks References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nFI39u4OQcMktqkHjnCdQsGHToWdq43GL" Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CnO5dJZ3K3vfvXTbI7Y7ESMKwEo X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:17:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nFI39u4OQcMktqkHjnCdQsGHToWdq43GL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/17/14 12:12 PM, Templin, Fred L wrote: >> Still don't see the benefit. >=20 > Blanks can be sent at the discretion of the sender for the benefit > of the receiver(s). Just a little blip to let the receiver(s) know > that the sender is still alive and w/o having to disturb any upper > layer protocols. The network path(s) between the sender and > receiver(s) may also be interested to see some occasional traffic. >=20 So, you are basically describing RFC 5880 (albeit in one direction, maybe= ). I will repeat myself once more and then shut up... I don't see the benefit of documenting the "why" in an RFC. Your original note read like you wanted to describe the "how" and I don't see the need either since this is just noise that can be generated in a multitude of ways. --nFI39u4OQcMktqkHjnCdQsGHToWdq43GL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTx/cCAAoJEBOZRqCi7goqsM4IAIge+PH8DlyWWb19OzDMkuPT HM2xAnh+ImJRVSK83TxZ8Go4123FxS4L/uPQFhD+wdBDLB2NgmFL6UG8LESS5+jy 0M3SRTdj+O+TUeG/LVS7qcxiV7dzpOTfTt4tD4vRF8PTBSZG3SU156/ovgYjQL0l mmc5tbAjfhmGnwyChcFAnLfbAIK2bTs4hhKKoY1IbfgeTi047Fo+lF/2kJmjq/br Rfj6Jq4sWSfeVDMBXgsUCd7jDtz24F8lsJgA2/ss4TM/+EY9RMdBlen+nrMnQjuI +M9d6ks2LTsfr93H+Md7i7MttW20RD+iz31i0Wqf4AzFscotBXsbOk4MVX8K3AM= =6otj -----END PGP SIGNATURE----- --nFI39u4OQcMktqkHjnCdQsGHToWdq43GL-- From nobody Thu Jul 17 09:25:10 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331D81B27CF for ; Thu, 17 Jul 2014 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04teCQHnf0Mb for ; Thu, 17 Jul 2014 09:24:47 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A99A1B27C6 for ; Thu, 17 Jul 2014 09:24:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HGOkxX003377; Thu, 17 Jul 2014 09:24:47 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HGOeOB003195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 09:24:40 -0700 Received: from XCH-BLV-207.nw.nos.boeing.com (10.57.37.63) by XCH-PHX-112.sw.nos.boeing.com (130.247.25.134) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 17 Jul 2014 09:24:39 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.96]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 09:24:39 -0700 From: "Templin, Fred L" To: Brian Haberman , "ipv6@ietf.org" Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA//+QG4CAAHJ2sP//krgAgAB0yjA= Date: Thu, 17 Jul 2014 16:24:38 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB1A3@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> In-Reply-To: <53C7F6FC.7010604@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cZKom_4u2Hm-hRi-gdQH18WdGhc X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:24:49 -0000 Hi Brian, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Thursday, July 17, 2014 9:17 AM > To: ipv6@ietf.org > Subject: Re: blanks >=20 >=20 >=20 > On 7/17/14 12:12 PM, Templin, Fred L wrote: > >> Still don't see the benefit. > > > > Blanks can be sent at the discretion of the sender for the benefit > > of the receiver(s). Just a little blip to let the receiver(s) know > > that the sender is still alive and w/o having to disturb any upper > > layer protocols. The network path(s) between the sender and > > receiver(s) may also be interested to see some occasional traffic. > > >=20 > So, you are basically describing RFC 5880 (albeit in one direction, maybe= ). 49 pages - wow, that's a lot of text! I was thinking 2-3 pages. > I will repeat myself once more and then shut up... >=20 > I don't see the benefit of documenting the "why" in an RFC. I'm not pushing hard for this - just testing the waters before wasting Internet Draft submission resources, and perhaps to introduce a new term. > Your original note read like you wanted to describe the "how" Apologies. > and I don't see > the need either since this is just noise that can be generated in a > multitude of ways. On that, I think I made the point that this manner has some fairly unique and desirable properties. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Jul 17 09:26:43 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2C1B27D6 for ; Thu, 17 Jul 2014 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEdfmpo_sUxz for ; Thu, 17 Jul 2014 09:25:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BF21B27D8 for ; Thu, 17 Jul 2014 09:25:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B95220028; Thu, 17 Jul 2014 12:26:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AC34F63B0E; Thu, 17 Jul 2014 12:25:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 96DE063AED; Thu, 17 Jul 2014 12:25:18 -0400 (EDT) From: Michael Richardson To: Brian Haberman Subject: Re: blanks In-Reply-To: <53C7F6FC.7010604@innovationslab.net> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5dYeweiU6WkorkISIRow29S9WD8 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:25:33 -0000 --=-=-= Brian Haberman wrote: > On 7/17/14 12:12 PM, Templin, Fred L wrote: >>> Still don't see the benefit. >> >> Blanks can be sent at the discretion of the sender for the benefit of >> the receiver(s). Just a little blip to let the receiver(s) know that >> the sender is still alive and w/o having to disturb any upper layer >> protocols. The network path(s) between the sender and receiver(s) may >> also be interested to see some occasional traffic. >> > So, you are basically describing RFC 5880 (albeit in one direction, > maybe). > I will repeat myself once more and then shut up... > I don't see the benefit of documenting the "why" in an RFC. Your > original note read like you wanted to describe the "how" and I don't > see the need either since this is just noise that can be generated in a > multitude of ways. It would definitely be an odd packet for someone to notice in the middle. It could cause a device in the middle to do the wrong thing (such as look for port numbers where none exist). That it is a legitimate activity might be implicit in the IPv6 documents; but it is explicitely called out? I know that we talked about doing exactly such a thing inside IPsec tunnels as keepalives as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8f47ICLcPvd0N1lAQJmmQgAuYao1mSiSg3OCvCafHKPHmIcynKSxg2X 0dKPAoamdIXGn5h2vpHwjriHXXRBDhONYwdv6WSSWnO4ejCSTXKwyEdQ3EaabXZP ayvk3zgp8APnABGIsNsHShx3xdbc0zbsymiJmJ3B4wMBkDbEGHGQ7ToMWri3PjTB HcyFU2mkt2ToI2lcVXLfBlHYkipPz+0flqwO2y/Mtsu5rJ94bSsgGzQsKegfv7jf KtjICO8gevwjFio76xgD0f4R7TKorknpewIgwXhfpr4xnRoPDYOVoWuNB/xYmoQB ckoERjmuXYLFRSkYCM7kiFXwaKkoEEAnwBCcb7TXN+9ldfRIc88qig== =3yXy -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 17 09:47:21 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADC01A0181 for ; Thu, 17 Jul 2014 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEMVcoAn0fso for ; Thu, 17 Jul 2014 09:46:44 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05BC1A002D for ; Thu, 17 Jul 2014 09:46:44 -0700 (PDT) Received: from maxijim.local ([68.43.142.33]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0McVXi-1Wq9Q30xUG-00Hhhw for ; Thu, 17 Jul 2014 18:46:43 +0200 From: James R Cutler Content-Type: multipart/signed; boundary="Apple-Mail=_FAC11344-0D2F-4545-BC53-93CB1D0D3A9D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <8D11901A-6091-4301-A578-04AFF147A8DF@consultant.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: blanks Date: Thu, 17 Jul 2014 12:46:41 -0400 References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> To: "ipv6@ietf.org" In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:Wv5PL0RuxEcxR0Srp1a7SJKcMeqnrSrp9QXEPJWbRZabMNDPgNI xQusivhwQs3YstnBnuox7wN9yp1erxlfvvF4rrbhwmsjxlmRvWoRRgitnXHO5zxwLhBPE0g BO29tPyvpRI6l5RGossEzu7nKi7JmtruiExwV/wRxW5mwoes/syGDLIhRvN/GBK0c7wuZyx P5SH3OY6ckiTiSIKqdiHw== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/o6cbUEq10_7ZzdMxt2NKnevXv4I X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:46:47 -0000 --Apple-Mail=_FAC11344-0D2F-4545-BC53-93CB1D0D3A9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7/17/14 11:29 AM, Templin, Fred L wrote: > Hi, >=20 > Sometimes, an IPv6 node may have nothing useful to say but wants > to make a little noise anyway. In those cases, it should be able > to fire off a "blank" that gets through the network to the final > destination but then gets dropped at the destination's doorstep. > Here, I define a blank as any IPv6 packet that contains the value > "No Next Header" in the ultimate (i.e., outermost) Next Header > field. The IPv6 input process of the destination will receive the > packet and delete it once it sees that there is no upper layer > header following the IPv6 header. >=20 > As I said, on the surface all this does is makes a little noise. > But in some cases, useful information can be conveyed such as in > a Destination Option. Is it worth writing a little 2-3 page > informational document describing this? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- I would suggest that an IPv6 node that is that lonely needs more = attention from the System Manager. Making noise to disturb other nodes = is not a particularly friendly act. If the business purpose is to determine ongoing connectivity for a = business activity, the an application level query and response is = appropriate. For generic connectivity probing, ECHO is appropriate, but = not just because a node is lonely or bored. James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu --Apple-Mail=_FAC11344-0D2F-4545-BC53-93CB1D0D3A9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPH/fEACgkQHzETiNcaVPmSCwCdH5rDhtEWvXtvyiMpftjMCfpw hpwAniZbuFK1jkjRYIcb0Z5E/yQwMMas =Mi2A -----END PGP SIGNATURE----- --Apple-Mail=_FAC11344-0D2F-4545-BC53-93CB1D0D3A9D-- From nobody Thu Jul 17 09:56:31 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081C61A0201 for ; Thu, 17 Jul 2014 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A76U4grH2uq for ; Thu, 17 Jul 2014 09:55:47 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259781A0181 for ; Thu, 17 Jul 2014 09:55:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HGtktx026036; Thu, 17 Jul 2014 11:55:46 -0500 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HGtZKR025302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 11:55:36 -0500 Received: from XCH-BLV-405.nw.nos.boeing.com (2002:82f7:199e::82f7:199e) by XCH-PHX-213.sw.nos.boeing.com (2002:82f7:198e::82f7:198e) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 17 Jul 2014 09:55:35 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.201]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 09:55:35 -0700 From: "Templin, Fred L" To: Michael Richardson , Brian Haberman Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA//+QG4CAAHJ2sP//ICcd///5IqA= Date: Thu, 17 Jul 2014 16:55:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> <32055.1405614318@sandelman.ca> In-Reply-To: <32055.1405614318@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/rQJFefWd58esEzvTeK6XoC0RX1w Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:55:49 -0000 Hi Michael, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Thursday, July 17, 2014 9:25 AM > To: Brian Haberman > Cc: ipv6@ietf.org > Subject: Re: blanks >=20 >=20 > Brian Haberman wrote: > > On 7/17/14 12:12 PM, Templin, Fred L wrote: > >>> Still don't see the benefit. > >> > >> Blanks can be sent at the discretion of the sender for the benefit= of > >> the receiver(s). Just a little blip to let the receiver(s) know th= at > >> the sender is still alive and w/o having to disturb any upper laye= r > >> protocols. The network path(s) between the sender and receiver(s) = may > >> also be interested to see some occasional traffic. > >> >=20 > > So, you are basically describing RFC 5880 (albeit in one direction, > > maybe). >=20 > > I will repeat myself once more and then shut up... >=20 > > I don't see the benefit of documenting the "why" in an RFC. Your > > original note read like you wanted to describe the "how" and I don'= t > > see the need either since this is just noise that can be generated = in a > > multitude of ways. >=20 > It would definitely be an odd packet for someone to notice in the middle. Perhaps in some networks, but maybe not all. > It could cause a device in the middle to do the wrong thing (such as look= for > port numbers where none exist). That sounds like broken networking gear - it would be good to find such gear and fix it. > That it is a legitimate activity might be > implicit in the IPv6 documents; but it is explicitely called out? I think the specs are silent, but blanks are built in just the same. > I know that we talked about doing exactly such a thing inside IPsec tunne= ls > as keepalives as well. I'll add this to my use case list. Thanks - Fred fred.l.templin@boeing.com > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jul 17 11:04:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C071A0092 for ; Thu, 17 Jul 2014 11:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw0_a42xPzMH for ; Thu, 17 Jul 2014 11:03:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE571A0062 for ; Thu, 17 Jul 2014 11:03:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7723020028; Thu, 17 Jul 2014 14:04:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 172CF63B0E; Thu, 17 Jul 2014 14:02:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F2AC863AED; Thu, 17 Jul 2014 14:02:49 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" Subject: Re: blanks In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> <32055.1405614318@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/TLBe86DFSqj0M7UYrsf6NBmQwwc Cc: Brian Haberman , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:03:13 -0000 --=-=-= Templin, Fred L wrote: >> It would definitely be an odd packet for someone to notice in the >> middle. > Perhaps in some networks, but maybe not all. I'm saying this from the point of view of someone who is looking at the traffic in the middle trying to figure out why: >> It could cause a device in the middle to do the wrong thing (such as >> look for port numbers where none exist). > That sounds like broken networking gear - it would be good to find such > gear and fix it. there is this gear in the middle that is failing; because it was misdesigned. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8gPx4CLcPvd0N1lAQKMtAgAgCg9xrDFx4nBnp4JSSYoGa9jteAc0QwH 6LvsYoNSSCMalNd3vi2Q1K9/v+2hXaLoMqkUwgWsmJ51PwBY9Z9OBF0rvEX2uTry EzE3BYADhnigyTfa6oETFgA6had5WiXpyOc0SU5Mu9chmG17w76k5Gs5vfwvcX6V 6/Cn/74G7LaNip19P7pBh4gZgkZ3mFxieWzw/aH94uh7rltRv6J9eVw09iuYomVx oqtqEErY8MEqQ/JG23JtQr/Y3nNNpWqCwIFHRXIvmdDnzFhtdl5xCYDuzCuo/9Fn tcBYOhftVEUr2aLK2IU3FMUXatldV8AFoYdPXSTuUH684nb8bre0iQ== =AEK+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 17 11:42:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A01A00D6 for ; Thu, 17 Jul 2014 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqvVQixxKZbV for ; Thu, 17 Jul 2014 11:41:13 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536F61A009C for ; Thu, 17 Jul 2014 11:41:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HIfCrQ011826; Thu, 17 Jul 2014 13:41:12 -0500 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HIf93S011312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 13:41:09 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.209]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 11:41:08 -0700 From: "Templin, Fred L" To: Michael Richardson Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA//+QG4CAAHJ2sP//ICcd///5IqAAEuAPgAANfSVQ Date: Thu, 17 Jul 2014 18:41:08 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB40E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> <32055.1405614318@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> <20330.1405620169@sandelman.ca> In-Reply-To: <20330.1405620169@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/YckFoqFqGS1kIoburZuO0zM0e4k Cc: Brian Haberman , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:41:15 -0000 Hi Michael, > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Ric= hardson > Sent: Thursday, July 17, 2014 11:03 AM > To: Templin, Fred L > Cc: Brian Haberman; ipv6@ietf.org > Subject: Re: blanks >=20 >=20 > Templin, Fred L wrote: > >> It would definitely be an odd packet for someone to notice in the > >> middle. >=20 > > Perhaps in some networks, but maybe not all. >=20 > I'm saying this from the point of view of someone who is looking at the > traffic in the middle trying to figure out why: >=20 > >> It could cause a device in the middle to do the wrong thing (such = as > >> look for port numbers where none exist). >=20 > > That sounds like broken networking gear - it would be good to find = such > > gear and fix it. >=20 > there is this gear in the middle that is failing; because it was misdesig= ned. Understood. But, I think there will be uses for IPv6 in networks besides the public Internet where we might have a bit more control over the type of networking gear we deploy. Thanks - Fred fred.l.templin@boeing.com > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jul 17 11:56:24 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9A1A0076 for ; Thu, 17 Jul 2014 11:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx6sJ1sZKsTz for ; Thu, 17 Jul 2014 11:54:28 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128A21A000F for ; Thu, 17 Jul 2014 11:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6HIsR3g002039; Thu, 17 Jul 2014 11:54:27 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6HIsJMa001898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 11:54:20 -0700 Received: from XCH-BLV-106.nw.nos.boeing.com (2002:82f7:197a::82f7:197a) by XCH-PHX-112.sw.nos.boeing.com (2002:82f7:1986::82f7:1986) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 17 Jul 2014 11:54:19 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.166]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 11:54:18 -0700 From: "Templin, Fred L" To: Michael Richardson Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwAO6poAAA6kwCD//4wjAIAAdLJA//+QG4CAAHJ2sP//ICcd///5IqAAEuAPgAANfSVQABp28BA= Date: Thu, 17 Jul 2014 18:54:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CCB48C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> <32055.1405614318@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> <20330.1405620169@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB40E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB40E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0-4SeV68v0GQJmr-uXLcfKK1MqA Cc: Brian Haberman , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:54:29 -0000 > > there is this gear in the middle that is failing; because it was misdes= igned. >=20 > Understood. But, I think there will be uses for IPv6 in networks > besides the public Internet where we might have a bit more control > over the type of networking gear we deploy. Let me correct myself because I don't want to exclude the case of operating over the public Internet. If a node sends a legitimate IPv6 packet that is perfectly compliant with the specs and some fragile piece of networking gear goes belly-up, whose fault is that? Thanks - Fred fred.l.templin@boeing.com From nobody Thu Jul 17 12:07:42 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F8C1A00B7 for ; Thu, 17 Jul 2014 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PikHrZxbf0q for ; Thu, 17 Jul 2014 12:04:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A577A1A0076 for ; Thu, 17 Jul 2014 12:04:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C26E20028; Thu, 17 Jul 2014 15:06:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 92D6263B0E; Thu, 17 Jul 2014 15:04:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7C2F563AED; Thu, 17 Jul 2014 15:04:49 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" Subject: Re: blanks In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB48C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53C7ED88.1060909@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0A4@XCH-BLV-504.nw.nos.boeing.com> <53C7EE9C.9000703@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB0DE@XCH-BLV-504.nw.nos.boeing.com> <53C7F2A3.3070301@innovationslab.net> <2134F8430051B64F815C691A62D9831832CCB15E@XCH-BLV-504.nw.nos.boeing.com> <53C7F6FC.7010604@innovationslab.net> <32055.1405614318@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB241@XCH-BLV-504.nw.nos.boeing.com> <20330.1405620169@sandelman.ca> <2134F8430051B64F815C691A62D9831832CCB40E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CCB48C@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6O9amFTB-AtCdQfKntcn0cBYc_E Cc: Brian Haberman , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 19:04:53 -0000 --=-=-= Templin, Fred L wrote: >> Understood. But, I think there will be uses for IPv6 in networks >> besides the public Internet where we might have a bit more control >> over the type of networking gear we deploy. > Let me correct myself because I don't want to exclude the case of > operating over the public Internet. If a node sends a legitimate IPv6 > packet that is perfectly compliant with the specs and some fragile > piece of networking gear goes belly-up, whose fault is that? Again, I'm not claiming the packet is broken; I'm agreeing that the gear is broken. The guy investigating why might wonder if the packet is sane, or if perhaps some other part of the system is corrupting it somewhere, and might benefit from reading the document. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8geT4CLcPvd0N1lAQK8IggAp9yxpXbBHAQsUjuF4s4MlQGF7em414Wx XHCbMPxoe7cHO9sAyn5XqvM+ot74LK8087nTi/P3+0XcAXj0sUwoLO3bHuDoU3qQ 0eI4tW232HZnJIpUQvUq78Fw8qa/G3XZqOiXYuCudSZ3atraPBdFqLdozSdIal5z q9AMnBb/gcfaleZ2jK9WNekgIagyCqYV32PiQ0WNPEf3O05hh/UW1ZawssKAi5Pk qPU8L0PcNxQIJcrqv0IR+qFPgIq+C1cP7tImdScsKjuynT2iG757uET8QVR9Hy8P +3rKBJJzXzeDGSBz8vAAceLQUcv0sUWMIN9uKP0MJnHFkmmFFnCDJw== =J1fz -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 21 04:53:21 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F24E1B2DA4; Mon, 21 Jul 2014 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxpx1uCSP8WV; Mon, 21 Jul 2014 04:53:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F751B2D4A; Mon, 21 Jul 2014 04:53:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-enhanced-dad-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721115314.11808.40913.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 04:53:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Z7x5tAKTu346Xyfpq6jv1RCfcJM Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:53:16 -0000 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 : Enhanced Duplicate Address Detection Authors : Rajiv Asati Hemant Singh Wes Beebee Carlos Pignataro Eli Dart Wes George Filename : draft-ietf-6man-enhanced-dad-06.txt Pages : 12 Date : 2014-07-21 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-enhanced-dad-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 04:55:54 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870291B2DA4; Mon, 21 Jul 2014 04:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pytdd7INJCtN; Mon, 21 Jul 2014 04:55:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963DA1B2D53; Mon, 21 Jul 2014 04:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2717; q=dns/txt; s=iport; t=1405943751; x=1407153351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MpHY5KpNPU83ajScwuwG8S7kWIm/IiffVq+ivMf3zP4=; b=f559MPPG1BKUI6LiCp2NIejJUGDfoKT4cjat1v4mGV3TBOLK1yCJHmHP F++atmRxHMj0m4/qMaB7wTOO9JKcdHyrha6U1YMIvl7ebGqvUHyYbY6FV NW4H930welBWwz+bMoUcI2HMhxoG4/QhL1ap/0DctBIjfHXFRrunAobDn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAHP+zFOtJA2L/2dsb2JhbABZgw5SUwjFIAqHRQGBGhZ2hAMBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAYg5CAW+ZBePGjEHBoMogRgFhXOWf5Jig0RsgUU X-IronPort-AV: E=Sophos;i="5.01,700,1400025600"; d="scan'208";a="62633513" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 21 Jul 2014 11:55:50 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6LBtnxJ015010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 11:55:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 06:55:49 -0500 From: "Hemant Singh (shemant)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-06.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-06.txt Thread-Index: AQHPpNpz5GleYb9DzUagmy1uEu1uspuqa0OQ Date: Mon, 21 Jul 2014 11:55:48 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8915574B5C@xmb-rcd-x06.cisco.com> References: <20140721115314.11808.40913.idtracker@ietfa.amsl.com> In-Reply-To: <20140721115314.11808.40913.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5JhD3cBRa0WGYc0nYXp-zY2A-fk Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:55:52 -0000 This version of the document has addressed all comments from Eric Vyncke du= ring the Last Call. Other editorial cleanup was also done in this version. Thanks, Hemant -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Monday, July 21, 2014 7:53 AM To: i-d-announce@ietf.org Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-enhanced-dad-06.txt 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 IET= F. Title : Enhanced Duplicate Address Detection Authors : Rajiv Asati Hemant Singh Wes Beebee Carlos Pignataro Eli Dart Wes George Filename : draft-ietf-6man-enhanced-dad-06.txt Pages : 12 Date : 2014-07-21 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-enhanced-dad-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Mon Jul 21 08:04:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218221A00A7 for ; Mon, 21 Jul 2014 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSEW24Khf-64 for ; Mon, 21 Jul 2014 08:04:38 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8601A01D6 for ; Mon, 21 Jul 2014 08:04:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s6LF42iH011995 for ; Mon, 21 Jul 2014 17:04:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28C16208C96 for ; Mon, 21 Jul 2014 17:06:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 15B7E208C67 for ; Mon, 21 Jul 2014 17:06:38 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s6LF3tku031680 for ; Mon, 21 Jul 2014 17:04:02 +0200 Message-ID: <53CD2BDB.3010409@gmail.com> Date: Mon, 21 Jul 2014 17:03:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: blanks References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/eOQO4OEAM6znLPUQBsKsnpCTLs8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:04:40 -0000 Le 17/07/2014 17:29, Templin, Fred L a crit : > Hi, > > Sometimes, an IPv6 node may have nothing useful to say but wants > to make a little noise anyway. In those cases, it should be able > to fire off a "blank" that gets through the network to the final > destination but then gets dropped at the destination's doorstep. > Here, I define a blank as any IPv6 packet that contains the value > "No Next Header" in the ultimate (i.e., outermost) Next Header > field. And if there is no extension header this 'blank' would be the smallest possible legitimate IPv6 packet. In constrained environments often there is need of the smallest such packet but still to carry some 1byte data. Or otherwise just the smallest possible heartbeats needed in applications such as VPN, NAT state maintenance. > The IPv6 input process of the destination will receive the > packet and delete it once it sees that there is no upper layer > header following the IPv6 header. > > > As I said, on the surface all this does is makes a little noise. > But in some cases, useful information can be conveyed such as in > a Destination Option. Is it worth writing a little 2-3 page > informational document describing this? I think it's always worth writing an Internet Draft. Alex > > Thanks - Fred > fred.l.templin@boeing.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From nobody Mon Jul 21 15:19:55 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7751A0135 for ; Mon, 21 Jul 2014 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4k1G1fC7mqu for ; Mon, 21 Jul 2014 15:19:51 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36E21A00C6 for ; Mon, 21 Jul 2014 15:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s6LMJpbb014163; Mon, 21 Jul 2014 15:19:51 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s6LMJfoP014030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Jul 2014 15:19:41 -0700 Received: from XCH-BLV-102.nw.nos.boeing.com (2002:82f7:1975::82f7:1975) by XCH-PHX-212.sw.nos.boeing.com (2002:82f7:198d::82f7:198d) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Jul 2014 15:19:41 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.173]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.194]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 15:19:40 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "ipv6@ietf.org" Subject: RE: blanks Thread-Topic: blanks Thread-Index: Ac+h0+kZOOY0i7sTScW/FzRDCGImuwDW8DWAAAByHoA= Date: Mon, 21 Jul 2014 22:19:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CD0179@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CCB04F@XCH-BLV-504.nw.nos.boeing.com> <53CD2BDB.3010409@gmail.com> In-Reply-To: <53CD2BDB.3010409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/TS7abNl5zexwHuLnBvL920QIpsk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:19:53 -0000 Hi Alex, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Monday, July 21, 2014 8:04 AM > To: ipv6@ietf.org > Subject: Re: blanks >=20 > Le 17/07/2014 17:29, Templin, Fred L a =E9crit : > > Hi, > > > > Sometimes, an IPv6 node may have nothing useful to say but wants > > to make a little noise anyway. In those cases, it should be able > > to fire off a "blank" that gets through the network to the final > > destination but then gets dropped at the destination's doorstep. > > Here, I define a blank as any IPv6 packet that contains the value > > "No Next Header" in the ultimate (i.e., outermost) Next Header > > field. >=20 > And if there is no extension header this 'blank' would be the smallest > possible legitimate IPv6 packet. Right. > In constrained environments often there is need of the smallest such > packet but still to carry some 1byte data. >=20 > Or otherwise just the smallest possible heartbeats needed in > applications such as VPN, NAT state maintenance. Small heartbeats is certainly one of the "why's" I was referring to. =20 > > The IPv6 input process of the destination will receive the > > packet and delete it once it sees that there is no upper layer > > header following the IPv6 header. > > > > > > As I said, on the surface all this does is makes a little noise. > > But in some cases, useful information can be conveyed such as in > > a Destination Option. Is it worth writing a little 2-3 page > > informational document describing this? >=20 > I think it's always worth writing an Internet Draft. I'm still not sure. Again, I would prefer a draft that focuses on "why" instead of "how". Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > -------------------------------------------------------------------- > > 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 nobody Tue Jul 22 03:00:36 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C989C1A064A for ; Tue, 22 Jul 2014 03:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqWRhhMMExq0 for ; Tue, 22 Jul 2014 03:00:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756621A032A for ; Tue, 22 Jul 2014 03:00:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s6MA0SUq010746 for ; Tue, 22 Jul 2014 12:00:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 605862042DD for ; Tue, 22 Jul 2014 12:03:05 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4E1132042F2 for ; Tue, 22 Jul 2014 12:03:05 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s6MA048Q031549 for ; Tue, 22 Jul 2014 12:00:28 +0200 Message-ID: <53CE3624.3040007@gmail.com> Date: Tue, 22 Jul 2014 12:00:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ipv Subject: updated draft-petrescu-autoconf-ra-based-routing-05.txt - RAs for routing between moving networks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/kYh1bTc9bSAJWEuCmvmDxe-BJwM X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 10:00:34 -0000 Hello, We have updated the draft "RAs for routing between moving networks" http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-05 This draft describes an extension to be carried by RAs containing IP prefixes to be exchanged between mobile routers ('exchanged' - as opposed to 'announcing' prefixes active on links). The implementation of this extension allows 1-hop neighboring vehicles to establish IP paths between any pair of onboard IP-addressable devices; one potential application is a live videostream sent by an IP camera in a large vehicle to an IP display in the following vehicle, to help during view-obstructing situations. This -05 update is minor - just added a reference to another draft which may present similarities. Alex From nobody Tue Jul 22 14:09:49 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1F1B2831 for ; Tue, 22 Jul 2014 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deYBLVZIsLY8 for ; Tue, 22 Jul 2014 14:09:44 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA7B1A0183 for ; Tue, 22 Jul 2014 14:09:44 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 1EAAB6109; Tue, 22 Jul 2014 14:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=+2y8Cg7a9Q2rVzatwFaqd amsitg=; b=omiehyUYe8y2OlE/XjQoC8W3qKf57oh9KknW8OIKn5wKArwOqKUC/ xhX3xSP4IzKSg7APCygJxPVUjneIyRAkOMGTpL0+kO8wX01oOPANqNQ2MfLDzLK3 lS1p0aB9WSw/1hKrXUgnQkUVjMH/8pxoRUgVcnhz5EYAigT5zIqwm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=FFRqlSzOPW6nSkl i/1mIxWDRAOPG/5deik0lMlPIMQOiSzqCek8JaegarK5m7d3hcbX8AGcVgI+D/y3 5EkxgMsTpiXJN1WtyJ7TYb8uPRPq5u6n3iNAkH6BBnh8fFuCZ+K8cKLNsHwBsQZL on4oOQU5/soG1X9prUp6ueC/qCEo= Received: from dhcp-10-61-105-11.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A1C7D5FF7; Tue, 22 Jul 2014 14:09:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2D4EDFA6-E0F0-484D-8F5B-EC86ED046DA5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: <53A4AE11.5040900@ericsson.com> Date: Tue, 22 Jul 2014 17:09:33 -0400 Message-Id: References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/rNMVPY_y4HvWuTjH52PoMcmLIdY Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:09:46 -0000 --Apple-Mail=_2D4EDFA6-E0F0-484D-8F5B-EC86ED046DA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Suresh, et al, to pick up this after my holiday. >>> My impression from the discussion in London that the consensus was = closer to (2) than (1) - that on such links the hosts should be allowed = to restart transmissions in a reasonable / rate-limited manner, when = connectivity parameters expire. And that we should add MAY text for = that. >>=20 >> that's also fine with me. if there was a text proposal it would most = likely be easier for the working group to come to a decision. >> is that something the authors can take on? >=20 > In my view, the text in the draft already reflects something akin to = what Dmitry was talking about (but not exactly option 2 from your = original mail on this thread). This is the relevant text from the draft. > Hosts MAY continue retransmitting the RSs even after router discovery = is successful. If the host continues to retransmit RSs, it is = RECOMMENDED that such retransmissions be rate-limited to one every MRT. the current text states: hosts SHOULD stop, but MAY continue. on a link where there are no periodic multicast RA, then all the hosts = that doesn't implement the MAY will fail after the initial Router = lifetime seconds. to me it appears we have two options. 1) only solve the initial connection case. remove any mention of links without periodic RAs (remove the last = sentence of the abstract, and bullet 1b.). possibly remove the MAY in the "SHOULD stop, but MAY continue" advance the document to the IESG=20 2) take the document back to the WG and solve the problems that Erik = outlined in his mail. cheers, Ole --Apple-Mail=_2D4EDFA6-E0F0-484D-8F5B-EC86ED046DA5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTztMNAAoJEFuJXizso86g/XIIAM8G5IcIOsEsHYBhobk2DSyI IJAjvovUHSG2hdqxzADE7fdmJc/EPbA2vpoBgj8BBypqQXW6to1efk7Iy+PBmMFl w0TAAw1uPjXrCShheTeZSGP6kUmqtsbEmHTJbe8IlQxYGHc1O6g6kyQ2S9PVdw2S IuqmqbJj/9troF5OUEs59xy7R9dnXtKc2gneKGpEV6+8Foy4z82kxazumFT7E47H bb4Y9mTQYY4shh7jrnH2i4fFGOzKoxYiQRodTY/zvusaTpXK5NpjI0TiNEOmDx0J vpf2rgnZjEJpFIjyA1/LhcYrM2s+BTadHocOOyL/95KdoLGxmhA1GnSk5UVYgxA= =Yw2a -----END PGP SIGNATURE----- --Apple-Mail=_2D4EDFA6-E0F0-484D-8F5B-EC86ED046DA5-- From nobody Tue Jul 22 18:28:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ACC1A0023 for ; Tue, 22 Jul 2014 18:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY2rqKZ7U01G for ; Tue, 22 Jul 2014 18:28:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A9A1A0012 for ; Tue, 22 Jul 2014 18:28:37 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 23 Jul 2014 01:28:35 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.92]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.92]) with mapi id 15.00.0995.011; Wed, 23 Jul 2014 01:28:35 +0000 From: Dmitry Anipko To: Ole Troan , Suresh Krishnan Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZA= Date: Wed, 23 Jul 2014 01:28:34 +0000 Message-ID: <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(189002)(199002)(51704005)(64706001)(561944003)(81542001)(20776003)(77982001)(74316001)(19580395003)(79102001)(76576001)(85852003)(106356001)(76482001)(81342001)(93886003)(83072002)(46102001)(80022001)(54356999)(50986999)(33646002)(106116001)(21056001)(87936001)(85306003)(76176999)(101416001)(105586002)(77096002)(86362001)(107046002)(83322001)(31966008)(74662001)(4396001)(99286002)(2656002)(99396002)(92566001)(19580405001)(86612001)(74502001)(95666004)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZvnOsuC7-Y-gYpHwLKe_jLkeOcw Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 01:28:39 -0000 Given the definition of MAY in RFC 2119, why is the wording, which is curre= ntly in the text, not an option? In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Where "the feature" would be e.g. "supporting links w/o periodic multicast = RAs"? -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Tuesday, July 22, 2014 2:10 PM To: Suresh Krishnan Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilient-= rs@tools.ietf.org; 6man WG Subject: Re: draft-ietf-6man-resilient-rs update Suresh, et al, to pick up this after my holiday. >>> My impression from the discussion in London that the consensus was clos= er to (2) than (1) - that on such links the hosts should be allowed to rest= art transmissions in a reasonable / rate-limited manner, when connectivity = parameters expire. And that we should add MAY text for that. >>=20 >> that's also fine with me. if there was a text proposal it would most lik= ely be easier for the working group to come to a decision. >> is that something the authors can take on? >=20 > In my view, the text in the draft already reflects something akin to what= Dmitry was talking about (but not exactly option 2 from your original mail= on this thread). This is the relevant text from the draft. > Hosts MAY continue retransmitting the RSs even after router discovery is = successful. If the host continues to retransmit RSs, it is RECOMMENDED tha= t such retransmissions be rate-limited to one every MRT. the current text states: hosts SHOULD stop, but MAY continue. on a link where there are no periodic multicast RA, then all the hosts that= doesn't implement the MAY will fail after the initial Router lifetime seco= nds. to me it appears we have two options. 1) only solve the initial connection case. remove any mention of links without periodic RAs (remove the last senten= ce of the abstract, and bullet 1b.). possibly remove the MAY in the "SHOULD stop, but MAY continue" advance the document to the IESG=20 2) take the document back to the WG and solve the problems that Erik outlin= ed in his mail. cheers, Ole From nobody Tue Jul 22 19:14:52 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE11B28D6 for ; Tue, 22 Jul 2014 19:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKGEs4u-Ncbr for ; Tue, 22 Jul 2014 19:14:50 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4841B288F for ; Tue, 22 Jul 2014 19:14:50 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2E7A46028; Tue, 22 Jul 2014 19:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=6g2RXFwqa/O5gZYu36r6y hrDqQk=; b=oQmdXayPxtlfBeMAT+Y4le62h4M1uQZGIqhk8nV4/6Pq6WVrlBVw8 dGkAl0V4NBRJ64Rz6iZggXMk+IfPqyIEuyy1dm5+UKEuHZqIg+QUEH/NGPMiQLXi C/epQ7q1AYjTQFl7DDqvvMV1+F65HbY9wtrO9kMV8eW6D8TGP7lBcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=O5wKV/Je3EBvZWG HZEKaE5ph5JtAVnz9yp+vrfZxs8UC8A8VFldpgAWpcOV85ZuMT69DYZJ6RBkEl8V JCODK6OZZRD9VXAS9cqypDCeRxFYnWuYYP+T0g4rwi5+1lVq0KtlTfnYihyDJ6a5 wHAHDq6dpYQWoFADvzMDWxLT7PEY= Received: from dhcp-10-61-104-169.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id AB52661AA; Tue, 22 Jul 2014 19:14:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3E4640F9-0A16-4B6B-B3C8-3137A8720B5A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> Date: Tue, 22 Jul 2014 22:14:41 -0400 Message-Id: <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xZcecLKcqzQfUW13kgxS39WhIBM Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:14:52 -0000 --Apple-Mail=_3E4640F9-0A16-4B6B-B3C8-3137A8720B5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dmitry, > Given the definition of MAY in RFC 2119, why is the wording, which is = currently in the text, not an option? >=20 > > In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > >=20 > Where "the feature" would be e.g. "supporting links w/o periodic = multicast RAs"? what would happen with the hosts that didn't implement the feature on = links w/o periodic multicast RAs? cheers, Ole >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Tuesday, July 22, 2014 2:10 PM > To: Suresh Krishnan > Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>; = draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Suresh, et al, >=20 > to pick up this after my holiday. >=20 >>>> My impression from the discussion in London that the consensus was = closer to (2) than (1) - that on such links the hosts should be allowed = to restart transmissions in a reasonable / rate-limited manner, when = connectivity parameters expire. And that we should add MAY text for = that. >>>=20 >>> that's also fine with me. if there was a text proposal it would most = likely be easier for the working group to come to a decision. >>> is that something the authors can take on? >>=20 >> In my view, the text in the draft already reflects something akin to = what Dmitry was talking about (but not exactly option 2 from your = original mail on this thread). This is the relevant text from the draft. >> Hosts MAY continue retransmitting the RSs even after router discovery = is successful. If the host continues to retransmit RSs, it is = RECOMMENDED that such retransmissions be rate-limited to one every MRT. >=20 > the current text states: hosts SHOULD stop, but MAY continue. > on a link where there are no periodic multicast RA, then all the hosts = that doesn't implement the MAY will fail after the initial Router = lifetime seconds. >=20 > to me it appears we have two options. > 1) only solve the initial connection case. > remove any mention of links without periodic RAs (remove the last = sentence of the abstract, and bullet 1b.). > possibly remove the MAY in the "SHOULD stop, but MAY continue" > advance the document to the IESG=20 > 2) take the document back to the WG and solve the problems that Erik = outlined in his mail. >=20 > cheers, > Ole --Apple-Mail=_3E4640F9-0A16-4B6B-B3C8-3137A8720B5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTzxqRAAoJEFuJXizso86g0NMH/3D5Z+qxnsG9sSomWZQatjsI je74BNW4AdAFHGSF1snr4NdvorcJpGwCtKWnKUMJKtuuWPYR8db+TCc24gL8wg06 qgfVxTu7I+X6p7tMwDakzvpwNVaD2XOMmujEPQwMXgbsmasCWfkF+4Q8uEWUfpIY f4ETmauQz6GymdcAkMpj/Ma5+g++231LpXQe6tCOpXbq4psRob5+A6sSgnFOQvI7 TFMzWRHq0SqA+k8GcrZ/1sNHUmfzllaCad0y9s4E+NveFH6lJ96s0ZIl5oTAs3w5 h91fXQpPzPgDifKQQicGMkE6sCeiU90gq3D80q5/dDgtU81OervSntgC0/DWo8A= =Spof -----END PGP SIGNATURE----- --Apple-Mail=_3E4640F9-0A16-4B6B-B3C8-3137A8720B5A-- From nobody Wed Jul 23 06:52:36 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF11B279E for ; Wed, 23 Jul 2014 06:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpFtTdO7nzzk for ; Wed, 23 Jul 2014 06:52:27 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9221B278A for ; Wed, 23 Jul 2014 06:52:27 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 6A2F761C9; Wed, 23 Jul 2014 06:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=Pkey34Kxs5ayK3pXOtaEK HrkP10=; b=Zwg4vCZEGF2fNPVjROuIn9HUOCUFz/ND7k2Jbz0llsvXZYkIO9GeZ 76ZP1DDSJeer0+UysHOh10ryvyNd2yhqGwdoxttEAmVuX+pE67FX/RDdtN3IxiCw uUmxC52z+qs2bT9nJkydFEh619L1A8IXhqwgMUOSeJE7mVC2FbnJX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=e2qalqUDkm7/TXB sOY4GENx2ULP4Mq+8r4KncFkoPFLxW3M3DfUYxtIMrdVUnsn2by61I43t0WgF0qO YBNoVZU7UTnrMpdFpYiMP3NtmbE4NmC6M8BHcZibdblZY3RCy/CHCLgPRVI9Y+Wk OPyTuAVK2KxwtQZzZRsCudeYHcB4= Received: from dhcp-10-61-109-95.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 61D806155; Wed, 23 Jul 2014 06:52:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C6731C71-EE50-43A8-AD4C-F4F1E052B39A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> Date: Wed, 23 Jul 2014 09:52:20 -0400 Message-Id: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> To: 6man WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0eyBZFzZZfTTQ_kaK0WEZrJyCaQ Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:52:32 -0000 --Apple-Mail=_C6731C71-EE50-43A8-AD4C-F4F1E052B39A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 All, We have received exactly zero comments on this last call. I assume this = doesn't mean that there is no support for the document, given previous = discussions. Can I ask for one or two reviewers to do a detailed review of the = document? Best regards, Ole On 20 Jun 2014, at 21:16 , Bob Hinden wrote: > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Analysis of the 64-bit Boundary in IPv6 = Addressing > Authors : Brian Carpenter > Tim Chown > Fernando Gont > Sheng Jiang > Alexandru Petrescu > Andrew Yourtchenko > Filename : draft-ietf-6man-why64-01.txt > Pages : 23 > Date : 2014-05-07 >=20 > http://tools.ietf.org/html/draft-ietf-6man-why64-01.txt >=20 > as an Informational RFC. Substantive comments and statements of = support for publishing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on July 4, 2014. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 --Apple-Mail=_C6731C71-EE50-43A8-AD4C-F4F1E052B39A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTz74VAAoJEFuJXizso86gVbAIAMtBzToMnhnPacX9pgT118QO XLU8FASo7XEz7o3uX6hD4JHvMkAHy8josWvjo00O2u1VH6yQEamWQFAFHHPuxHaC 7ELxPd2m4Y13U1HSkDoeBHjOCxT1nZXzf1UCyuQl4GP2BUyzQ4B6KrjE5fx7Xo/j WI4S+Fha8QBLCd1aMOHVaDtJ3iylom7PW5QYPc3RziYLiGYY/PHfdbXJUgIzRUjv K4FA4hHU1hJAZo/IWOaf5rw+7NJVxqD0j76hCMY9pdG7e+kZtE2dp5yAs2u0xGxB FA2ELTc4lnRzDOcj+hRYR66BBumT8ahVYybhL0sgy3m4gwLX6n7MtXD5obLvQJk= =KHXv -----END PGP SIGNATURE----- --Apple-Mail=_C6731C71-EE50-43A8-AD4C-F4F1E052B39A-- From nobody Wed Jul 23 07:12:20 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B071B286B for ; Wed, 23 Jul 2014 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLB2zw-_kqd9 for ; Wed, 23 Jul 2014 07:12:16 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991E71B29C5 for ; Wed, 23 Jul 2014 07:12:16 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2826261E9 for ; Wed, 23 Jul 2014 07:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; s= selector1; bh=3J0usxsMcuCzKwdGgEXWX8QkVOo=; b=DLSngXItoHbV7uSJsU FPuDjrxbejJ1RVLZgefw0CBy0r/Wj9WwemrTyARbx0/ZlRufe2Zt2bKHei/UO9zI qU4Z68LUURiswU1hqrcPvUKDx7F223rXr24z143IsrUjSvaTpreJEOJSbe5Xvii2 eGOzR61cR3ruKWDK0gBMJLVHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; q=dns; s= selector1; b=XCWTOL8KzNqeRHL/BrZ13IZVuDsr79iUAuQ90hgtZzQz9SD9s4M FheKG7P5DdzLMmBuml2J3ZC5pbOjqzUGgH4Pqrc9qskxSk6hSZmadIOA96OcpQ1C P/pHVwGVZi3dacwUhFEXNd4GjPOEoO3daj65fN3aj7cUvJNQBslxnGYc= Received: from dhcp-10-61-109-95.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4879061E1 for ; Wed, 23 Jul 2014 07:12:14 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_B27CF0F9-50A9-40D1-B930-627B69DB1A2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: 6MAN document status Message-Id: Date: Wed, 23 Jul 2014 10:12:11 -0400 To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FXyA42sup1mlZUJDom6xr1Jo6SM X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:12:18 -0000 --Apple-Mail=_B27CF0F9-50A9-40D1-B930-627B69DB1A2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Document state from https://datatracker.ietf.org/wg/6man/documents/ RFC-Editor: draft-ietf-6man-multicast-scopes-07 - IPv6 Multicast Address Scopes IESG: draft-ietf-6man-multicast-addr-arch-update-07 - Updates to the IPv6 = Multicast Addressing Architecture In Working Group Last call: draft-ietf-6man-resilient-rs-03 - Packet loss resiliency for Router = Solicitations (Open issues) draft-ietf-6man-why64-01 - Analysis of the 64-bit Boundary in IPv6 = Addressing (Awaiting reviewers) draft-ietf-6man-enhanced-dad-06 - Enhanced Duplicate Address Detection = (Awaiting chair action) Working group documents: draft-ietf-6man-default-iids-00 - Recommendation on Stable IPv6 = Interface Identifiers (expires soon) draft-ietf-6man-ipv6-address-generation-privacy-01 - Privacy = Considerations for IPv6 Address Generation Mechanisms draft-ietf-6man-predictable-fragment-id-01 - Security Implications of = Predictable Fragment Identification Values * For all of these I believe we are awaiting new revisions from the = authors after the discussions in London/Berlin. Drafts for which authors have requested adoption: draft-boucadair-6man-prefix-routing-reco - IPv6 Prefix Length = Recommendation for Routing Protocols draft-halpern-6man-nd-pre-resolve-addr-00 - Triggering ND Address = Resolution on Receiving DAD-NS In addition we have about 19 Active Drafts with -6man- in the file name. Best regards, Ole --Apple-Mail=_B27CF0F9-50A9-40D1-B930-627B69DB1A2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTz8K7AAoJEFuJXizso86gY0oIANO+MWZFz57RDvawUisJEn+d dORasUvWhU2ooO4hJF81bzYVy2PY2dLJOpi7jDkNQnHZSNmvie+FmpML63QccGqY BVkANIpt40dLJvGlIhOTBFKMIzgrHW+KRoFfoXGsIeh8R2JyjYhhfw6f+AdpVr/K stiqrthDpP9yjxdp5PkiRU4070yEV/toPik4dq6VsybikbZIFeV3RGnkxOgSAzc1 kVE+KCCXZ6EYXRuTFi0GtbogcknfxWWSLaSXtTcqdS7cyGNv/cwCC2n3tXsYkY8s /iTnYNZEVxBw8kGGNM+zpYWVebhsdhqlwy6dqtQVCg3g0HqgFEelCeWj/AnsStg= =F1yQ -----END PGP SIGNATURE----- --Apple-Mail=_B27CF0F9-50A9-40D1-B930-627B69DB1A2B-- From nobody Wed Jul 23 11:13:52 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72041B27A8 for ; Wed, 23 Jul 2014 11:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-Zvr92do__Y for ; Wed, 23 Jul 2014 11:13:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0400B1B28CA for ; Wed, 23 Jul 2014 11:13:37 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 23 Jul 2014 18:13:35 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) with mapi id 15.00.0995.011; Wed, 23 Jul 2014 18:13:35 +0000 From: Dmitry Anipko To: Ole Troan Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZCAAA48gIABC23Q Date: Wed, 23 Jul 2014 18:13:34 +0000 Message-ID: <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> In-Reply-To: <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(377454003)(51704005)(13464003)(80022001)(20776003)(74316001)(101416001)(64706001)(81342001)(31966008)(4396001)(83322001)(19580405001)(77982001)(81542001)(561944003)(74662001)(19580395003)(76482001)(79102001)(46102001)(107046002)(76576001)(85306003)(50986999)(86612001)(54356999)(106116001)(99286002)(95666004)(106356001)(77096002)(93886003)(105586002)(76176999)(2656002)(21056001)(86362001)(74502001)(87936001)(83072002)(99396002)(110136001)(85852003)(92566001)(33646002)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nb6yvhPtCEUmIH2ClXXf3B4A2HA Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:13:49 -0000 >> what would happen with the hosts that didn't implement the feature on li= nks w/o periodic multicast RAs? It would not get this particular improvement in behavior compared to the pr= e-draft state. But since the answer seems to be trivial, I'm not sure I und= erstood the question correctly? -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Tuesday, July 22, 2014 7:15 PM To: Dmitry Anipko Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilien= t-rs@tools.ietf.org; 6man WG Subject: Re: draft-ietf-6man-resilient-rs update Dmitry, > Given the definition of MAY in RFC 2119, why is the wording, which is cur= rently in the text, not an option? >=20 > > In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > >=20 > Where "the feature" would be e.g. "supporting links w/o periodic multicas= t RAs"? what would happen with the hosts that didn't implement the feature on links= w/o periodic multicast RAs? cheers, Ole >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Tuesday, July 22, 2014 2:10 PM > To: Suresh Krishnan > Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilien= t-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Suresh, et al, >=20 > to pick up this after my holiday. >=20 >>>> My impression from the discussion in London that the consensus was clo= ser to (2) than (1) - that on such links the hosts should be allowed to res= tart transmissions in a reasonable / rate-limited manner, when connectivity= parameters expire. And that we should add MAY text for that. >>>=20 >>> that's also fine with me. if there was a text proposal it would most li= kely be easier for the working group to come to a decision. >>> is that something the authors can take on? >>=20 >> In my view, the text in the draft already reflects something akin to wha= t Dmitry was talking about (but not exactly option 2 from your original mai= l on this thread). This is the relevant text from the draft. >> Hosts MAY continue retransmitting the RSs even after router discovery is= successful. If the host continues to retransmit RSs, it is RECOMMENDED th= at such retransmissions be rate-limited to one every MRT. >=20 > the current text states: hosts SHOULD stop, but MAY continue. > on a link where there are no periodic multicast RA, then all the hosts th= at doesn't implement the MAY will fail after the initial Router lifetime se= conds. >=20 > to me it appears we have two options. > 1) only solve the initial connection case. > remove any mention of links without periodic RAs (remove the last sente= nce of the abstract, and bullet 1b.). > possibly remove the MAY in the "SHOULD stop, but MAY continue" > advance the document to the IESG=20 > 2) take the document back to the WG and solve the problems that Erik outl= ined in his mail. >=20 > cheers, > Ole From nobody Wed Jul 23 11:44:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320501B2AB9 for ; Wed, 23 Jul 2014 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihvK8rEnij4D for ; Wed, 23 Jul 2014 11:44:32 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7C81B2BA9 for ; Wed, 23 Jul 2014 11:44:31 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so1606672wev.13 for ; Wed, 23 Jul 2014 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BK3Hoxn+N8qW3qExC7J6SpazV6invbcK2ljB++DqiGM=; b=vS9riovRCbMAZPF+nPDCbF1+sfeLa1wJS5ykgaeoN9dlctwyHLsIfLvrCAf+bx6Sxu PIMv89zEOKxtkqcmvlUyJJqwvsvraBWmpJwqCubBj+FS0Aa2TUtuBxsyBZ9Ul/53tJMe A3v1tQo2yCItUIlrVXV3KNXdCYexzNO9PJKqRKOeBqXNDedGRYJM6tzL3wvyi+tH3tBk NjHuNz/vImohUuNwvU7A10uRFV2b1eJuM8Nu7bHACxz/1NL37Lzxg5fuqnZzPjhkuIPV i/502Sasfj8z0qA7FUIUlNt+hcbnZpHj2loaeblQ6UjORyWQeitSc7c6hhC8j/Fb451E sNgg== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr4376258wjb.87.1406141068585; Wed, 23 Jul 2014 11:44:28 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.108.166 with HTTP; Wed, 23 Jul 2014 11:44:28 -0700 (PDT) In-Reply-To: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> Date: Wed, 23 Jul 2014 11:44:28 -0700 X-Google-Sender-Auth: 09fFmuhI4qS_9-AAjHYDszVw9rQ Message-ID: Subject: Re: 6MAN WG Last Call: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/HdWblyTL2-RlPXGF0LL-3S9T4P8 Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:44:35 -0000 At Wed, 23 Jul 2014 09:52:20 -0400, Ole Troan wrote: > We have received exactly zero comments on this last call. I assume this doesn't mean that there is no support for the document, given previous discussions. > > Can I ask for one or two reviewers to do a detailed review of the document? I've just read the latest version of the draft. It's well written and useful. I also confirmed my own comments on the previous version were addressed properly. I think it's ready for publication. A couple of very minor editorial comments: - In section 3.4, this one-sentence paragraph seems a bit awkward Hosts would likely use DHCPv6, or be manually configured with addresses. Maybe the intent was it's part of the previous paragraph, explaining that DHCPv6/manual config would be used in such a situation? If so, it makes sense, but I think it's better to say so clearly and explicitly. - In Section 4.2: s/how to/of how to/? [RFC3972] has defined a detailed algorithm how to generate 64-bit interface identifier from a public key and a 64-bit subnet prefix. -- JINMEI, Tatuya From nobody Wed Jul 23 14:38:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC011A0B00; Wed, 23 Jul 2014 14:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdTzbgNW9hbG; Wed, 23 Jul 2014 14:38:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323631A03E3; Wed, 23 Jul 2014 14:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=414; q=dns/txt; s=iport; t=1406151520; x=1407361120; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cIDt53yTCxAPRkvZDpXQEuiWMhG55wbVYTg28H63uko=; b=VTvIGU9kHZdqvoGOg7ML/x/Wo2WJH3rtS1MPdJ6ZBF6kKWfwV1zoIvuj PBYyqeCXXTnwCRmWOieph+OnW8gXnWc8Hgg4O815Kzr+YCdd4puFGUazH Op2S0YqKrHCgxPveE6Yx1BbkbCgjC5WY/cURiJtnTlxwFBV9iwFw9UDDh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAM8q0FOtJA2I/2dsb2JhbABZgw6BLdF8FnaECjpRAT5CJwQBiFTARReTAIEYBZstlECDSIIx X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="342369137" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jul 2014 21:38:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NLcdsS007505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 21:38:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 16:38:39 -0500 From: "Stefano Previdi (sprevidi)" To: 6man , "spring@ietf.org" Subject: SR-IPv6 in Toronto - IETF90 - Bits-n-Bites Thread-Topic: SR-IPv6 in Toronto - IETF90 - Bits-n-Bites Thread-Index: AQHPpr53UCNBwrpo+kyVg/ncn/sMDw== Date: Wed, 23 Jul 2014 21:38:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E5DEA671F43D04AA84AD0A7AE0C4726@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/zrEmccpdQhfS4j0LZOBaOkPZodc X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:38:43 -0000 Anyone in Toronto and interested into segment routing for ipv6, feel=20 free to come in the Concert Hall on thursday 1845-2100 EDT and attend=20 the interoperability demo between multiple SR-IPv6 implementations:=20 Cisco, Comcast, Ecole Polytechnique (Paris), Universite Catholique de=20 Louvain (LLN, Belgium).=20 Implementations are based on draft-previdi-6man-segment-routing-header-01. Thanks. s. From nobody Wed Jul 23 18:56:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B41A03B1 for ; Wed, 23 Jul 2014 18:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNCsDIQfZSQt for ; Wed, 23 Jul 2014 18:56:22 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2201A0305 for ; Wed, 23 Jul 2014 18:56:21 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id b6so1437879yha.36 for ; Wed, 23 Jul 2014 18:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=S9Frf4nCYn91O4pqODOBelfLKkUHsif2ZqDIdhNTvZc=; b=AHa5Km/cCXbJ4ma5d7HJzZhY0UmNGTuru/GHAh9ipSp+/+KeIYQw5jHqNGyKxzHZLu XKOrZIshzoQBkLLCT3cUTNYhk+Yuq11l+VJGj0SDam00GuwPW+c/2RiJl2se4Azkac9k 3XqPIXHTdq7BhzSfALBoFjADWi05L/DvIks0HqdxjAAuL/DbqSUUm80On05aWGUmgcy1 lXm0p7+Znx6lthoPPas87j5izFtVB2Lp1Ef+ttehehfRqR4BEtAfNDw+ovu4deRQwbGD SvsZZ8+4K3FC/0A6my8W6Bkv2cZ5w9aZqNzMrtk3C0WfHtomDQLxM2U4Avng2ARHYVhm Pz8g== MIME-Version: 1.0 X-Received: by 10.236.98.40 with SMTP id u28mr7411133yhf.9.1406166981206; Wed, 23 Jul 2014 18:56:21 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.170.224.66 with HTTP; Wed, 23 Jul 2014 18:56:21 -0700 (PDT) In-Reply-To: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> Date: Wed, 23 Jul 2014 18:56:21 -0700 X-Google-Sender-Auth: x_x1cgcCpT9PyLNgor1btGmI3kM Message-ID: Subject: Re: 6MAN WG Last Call: From: Matthew Petach To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=089e01537f4668ea8d04fee6c35e Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/tjwm5GsBycH81If055q15AAgK3Y Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 01:56:24 -0000 --089e01537f4668ea8d04fee6c35e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 23, 2014 at 11:44 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > > - In Section 4.2: s/how to/of how to/? > > [RFC3972] has defined a detailed algorithm how to generate 64-bit > interface identifier from a public key and a 64-bit subnet prefix. > A minor grammar nitpick; "of how to" would not be as well structured a sentence as you would instead get using "showing how to", as in: [RFC3972] has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. (sorry, I just get fussy about language usage sometimes. ^_^;) Thanks! :) Matt > > -- > JINMEI, Tatuya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --089e01537f4668ea8d04fee6c35e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 23, 2014 at 11:44 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 <jinmei@wide.ad.jp> wrote:


- In Section 4.2: s/how to/of how to/?

=C2=A0 =C2=A0 =C2=A0 [RFC3972] has defined a detailed algorithm how to gene= rate 64-bit
=C2=A0 =C2=A0 =C2=A0 interface identifier from a public key and a 64-bit su= bnet prefix.


A min= or grammar nitpick; "of how to" would not be as well
structured a sentence as you would instead get using=C2=A0
"showing how to", as in:

=C2=A0=C2=A0=C2=A0 =C2=A0 [RFC3972] has defined a detailed algorith= m showing how to generate=C2=A0
=C2=A0 =C2=A0 =C2=A0 a 64-b= it=C2=A0interface identifier from a public key and a 64-bit subnet prefix.<= /div>

(sorry, I just get fussy about language usa= ge sometimes. =C2=A0^_^;)

Thanks! =C2= =A0:)

Matt

=C2=A0

--
JINMEI, Tatuya

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


--089e01537f4668ea8d04fee6c35e-- From nobody Wed Jul 23 20:01:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D88F1A0282 for ; Wed, 23 Jul 2014 20:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8O3RRiVXFtO for ; Wed, 23 Jul 2014 20:01:34 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB66E1A0154 for ; Wed, 23 Jul 2014 20:01:34 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 7FA1361D1; Wed, 23 Jul 2014 20:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=FUcwluwdXQ7o5EtEIryYC OZiQq8=; b=XLaiwaCZ6A6B28MkqE/XpVW9wBpb1/qRfoiF9EZmmtem6wLm4z7rC 5zTlmZOWtighCF1ToVzjJk/Kflka2QIDV634S8A/foWyucVrLfLMm6IhTP6cT+HO vJbBPqDNujhm2e1tE96lU1Bcjvkofr20LpmZ0eObL5tIULwmoEVzr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=JQ3snv/0zPVcFab qoIPwzsErZCZQvHmKIV6+f0em7r3wqXyo1+10vsimyVLc9axwBs1g2VQFNJHi5Zt 3pkepf69mackYa1U/E1et1im0O1cjx3FkcNTKDLvWUs+mB6cDu+ixKd7lQBsIKOV vm187g2SJls4BPNV2LAsrPIrYbhg= Received: from dhcp-10-61-102-188.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 9DC2061D5; Wed, 23 Jul 2014 20:01:27 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7DDD3DDE-D597-472E-AA1D-2ABC5FECA750"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> Date: Wed, 23 Jul 2014 23:01:19 -0400 Message-Id: References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/aBydKOulTKUJjJM4UG_lUI4WvT0 Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 03:01:36 -0000 --Apple-Mail=_7DDD3DDE-D597-472E-AA1D-2ABC5FECA750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dmitry, >>> what would happen with the hosts that didn't implement the feature = on links w/o periodic multicast RAs? >=20 > It would not get this particular improvement in behavior compared to = the pre-draft state. But since the answer seems to be trivial, I'm not = sure I understood the question correctly? wouldn't those hosts initially do router discovery, then not ever send = RS again, and would be left without a default router when the router = lifetime expired? cheers, Ole >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Tuesday, July 22, 2014 7:15 PM > To: Dmitry Anipko > Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; = draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Dmitry, >=20 >> Given the definition of MAY in RFC 2119, why is the wording, which is = currently in the text, not an option? >>=20 >> >> In the >> same vein an implementation which does include a particular option >> MUST be prepared to interoperate with another implementation which >> does not include the option (except, of course, for the feature the >> option provides.) >> >>=20 >> Where "the feature" would be e.g. "supporting links w/o periodic = multicast RAs"? >=20 > what would happen with the hosts that didn't implement the feature on = links w/o periodic multicast RAs? >=20 > cheers, > Ole >=20 >>=20 >> -----Original Message----- >> From: Ole Troan [mailto:otroan@employees.org]=20 >> Sent: Tuesday, July 22, 2014 2:10 PM >> To: Suresh Krishnan >> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>; = draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >> Subject: Re: draft-ietf-6man-resilient-rs update >>=20 >> Suresh, et al, >>=20 >> to pick up this after my holiday. >>=20 >>>>> My impression from the discussion in London that the consensus was = closer to (2) than (1) - that on such links the hosts should be allowed = to restart transmissions in a reasonable / rate-limited manner, when = connectivity parameters expire. And that we should add MAY text for = that. >>>>=20 >>>> that's also fine with me. if there was a text proposal it would = most likely be easier for the working group to come to a decision. >>>> is that something the authors can take on? >>>=20 >>> In my view, the text in the draft already reflects something akin to = what Dmitry was talking about (but not exactly option 2 from your = original mail on this thread). This is the relevant text from the draft. >>> Hosts MAY continue retransmitting the RSs even after router = discovery is successful. If the host continues to retransmit RSs, it is = RECOMMENDED that such retransmissions be rate-limited to one every MRT. >>=20 >> the current text states: hosts SHOULD stop, but MAY continue. >> on a link where there are no periodic multicast RA, then all the = hosts that doesn't implement the MAY will fail after the initial Router = lifetime seconds. >>=20 >> to me it appears we have two options. >> 1) only solve the initial connection case. >> remove any mention of links without periodic RAs (remove the last = sentence of the abstract, and bullet 1b.). >> possibly remove the MAY in the "SHOULD stop, but MAY continue" >> advance the document to the IESG=20 >> 2) take the document back to the WG and solve the problems that Erik = outlined in his mail. >>=20 >> cheers, >> Ole --Apple-Mail=_7DDD3DDE-D597-472E-AA1D-2ABC5FECA750 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0HcAAAoJEFuJXizso86g5TMIANIJdqADsCDUJaXUI0JH6Gll vMco1kk+PNogulSblxKeaw1j41D2oCTOFc+Tj7KCkk/6X/K2maIH59Jkk7PbqlcO dynrZ/pmVBkkFH43y5wEU5+i1Xw2pNLi+n/flkZsQoR2GvGhDwd3hJNfSNR2zzQB 5EWUffmYWIbMh2aQhw+D2JTkVsqhnVbANg7RTFogD9mn23RHwVJ9UkAe8lBFjP+Y qYuDqxTzqCw8W8EGUKRiNsJfE8PWqpPMUdUMhWUNooR+HKU7KtQFEFzjtkhFgimh prT1ix4RWK4ewNpoJGsN6mlOphaPf9AtkIyDR3h9bFnw1leoyUEWpb93UBiC1jM= =GZV6 -----END PGP SIGNATURE----- --Apple-Mail=_7DDD3DDE-D597-472E-AA1D-2ABC5FECA750-- From nobody Thu Jul 24 18:06:12 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029EC1A0190 for ; Thu, 24 Jul 2014 18:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ-aOcA19R3g for ; Thu, 24 Jul 2014 18:06:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2C81A0360 for ; Thu, 24 Jul 2014 18:06:07 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.995.11; Fri, 25 Jul 2014 01:06:05 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) with mapi id 15.00.0995.011; Fri, 25 Jul 2014 01:06:05 +0000 From: Dmitry Anipko To: Ole Troan Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZCAAA48gIABC23QgACT74CAAW614A== Date: Fri, 25 Jul 2014 01:06:05 +0000 Message-ID: <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(189002)(199002)(13464003)(377454003)(101416001)(81542001)(76482001)(99286002)(46102001)(4396001)(76576001)(105586002)(106116001)(74662001)(95666004)(85306003)(83072002)(21056001)(77096002)(86612001)(85852003)(80022001)(106356001)(19580395003)(76176999)(74316001)(2656002)(107046002)(110136001)(20776003)(64706001)(81342001)(92566001)(77982001)(79102001)(561944003)(87936001)(74502001)(50986999)(54356999)(93886003)(83322001)(99396002)(19580405001)(31966008)(33646002)(86362001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/d0aWFs9Hb5y-pcWMXeNzl7weR9Q Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:06:11 -0000 >> wouldn't those hosts initially do router discovery, then not ever send R= S again, and would be left without a default router when the router lifetim= e expired? Assuming there are no other events, such as media state change - correct, a= nd that's the behavior they get today. As I understand it, this MAY is abou= t a specific behavior improvement, compared to the today state, which a ven= dor may choose to implement. -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Wednesday, July 23, 2014 8:01 PM To: Dmitry Anipko Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilien= t-rs@tools.ietf.org; 6man WG Subject: Re: draft-ietf-6man-resilient-rs update Dmitry, >>> what would happen with the hosts that didn't implement the feature on l= inks w/o periodic multicast RAs? >=20 > It would not get this particular improvement in behavior compared to the = pre-draft state. But since the answer seems to be trivial, I'm not sure I u= nderstood the question correctly? wouldn't those hosts initially do router discovery, then not ever send RS a= gain, and would be left without a default router when the router lifetime e= xpired? cheers, Ole >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Tuesday, July 22, 2014 7:15 PM > To: Dmitry Anipko > Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20 > draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Dmitry, >=20 >> Given the definition of MAY in RFC 2119, why is the wording, which is cu= rrently in the text, not an option? >>=20 >> >> In the >> same vein an implementation which does include a particular option =20 >> MUST be prepared to interoperate with another implementation which =20 >> does not include the option (except, of course, for the feature the =20 >> option provides.) >>=20 >> Where "the feature" would be e.g. "supporting links w/o periodic multica= st RAs"? >=20 > what would happen with the hosts that didn't implement the feature on lin= ks w/o periodic multicast RAs? >=20 > cheers, > Ole >=20 >>=20 >> -----Original Message----- >> From: Ole Troan [mailto:otroan@employees.org] >> Sent: Tuesday, July 22, 2014 2:10 PM >> To: Suresh Krishnan >> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;=20 >> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >> Subject: Re: draft-ietf-6man-resilient-rs update >>=20 >> Suresh, et al, >>=20 >> to pick up this after my holiday. >>=20 >>>>> My impression from the discussion in London that the consensus was cl= oser to (2) than (1) - that on such links the hosts should be allowed to re= start transmissions in a reasonable / rate-limited manner, when connectivit= y parameters expire. And that we should add MAY text for that. >>>>=20 >>>> that's also fine with me. if there was a text proposal it would most l= ikely be easier for the working group to come to a decision. >>>> is that something the authors can take on? >>>=20 >>> In my view, the text in the draft already reflects something akin to wh= at Dmitry was talking about (but not exactly option 2 from your original ma= il on this thread). This is the relevant text from the draft. >>> Hosts MAY continue retransmitting the RSs even after router discovery i= s successful. If the host continues to retransmit RSs, it is RECOMMENDED t= hat such retransmissions be rate-limited to one every MRT. >>=20 >> the current text states: hosts SHOULD stop, but MAY continue. >> on a link where there are no periodic multicast RA, then all the hosts t= hat doesn't implement the MAY will fail after the initial Router lifetime s= econds. >>=20 >> to me it appears we have two options. >> 1) only solve the initial connection case. >> remove any mention of links without periodic RAs (remove the last sente= nce of the abstract, and bullet 1b.). >> possibly remove the MAY in the "SHOULD stop, but MAY continue" >> advance the document to the IESG >> 2) take the document back to the WG and solve the problems that Erik out= lined in his mail. >>=20 >> cheers, >> Ole From nobody Thu Jul 24 20:24:50 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060051A0A6D for ; Thu, 24 Jul 2014 20:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSkbFTOHLdhE for ; Thu, 24 Jul 2014 20:24:46 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F09E1A0538 for ; Thu, 24 Jul 2014 20:24:46 -0700 (PDT) Received: from dhcp-10-61-104-80.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id C5200608E; Thu, 24 Jul 2014 20:24:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EA07D05D-4C06-47E6-86CB-9192ECC52522"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> Date: Thu, 24 Jul 2014 23:24:38 -0400 Message-Id: References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/azB4SoK5PX8ji1VEq4Nb015j9ew Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 03:24:48 -0000 --Apple-Mail=_EA07D05D-4C06-47E6-86CB-9192ECC52522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> wouldn't those hosts initially do router discovery, then not ever = send RS again, and would be left without a default router when the = router lifetime expired? >=20 > Assuming there are no other events, such as media state change - = correct, and that's the behavior they get today. As I understand it, = this MAY is about a specific behavior improvement, compared to the today = state, which a vendor may choose to implement. today, links without periodic RAs are not supported. cheers, Ole > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Wednesday, July 23, 2014 8:01 PM > To: Dmitry Anipko > Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; = draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Dmitry, >=20 >>>> what would happen with the hosts that didn't implement the feature = on links w/o periodic multicast RAs? >>=20 >> It would not get this particular improvement in behavior compared to = the pre-draft state. But since the answer seems to be trivial, I'm not = sure I understood the question correctly? >=20 > wouldn't those hosts initially do router discovery, then not ever send = RS again, and would be left without a default router when the router = lifetime expired? >=20 > cheers, > Ole >=20 >=20 >>=20 >>=20 >> -----Original Message----- >> From: Ole Troan [mailto:otroan@employees.org] >> Sent: Tuesday, July 22, 2014 7:15 PM >> To: Dmitry Anipko >> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20 >> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >> Subject: Re: draft-ietf-6man-resilient-rs update >>=20 >> Dmitry, >>=20 >>> Given the definition of MAY in RFC 2119, why is the wording, which = is currently in the text, not an option? >>>=20 >>> >>> In the >>> same vein an implementation which does include a particular option =20= >>> MUST be prepared to interoperate with another implementation which =20= >>> does not include the option (except, of course, for the feature the =20= >>> option provides.) >>>=20 >>> Where "the feature" would be e.g. "supporting links w/o periodic = multicast RAs"? >>=20 >> what would happen with the hosts that didn't implement the feature on = links w/o periodic multicast RAs? >>=20 >> cheers, >> Ole >>=20 >>>=20 >>> -----Original Message----- >>> From: Ole Troan [mailto:otroan@employees.org] >>> Sent: Tuesday, July 22, 2014 2:10 PM >>> To: Suresh Krishnan >>> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;=20 >>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >>> Subject: Re: draft-ietf-6man-resilient-rs update >>>=20 >>> Suresh, et al, >>>=20 >>> to pick up this after my holiday. >>>=20 >>>>>> My impression from the discussion in London that the consensus = was closer to (2) than (1) - that on such links the hosts should be = allowed to restart transmissions in a reasonable / rate-limited manner, = when connectivity parameters expire. And that we should add MAY text for = that. >>>>>=20 >>>>> that's also fine with me. if there was a text proposal it would = most likely be easier for the working group to come to a decision. >>>>> is that something the authors can take on? >>>>=20 >>>> In my view, the text in the draft already reflects something akin = to what Dmitry was talking about (but not exactly option 2 from your = original mail on this thread). This is the relevant text from the draft. >>>> Hosts MAY continue retransmitting the RSs even after router = discovery is successful. If the host continues to retransmit RSs, it is = RECOMMENDED that such retransmissions be rate-limited to one every MRT. >>>=20 >>> the current text states: hosts SHOULD stop, but MAY continue. >>> on a link where there are no periodic multicast RA, then all the = hosts that doesn't implement the MAY will fail after the initial Router = lifetime seconds. >>>=20 >>> to me it appears we have two options. >>> 1) only solve the initial connection case. >>> remove any mention of links without periodic RAs (remove the last = sentence of the abstract, and bullet 1b.). >>> possibly remove the MAY in the "SHOULD stop, but MAY continue" >>> advance the document to the IESG >>> 2) take the document back to the WG and solve the problems that Erik = outlined in his mail. >>>=20 >>> cheers, >>> Ole --Apple-Mail=_EA07D05D-4C06-47E6-86CB-9192ECC52522 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0c32AAoJEFuJXizso86gzL4IANAhfGW3/VQR7j3HqjXysUxY FTgKYZ7F2PYmb4rJgE04G5gp4w8NRqRiNC5E7BVHF5FJCPkSqSXORufk2i3Q1CJE IXFMpw9yguuJ+XsZldP/zXj+ZCn3XXwrIHtGDdLbkRi0ufGbIiDQ3psgF5Wjoebh 2DdQZ6ixuwJbHoeIPOFyj37q33448zJuI2khplLpPewBSt+p12dwdKH5oZdfMugE nuX1Si/Z2r4MvuOC1rw7NqggQYJHdmRD8S1BXyIAxa1KnvMI/nVT/HRae/LgbdF+ bZIMAxUvfwZGv1ZmpnRzWNbPWau4JMtR8epdid2k/6Qay4kI1xbo6kDSsx3GNRo= =6JB2 -----END PGP SIGNATURE----- --Apple-Mail=_EA07D05D-4C06-47E6-86CB-9192ECC52522-- From nobody Fri Jul 25 17:21:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A611A0A91 for ; Fri, 25 Jul 2014 17:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFHuKUUozafl for ; Fri, 25 Jul 2014 17:21:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B7A1A0657 for ; Fri, 25 Jul 2014 17:21:20 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.995.11; Sat, 26 Jul 2014 00:21:18 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) with mapi id 15.00.0995.011; Sat, 26 Jul 2014 00:21:18 +0000 From: Dmitry Anipko To: Ole Troan Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZCAAA48gIABC23QgACT74CAAW614IAAKiQAgAFZbSA= Date: Sat, 26 Jul 2014 00:21:17 +0000 Message-ID: References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(51704005)(377454003)(55674003)(199002)(85306003)(76576001)(77096002)(50986999)(107046002)(21056001)(33646002)(561944003)(64706001)(80022001)(74316001)(76176999)(101416001)(54356999)(19580395003)(83322001)(19580405001)(77982001)(92566001)(81342001)(93886003)(95666004)(81542001)(99286002)(105586002)(46102001)(79102001)(110136001)(76482001)(106116001)(87936001)(85852003)(106356001)(99396002)(20776003)(83072002)(86612001)(2656002)(74502001)(4396001)(86362001)(31966008)(74662001)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Tppl5r1PoZqXa3a_aISyFTtR4O4 Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 00:21:23 -0000 Let's separate discussions on the substance and on what exact language we p= ut in the draft.=20 Substance wise - IMO, the change tries to reduce existing fragility of RD i= n some situations. We had very real real-world support cases with one of th= e top mobile operators in the US, where the network was not sending new RAs= before expiring the info in the initial one. Yes, this was a misconfigura= tion / bug on the network side. Yes, this is where it was eventually fixed,= and yes perhaps the support teams should not have taken as much time to fi= gure it out. But the end-users don't care about that part, and they would b= e better off in the meantime if the protocol had more resiliency against mi= sconfiguration or packet loss. Speaking for myself only, this is the scenar= io I'm concerned about. I'm sure there are others who know the "no multicas= t RAs, period" scenario better than I do, and they can speak for that. So I think it would be good to first understand, leaving specific RFC langu= age aside, whether there is consensus to improve RD reliability when the ho= st sees that previously received information has expired / about to expire.= My impression from the discussion in London was that there was such consen= sus - but perhaps I misunderstood. Letting the host do additional rate-limi= ted transmissions to solve that, to me looks like a simple and reasonable a= pproach. If you agree with that, then what's the specific concern on puttin= g that as MAY? I do disagree with the viewpoint, that because if ND use of multicast is in= efficient, let's not make any improvements to ND until multicast issue is s= olved. Yes, the multicast-related issues in general do need to be addressed= over long term. But addressing them will take time, and there are issues t= oday which end-users are hitting, for which incremental limited fixes withi= n existing framework are possible and reasonable. >> today, links without periodic RAs are not supported. Since this is a statement about today, it equally applies (or not applies),= to the option 2 you suggested and the option I suggested, so it's not a di= fferentiator. Furthermore, it basically is equivalent to option 1, which ma= kes it not an independent argument, but re-iterating option 1, and can't be= used as a differentiator there either. -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Thursday, July 24, 2014 8:25 PM To: Dmitry Anipko Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilien= t-rs@tools.ietf.org; 6man WG Subject: Re: draft-ietf-6man-resilient-rs update >>> wouldn't those hosts initially do router discovery, then not ever send = RS again, and would be left without a default router when the router lifeti= me expired? >=20 > Assuming there are no other events, such as media state change - correct,= and that's the behavior they get today. As I understand it, this MAY is ab= out a specific behavior improvement, compared to the today state, which a v= endor may choose to implement. today, links without periodic RAs are not supported. cheers, Ole > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Wednesday, July 23, 2014 8:01 PM > To: Dmitry Anipko > Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20 > draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG > Subject: Re: draft-ietf-6man-resilient-rs update >=20 > Dmitry, >=20 >>>> what would happen with the hosts that didn't implement the feature on = links w/o periodic multicast RAs? >>=20 >> It would not get this particular improvement in behavior compared to the= pre-draft state. But since the answer seems to be trivial, I'm not sure I = understood the question correctly? >=20 > wouldn't those hosts initially do router discovery, then not ever send RS= again, and would be left without a default router when the router lifetime= expired? >=20 > cheers, > Ole >=20 >=20 >>=20 >>=20 >> -----Original Message----- >> From: Ole Troan [mailto:otroan@employees.org] >> Sent: Tuesday, July 22, 2014 7:15 PM >> To: Dmitry Anipko >> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20 >> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >> Subject: Re: draft-ietf-6man-resilient-rs update >>=20 >> Dmitry, >>=20 >>> Given the definition of MAY in RFC 2119, why is the wording, which is c= urrently in the text, not an option? >>>=20 >>> >>> In the >>> same vein an implementation which does include a particular option=20 >>> MUST be prepared to interoperate with another implementation which=20 >>> does not include the option (except, of course, for the feature the=20 >>> option provides.) >>>=20 >>> Where "the feature" would be e.g. "supporting links w/o periodic multic= ast RAs"? >>=20 >> what would happen with the hosts that didn't implement the feature on li= nks w/o periodic multicast RAs? >>=20 >> cheers, >> Ole >>=20 >>>=20 >>> -----Original Message----- >>> From: Ole Troan [mailto:otroan@employees.org] >>> Sent: Tuesday, July 22, 2014 2:10 PM >>> To: Suresh Krishnan >>> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;=20 >>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG >>> Subject: Re: draft-ietf-6man-resilient-rs update >>>=20 >>> Suresh, et al, >>>=20 >>> to pick up this after my holiday. >>>=20 >>>>>> My impression from the discussion in London that the consensus was c= loser to (2) than (1) - that on such links the hosts should be allowed to r= estart transmissions in a reasonable / rate-limited manner, when connectivi= ty parameters expire. And that we should add MAY text for that. >>>>>=20 >>>>> that's also fine with me. if there was a text proposal it would most = likely be easier for the working group to come to a decision. >>>>> is that something the authors can take on? >>>>=20 >>>> In my view, the text in the draft already reflects something akin to w= hat Dmitry was talking about (but not exactly option 2 from your original m= ail on this thread). This is the relevant text from the draft. >>>> Hosts MAY continue retransmitting the RSs even after router discovery = is successful. If the host continues to retransmit RSs, it is RECOMMENDED = that such retransmissions be rate-limited to one every MRT. >>>=20 >>> the current text states: hosts SHOULD stop, but MAY continue. >>> on a link where there are no periodic multicast RA, then all the hosts = that doesn't implement the MAY will fail after the initial Router lifetime = seconds. >>>=20 >>> to me it appears we have two options. >>> 1) only solve the initial connection case. >>> remove any mention of links without periodic RAs (remove the last sente= nce of the abstract, and bullet 1b.). >>> possibly remove the MAY in the "SHOULD stop, but MAY continue" >>> advance the document to the IESG >>> 2) take the document back to the WG and solve the problems that Erik ou= tlined in his mail. >>>=20 >>> cheers, >>> Ole From nobody Tue Jul 29 01:48:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277C1A00FA for ; Tue, 29 Jul 2014 01:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKrySqJSbZnc for ; Tue, 29 Jul 2014 01:48:41 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C921A0086 for ; Tue, 29 Jul 2014 01:48:41 -0700 (PDT) Received: from dhcp-10-61-106-78.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id EAC4E6128; Tue, 29 Jul 2014 01:48:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1EE438A1-5BBF-4E0A-B77D-C113957D3DCC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: Date: Tue, 29 Jul 2014 10:48:31 +0200 Message-Id: <004AD154-0D65-4F7F-A198-61382562550A@employees.org> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uqmZzYIKtXnmr0P6wcI59BxWXhE Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 08:48:43 -0000 --Apple-Mail=_1EE438A1-5BBF-4E0A-B77D-C113957D3DCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Let's separate discussions on the substance and on what exact language = we put in the draft.=20 >=20 > Substance wise - IMO, the change tries to reduce existing fragility of = RD in some situations. We had very real real-world support cases with = one of the top mobile operators in the US, where the network was not = sending new RAs before expiring the info in the initial one. Yes, this = was a misconfiguration / bug on the network side. Yes, this is where it = was eventually fixed, and yes perhaps the support teams should not have = taken as much time to figure it out. But the end-users don't care about = that part, and they would be better off in the meantime if the protocol = had more resiliency against misconfiguration or packet loss. Speaking = for myself only, this is the scenario I'm concerned about. I'm sure = there are others who know the "no multicast RAs, period" scenario better = than I do, and they can speak for that. >=20 > So I think it would be good to first understand, leaving specific RFC = language aside, whether there is consensus to improve RD reliability = when the host sees that previously received information has expired / = about to expire. My impression from the discussion in London was that = there was such consensus - but perhaps I misunderstood. Letting the host = do additional rate-limited transmissions to solve that, to me looks like = a simple and reasonable approach. If you agree with that, then what's = the specific concern on putting that as MAY? I do agree with that. the specific concern with the MAY, is that we'll = end up with inconsistent behaviour on the link. I'd much rather that we = specified behaviour in detail. > I do disagree with the viewpoint, that because if ND use of multicast = is inefficient, let's not make any improvements to ND until multicast = issue is solved. Yes, the multicast-related issues in general do need to = be addressed over long term. But addressing them will take time, and = there are issues today which end-users are hitting, for which = incremental limited fixes within existing framework are possible and = reasonable. I think the argument made is that the issues are somewhat tangled = together.=20 >>> today, links without periodic RAs are not supported. >=20 > Since this is a statement about today, it equally applies (or not = applies), to the option 2 you suggested and the option I suggested, so = it's not a differentiator. Furthermore, it basically is equivalent to = option 1, which makes it not an independent argument, but re-iterating = option 1, and can't be used as a differentiator there either. if you made RD more resilient against packet loss, then you may end up = solving the "no periodic multicast" case as a side effect. so for the question of what to do with the resilient RS draft. there = seems to be at least three problems: 1) the initial connection problem 2) not robust enough in case of packet drop / what to do when (last) = router lifetime expires / last address expires 3) links without periodic RAs solving 2 may inadvertently solve 3. before posing the questions to the working group, let's agree on the = questions. can we ask the working group to choose between the following two = options: i) only solve problem 1 in the resilient-rs draft. which implies remove = text about no periodic RAs ii) solve both problem 1 and 2. which implies taking the document back = to the working group cheers, Ole --Apple-Mail=_1EE438A1-5BBF-4E0A-B77D-C113957D3DCC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT11/fAAoJEFuJXizso86g23sH/RNam4vbVqjiWINoKXzGuCjY s0TE0koyZDv7mYmN737vo0C4DRpPJGVFxEwejFsy0avtPbgM9t+Jt59wb1h9GjbR 9aqhEpGyxNfq3655dzap9Gs+paHHMg1oXA9T7MC6lILM1ZM0IrLCy/1vlgFdEIyb cAo9AlGXPEazF0ivc/n/bv6Uiz3J3yw+UDQZNckf4i+5Ehev0G3pAOGvpHVxCJYq ekxcqTlx3Np4cSauMWdWwLR4HzvUoubCsFuKpv74SFgSpOUuY5phY+ZlLh8cwjRX IBu9d0bnlrl5yPNMPiUXa3Igr1e8/pmmru5qGExHytKMnddFgGDGRlv3vyQPB4w= =bxcr -----END PGP SIGNATURE----- --Apple-Mail=_1EE438A1-5BBF-4E0A-B77D-C113957D3DCC-- From nobody Tue Jul 29 06:46:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC41A03D6 for ; Tue, 29 Jul 2014 06:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH-aFaKjq1Ni for ; Tue, 29 Jul 2014 06:46:37 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D309A1A0185 for ; Tue, 29 Jul 2014 06:46:37 -0700 (PDT) Received: from dhcp-10-61-109-61.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id AC0056101; Tue, 29 Jul 2014 06:46:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EAD79D8B-8A58-4DF5-B2FC-98CB20C16442"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> Date: Tue, 29 Jul 2014 15:46:29 +0200 Message-Id: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> To: 6man WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZrmFz0wAoQShFKC-SrBo3vJQa_A Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:46:39 -0000 --Apple-Mail=_EAD79D8B-8A58-4DF5-B2FC-98CB20C16442 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have reviewed the document, and have found a few comments below. apart = from that I think the document is ready to go. Section 1: "The fixed length limits the practical length of a routing prefix to 64 bits, whereas architecturally, and from the point of view of routing protocols, it could be anything (in theory) between /1 and / 128 inclusive. Here, we mainly discuss the question of a shorter IID, which would allow a longer subnet prefix. The document makes no proposal for a change to the IID length." say something about host routes. for the sake of the argument you could = say that the interface-id is still 64 bits, and that the longest match = is done on the concatenation of prefix and interface-id. Section 2: "Even though this length is a parameter for SLAAC, determined separately for each interface, a globally fixed IID length for all link layer media is the simplest solution, and is consistent with the principles of Internet host configuration described in [RFC5505]." s/for each interface/link-layer media type/ Section 4.1: "Only the IPv6 Subnet Model [RFC5942] refers to the assumption of /64 = prefix length as a potential implementation error." =20 that almost reads as if the authors believe RFC5942 is in the wrong. making the assumption that there is a corresponding on-link /64 prefix = when the host only has an IPv6 address (e.g. from DHCPv6) is indeed an = implementation error. the simplest resolution would be to delete the above sentence. "Default Router Preferences [RFC4191] for its impossibility of Prefix = Length 4" remove above reference. there is no limitation on prefix length in = RFC4191. prefix is zero padded up to a 8 or 16 octet boundary. Section 4.2 "Operationally there could be a problem unless all hosts on a link use IIDs of the same length to configure a link-local address during reboot. Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface, and systems behave as if the link local prefix was actually fe80::/64. " remove "during reboot". the prefix length for a global prefix doesn't = have to be the same as for the link-local address. perhaps rather make = it clear that since there is no way to configure the link-local prefix = length, it will be a as defined in IPv6 over foo documents regardless of = what the global prefix is. Section 4.4: At least one DHCPv6 client unconditionally installs a /64 prefix as on-link when it configures an interface with an address, although some specific operating system vendors seem to change this default behavior by tweaking a client-side script. It does this (even if technically it violates the protocol) because if there is no router on the link, the hosts effectively would fail to communicate each other with the configured addresses because the "on-link assumption" was removed in [RFC4861]. This is not really about the magic number of 64, but an implementation may sometimes pick a specific value of prefix length due to the removal of the on-link assumption, and the value chosen will most likely be 64. if so, that is in violation of RFC5942. I don't think this document = should make a case for different behaviour than 5942 requires. just drop the whole paragraph? Section 4.5: "A prefix long enough to limit the number of addresses comparably to an IPv4 subnet, such as /120, would create exactly the same situation for privacy as IPv4 except for the absence of NAT. In particular, a host would be forced to pick a new IID when roaming to a new network, to avoid collisions. An argument could be made that since this reduces traceability, it is a good thing from a privacy point of view." does that logic hold water? outside of the network using the longer = prefixes, an attacker would still have to track or guess the prefix = length set of bits. privacy-wise you could make the reverse argument as well. that a = constant subnet prefix assigned to every end-user, means that I can now = make fairly safe assumptions that I can track a given end-user by = tracking the /64. which doesn't help privacy. cheers, Ole On 21 Jun 2014, at 3:16 , Bob Hinden wrote: > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Analysis of the 64-bit Boundary in IPv6 = Addressing > Authors : Brian Carpenter > Tim Chown > Fernando Gont > Sheng Jiang > Alexandru Petrescu > Andrew Yourtchenko > Filename : draft-ietf-6man-why64-01.txt > Pages : 23 > Date : 2014-05-07 >=20 > http://tools.ietf.org/html/draft-ietf-6man-why64-01.txt >=20 > as an Informational RFC. Substantive comments and statements of = support for publishing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on July 4, 2014. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 --Apple-Mail=_EAD79D8B-8A58-4DF5-B2FC-98CB20C16442 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT16W1AAoJEFuJXizso86gDusIANZmsyzbfQJB4VOqWNa9GTaj 6lxTzv7Wgb2KMhgf1Hnxl4w9TyX2EwmliYWLD+Xuz6AXwVhhTzbpzRdxW5XguDDH KuJypWPRLIoiLmwGJz0NgX++fDa6MPvgCpzlCCNbc0rAXwpx5QowogZrdVEsWEvA lpPkC80PJD/IYP3laPV9iHa5kDPpo53Fq2+Dh+E4an7WusFIrkK2yq844RyiQhNd rljS/xGA8bLt1/B21n7TbprunoGV8Yv3V/r+AeiIW4hQPRbJKMPbWW+ENjM2k55H KirOQPr5BOSXuvgBkm2AMf5OcodBp+1lKiMgFApqGHuvZjCpcN+SjmnsaQZMbH0= =KnaT -----END PGP SIGNATURE----- --Apple-Mail=_EAD79D8B-8A58-4DF5-B2FC-98CB20C16442-- From nobody Tue Jul 29 07:54:47 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B921B2957 for ; Tue, 29 Jul 2014 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEAP4F1m4C2c for ; Tue, 29 Jul 2014 07:54:37 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221F01B2935 for ; Tue, 29 Jul 2014 07:54:19 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so8532227iec.5 for ; Tue, 29 Jul 2014 07:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IS1P9aOJFJi+Q2jR4KBlbpoajpOkNTjQAVmp7gMngPg=; b=hSCCG48VGvXQ+fri+SBa7a3kAC3gpHHg1dr8qSnw4un+lMNA+3R2Ftah38BvVgQuw2 LxH0zMhMFzyikM+zIbXoNqN+pYNQx7PJ1gd701mZ4UvYZLVYUAmg0rScaSiTzGuE9oa1 /+9Q4cdy3t6gaSqbzXHsdwt0rJyM4sromtxjt6as3my6Xb04kIjESQNCmQJC1JPABKvx +unFKNgCd8xYTNYE9lPraV1H+Z6UWzJmZlyN1lc9YzOaEy+rSoRF5p4v8vlIb337BBkv IrSpdSx5Qu9kOjJpJ+oNpSnwqrAzU/IaYPnwilJ3p7HBjGeL1wZ+DUlYgg4pH/lE8rP4 L8uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IS1P9aOJFJi+Q2jR4KBlbpoajpOkNTjQAVmp7gMngPg=; b=VQLDYhckoLtJ+NQmBf7LTb23JZizDNqUdlCNyMcW3utcpsPiRO2ulTONprUDJ7bijr 4bhzDTDzCDiWVm4WY5rN6nbuM9Pw9jhhzJdDAEnE3CFtCmX+P54IEV23bD4vbPAf9JRC sHzpcBamDFFXbOzFrjzvwfAFe4tJUsFT67ix6DBxmomAD8PraeCdQXbB4s/eC0rxt44D s3cH7JpZn6XD60Af5r8Dg53laU55H8rjjHnKuqVktF90NNhKXOt03LjbvaXq8O2RssdG IM+KiRVzaRVQGCeXOalT7gQR4+nffguTQkL0T3QvIe7xTYDdczhx4v94P5CNMYIob2F2 RLWg== X-Gm-Message-State: ALoCoQnhEgn8QVikTywnKyHm09KGPqWP1XzbDzD8hWE0eQkRHeoCiZtXAHd8SevyqwfZX/iWaNp3 X-Received: by 10.50.164.167 with SMTP id yr7mr1850247igb.37.1406645658464; Tue, 29 Jul 2014 07:54:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.6 with HTTP; Tue, 29 Jul 2014 07:53:58 -0700 (PDT) In-Reply-To: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> From: Lorenzo Colitti Date: Tue, 29 Jul 2014 23:53:58 +0900 Message-ID: Subject: Re: 6MAN WG Last Call: To: Ole Troan Content-Type: multipart/alternative; boundary=089e0122a7fccc5e1204ff563683 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ClM4idjeTwDCK8hfaZF0felNX_w Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:54:40 -0000 --089e0122a7fccc5e1204ff563683 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 29, 2014 at 9:46 AM, Ole Troan wrote: > "The fixed length limits the practical length of a routing prefix to > 64 bits, whereas architecturally, and from the point of view of > routing protocols, it could be anything (in theory) between /1 and / > 128 inclusive. Or /0? --089e0122a7fccc5e1204ff563683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 29, 2014 at 9:46 AM, Ole Troan <otroan@employees.org> wrote:
=C2=A0 =C2=A0"The fixed length limits t= he practical length of a routing prefix to
=C2=A0 =C2=A064 bits, whereas architecturally, and from the point of view o= f
=C2=A0 =C2=A0routing protocols, it could be anything (in theory) between /1= and /
=C2=A0 =C2=A0128 inclusive.

Or /0?=C2=A0
--089e0122a7fccc5e1204ff563683-- From nobody Tue Jul 29 08:00:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F003B1B283B for ; Tue, 29 Jul 2014 07:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHW-q8pQnTQR for ; Tue, 29 Jul 2014 07:59:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C341A0356 for ; Tue, 29 Jul 2014 07:59:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s6TEvWEA013931; Tue, 29 Jul 2014 16:57:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E433C20A4A4; Tue, 29 Jul 2014 17:00:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D633C200C2A; Tue, 29 Jul 2014 17:00:19 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s6TEvUR2018978; Tue, 29 Jul 2014 16:57:31 +0200 Message-ID: <53D7B65A.3040909@gmail.com> Date: Tue, 29 Jul 2014 16:57:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ole Troan , 6man WG Subject: Re: 6MAN WG Last Call: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/A7NPMajisqaPTf42mjyCu5vAIy8 Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:00:00 -0000 Le 29/07/2014 15:46, Ole Troan a crit : [...] > "Default Router Preferences [RFC4191] for its impossibility of Prefix > Length 4" > > remove above reference. there is no limitation on prefix length in > RFC4191. prefix is zero padded up to a 8 or 16 octet boundary. Right, that text should be removed. (there was an interpretation error of RFC4191 from my part earlier.) Alex > > Section 4.2 "Operationally there could be a problem unless all hosts > on a link use IIDs of the same length to configure a link-local > address during reboot. Typically today the choice of 64 bits for the > link-local IID length is hard-coded per interface, and systems behave > as if the link local prefix was actually fe80::/64. " > > remove "during reboot". the prefix length for a global prefix doesn't > have to be the same as for the link-local address. perhaps rather > make it clear that since there is no way to configure the link-local > prefix length, it will be a as defined in IPv6 over foo documents > regardless of what the global prefix is. > > Section 4.4: At least one DHCPv6 client unconditionally installs a > /64 prefix as on-link when it configures an interface with an > address, although some specific operating system vendors seem to > change this default behavior by tweaking a client-side script. It > does this (even if technically it violates the protocol) because if > there is no router on the link, the hosts effectively would fail to > communicate each other with the configured addresses because the > "on-link assumption" was removed in [RFC4861]. This is not really > about the magic number of 64, but an implementation may sometimes > pick a specific value of prefix length due to the removal of the > on-link assumption, and the value chosen will most likely be 64. > > if so, that is in violation of RFC5942. I don't think this document > should make a case for different behaviour than 5942 requires. just > drop the whole paragraph? > > Section 4.5: "A prefix long enough to limit the number of addresses > comparably to an IPv4 subnet, such as /120, would create exactly the > same situation for privacy as IPv4 except for the absence of NAT. In > particular, a host would be forced to pick a new IID when roaming to > a new network, to avoid collisions. An argument could be made that > since this reduces traceability, it is a good thing from a privacy > point of view." > > does that logic hold water? outside of the network using the longer > prefixes, an attacker would still have to track or guess the prefix > length set of bits. > > privacy-wise you could make the reverse argument as well. that a > constant subnet prefix assigned to every end-user, means that I can > now make fairly safe assumptions that I can track a given end-user by > tracking the /64. which doesn't help privacy. > > > cheers, Ole > > > > On 21 Jun 2014, at 3:16 , Bob Hinden wrote: > >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Analysis of the 64-bit Boundary in IPv6 >> Addressing Authors : Brian Carpenter Tim Chown Fernando >> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename >> : draft-ietf-6man-why64-01.txt Pages : 23 Date >> : 2014-05-07 >> >> http://tools.ietf.org/html/draft-ietf-6man-why64-01.txt >> >> as an Informational RFC. Substantive comments and statements of >> support for publishing this document should be directed to the >> mailing list. Editorial suggestions can be sent to the authors. >> This last call will end on July 4, 2014. >> >> Regards, >> >> Bob Hinden & Ole Tran >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 29 08:15:17 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C431A02D4 for ; Tue, 29 Jul 2014 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoHdvY26f7bn for ; Tue, 29 Jul 2014 08:15:09 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A287C1A037C for ; Tue, 29 Jul 2014 08:14:44 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so5682257igb.2 for ; Tue, 29 Jul 2014 08:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qis7j2EAljtMjj7HrsDcq9gio5m50NZ5Utx/3QEiSn4=; b=iBoA1d1JirywVIlXUrSBCLS327AaVPAWcetZnugCQQ/HMSi6+I9M+nZ92NnGg6ZpzZ DDDaGLeTq6UJWvq8Cc9UFxTurvnl4w2Vxa8KTgEytGeC51Rb0Z0ajcuSd+RfPEVytC1a m712HKSJEw9rW3K1xqw6BHuY48XstlvRVtWjP1tofwNBddNl7UmK5njrJS1FGzmpuxMB AYtflxo8j3VRQpLnAgVp5r0gAYN9QXLolKiOV4J2jRxdYn3fRPwZQFbukhtyA1NP4t15 W+kBGl84/OJsc6KbFYpq4id5cCRx+PNPW/e0hrG/lbQg1cRqU3LYZg8wsmDBaPTzIeMz cHWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qis7j2EAljtMjj7HrsDcq9gio5m50NZ5Utx/3QEiSn4=; b=iB1VOAix6Aop6ypcpfBZfcmXip4lauDIPGiv/sjsZECZw/VpNJzvb91ttx+rlEsT0+ 3dHarKCopmSKUOmtXVffUvfdjmOZ0X6UKCAnmChZa39Z/6QWEP0seSKOfT4x9QkUYLKo rtD0XBVDxMITWnquzbweUVqE+DUzI0wLw8T8XhQqsXCyCdULVj3NgoctwvaUCa7YdPBh T3MAWqYR4sJnth+fVwUr2slLS8nlj2pS8bWAguXVdrM8Pd1SIR+BPhqgApEnlAV/2aTg M9jRpCuPoYJvyMI1gcTPBo6gQkM7YWmxY5HHDKRvuhbdnNX6yS6Hh9OSpHiLqbuMpCaq NROQ== X-Gm-Message-State: ALoCoQlbkPhP2S1ik2kPA9xbfyhWEiAwM5JGIxzgR03YyaB1L2zzxQdoRC0WznXRrGpDxRaIhcmd X-Received: by 10.43.107.68 with SMTP id dx4mr6516332icc.34.1406646883561; Tue, 29 Jul 2014 08:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.6 with HTTP; Tue, 29 Jul 2014 08:14:23 -0700 (PDT) In-Reply-To: <004AD154-0D65-4F7F-A198-61382562550A@employees.org> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org> From: Lorenzo Colitti Date: Wed, 30 Jul 2014 00:14:23 +0900 Message-ID: Subject: Re: draft-ietf-6man-resilient-rs update To: Ole Troan Content-Type: multipart/alternative; boundary=20cf30223cddd1d75d04ff567f2a Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0RNYH4KpJD8vVoq0yzbNJt6e6GY Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:15:16 -0000 --20cf30223cddd1d75d04ff567f2a Content-Type: text/plain; charset=UTF-8 On Tue, Jul 29, 2014 at 5:48 PM, Ole Troan wrote: > before posing the questions to the working group, let's agree on the > questions. > can we ask the working group to choose between the following two options: > i) only solve problem 1 in the resilient-rs draft. which implies remove > text about no periodic RAs > ii) solve both problem 1 and 2. which implies taking the document back to > the working group > If we pick #1, are we still allowed to clarify that a host MAY send a router solicitation when it feels it needs to (e.g., when some parameter it is interested in is about to expire?) --20cf30223cddd1d75d04ff567f2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 29, 2014 at 5:48 PM, Ole Troan <otroan@employees.org> wrote:
before posing the questions = to the working group, let's agree on the questions.
can we ask the working group to choose between the following two options: i) only solve problem 1 in the resilient-rs draft. which implies remove tex= t about no periodic RAs
ii) solve both problem 1 and 2. which implies taking the document back to t= he working group

If we pick #1, are we = still allowed to clarify that a host MAY send a router solicitation when it= feels it needs to (e.g., when some parameter it is interested in is about = to expire?)=C2=A0
--20cf30223cddd1d75d04ff567f2a-- From nobody Tue Jul 29 10:27:08 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC1F1A061D for ; Tue, 29 Jul 2014 10:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KPbjqK1PRqX for ; Tue, 29 Jul 2014 10:27:05 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7761A040F for ; Tue, 29 Jul 2014 10:27:05 -0700 (PDT) Received: from dhcp-10-61-109-61.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 427A061D1; Tue, 29 Jul 2014 10:26:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A1B39F61-32A7-402C-B4C8-7D1F2C5E0F6F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: draft-ietf-6man-resilient-rs update From: Ole Troan In-Reply-To: Date: Tue, 29 Jul 2014 19:26:52 +0200 Message-Id: <5D0C837C-0ADA-4309-B470-B2547F161984@employees.org> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/p9G87bZ3zt1ni18ml-DuaLtv1jg Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:27:07 -0000 --Apple-Mail=_A1B39F61-32A7-402C-B4C8-7D1F2C5E0F6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lorenzo, > before posing the questions to the working group, let's agree on the = questions. > can we ask the working group to choose between the following two = options: > i) only solve problem 1 in the resilient-rs draft. which implies = remove text about no periodic RAs > ii) solve both problem 1 and 2. which implies taking the document back = to the working group >=20 > If we pick #1, are we still allowed to clarify that a host MAY send a = router solicitation when it feels it needs to (e.g., when some parameter = it is interested in is about to expire?)=20 in my opinion, that should be part of solving problem 2. in any case a = "SHOULD stop sending periodic RS, but MAY do something else", the MAY is = redundant. cheers, Ole --Apple-Mail=_A1B39F61-32A7-402C-B4C8-7D1F2C5E0F6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT19ldAAoJEFuJXizso86gnucH/ifrdS8QLnpy0v42tYvg0Txy fp/KXtFuWct1hR0Xka9huTMhaNk/Y8tgk33DltZn5ySYhwK7N+g6nU1m2PCV+Ufw B3Y/TEi4Rrp/3rHbUGfMJNG7vc+KOxbHozDAwBjWICGIOqCmM2rdga8UyyowpxCE jsagpBG75+n+ugfEvcIbej1qUKOqd1COIQAIM6INpWb7e/BCpLdz4qJwHQ28BM8S cELosLnLqKeh+wXxaxKzExUpi8FpUwJ+A4ZElecH5ddTyP4Mr8SZzLPvUrKbn+jy dI/i7lf+hC7J8jv3XEnodDE4JXFRrVl9u7OTMSEwOAZJblTXfbMaI76+CrZp44o= =86+D -----END PGP SIGNATURE----- --Apple-Mail=_A1B39F61-32A7-402C-B4C8-7D1F2C5E0F6F-- From nobody Tue Jul 29 13:33:37 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419CE1A0A9D for ; Tue, 29 Jul 2014 13:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPqxTaV94um3 for ; Tue, 29 Jul 2014 13:33:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1902F1A0409 for ; Tue, 29 Jul 2014 13:33:31 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.995.11; Tue, 29 Jul 2014 20:33:29 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.120]) with mapi id 15.00.0995.011; Tue, 29 Jul 2014 20:33:29 +0000 From: Dmitry Anipko To: Ole Troan Subject: RE: draft-ietf-6man-resilient-rs update Thread-Topic: draft-ietf-6man-resilient-rs update Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZCAAA48gIABC23QgACT74CAAW614IAAKiQAgAFZbSCABUpkgIAAweaA Date: Tue, 29 Jul 2014 20:33:28 +0000 Message-ID: <351e522158e14ed7a8e533f4137bf401@SN2PR03MB077.namprd03.prod.outlook.com> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org> In-Reply-To: <004AD154-0D65-4F7F-A198-61382562550A@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(199002)(51704005)(377454003)(87936001)(85852003)(20776003)(80022001)(2656002)(83072002)(86362001)(106116001)(74502001)(21056001)(4396001)(74662001)(105586002)(106356001)(101416001)(107046002)(110136001)(81342001)(92566001)(64706001)(31966008)(99396002)(76176999)(74316001)(76576001)(79102001)(46102001)(33646002)(19580405001)(85306003)(83322001)(54356999)(76482001)(95666004)(50986999)(81542001)(77096002)(77982001)(99286002)(93886003)(19580395003)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/kygIp-l1W1uLShEZgPk0ecaHxhw Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" , 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:33:36 -0000 Hi Ole, >> I do agree with that. the specific concern with the MAY, is that we'll e= nd up with inconsistent behaviour on the link. I'd much rather that we spec= ified behaviour in detail. Ok, can you elaborate to what level of details you'd expect the behavior to= be specified? Is statement on rate limiting would be sufficient, or you th= ink the description of the algo along the lines of DHCPv6 retransmissions i= s needed (or the latter could be referenced)? >> I think the argument made is that the issues are somewhat tangled togeth= er. While the issues might be somewhat tangled, it doesn't necessarily follow t= hat the solutions have to be tangled - particularly if the solution to the = massive multicast background traffic may not come fast. >> if you made RD more resilient against packet loss, then you may end up s= olving the "no periodic multicast" case as a side effect. Yes, it might happen, and I think it's fine if we solve that scenario curre= ntly described in the draft.=20 That said, I don't think that for this draft we must pursue the goal of add= ressing the general multicast issues raised in the other recent drafts. Thi= s draft pursues incremental improvement in the context of the existing prot= ocol. >>1) the initial connection problem 2) not robust enough in case of packet drop / what to do when (last) router= lifetime expires / last address expires 3) links without periodic RAs Speaking for myself only, I think either (1) & (2) or (1) & (2) & (3) are f= ine. >> ii) solve both problem 1 and 2. which implies taking the document back t= o the working group I'd suggest re-phrasing this as "instructing the authors to update the scen= ario text and the suggested host behavior and re-submit for LC". Thank you, Dmitry -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Tuesday, July 29, 2014 1:49 AM To: Dmitry Anipko Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilien= t-rs@tools.ietf.org; 6man WG Subject: Re: draft-ietf-6man-resilient-rs update > Let's separate discussions on the substance and on what exact language we= put in the draft.=20 >=20 > Substance wise - IMO, the change tries to reduce existing fragility of RD= in some situations. We had very real real-world support cases with one of = the top mobile operators in the US, where the network was not sending new R= As before expiring the info in the initial one. Yes, this was a misconfigu= ration / bug on the network side. Yes, this is where it was eventually fixe= d, and yes perhaps the support teams should not have taken as much time to = figure it out. But the end-users don't care about that part, and they would= be better off in the meantime if the protocol had more resiliency against = misconfiguration or packet loss. Speaking for myself only, this is the scen= ario I'm concerned about. I'm sure there are others who know the "no multic= ast RAs, period" scenario better than I do, and they can speak for that. >=20 > So I think it would be good to first understand, leaving specific RFC lan= guage aside, whether there is consensus to improve RD reliability when the = host sees that previously received information has expired / about to expir= e. My impression from the discussion in London was that there was such cons= ensus - but perhaps I misunderstood. Letting the host do additional rate-li= mited transmissions to solve that, to me looks like a simple and reasonable= approach. If you agree with that, then what's the specific concern on putt= ing that as MAY? I do agree with that. the specific concern with the MAY, is that we'll end = up with inconsistent behaviour on the link. I'd much rather that we specifi= ed behaviour in detail. > I do disagree with the viewpoint, that because if ND use of multicast is = inefficient, let's not make any improvements to ND until multicast issue is= solved. Yes, the multicast-related issues in general do need to be address= ed over long term. But addressing them will take time, and there are issues= today which end-users are hitting, for which incremental limited fixes wit= hin existing framework are possible and reasonable. I think the argument made is that the issues are somewhat tangled together.= =20 >>> today, links without periodic RAs are not supported. >=20 > Since this is a statement about today, it equally applies (or not applies= ), to the option 2 you suggested and the option I suggested, so it's not a = differentiator. Furthermore, it basically is equivalent to option 1, which = makes it not an independent argument, but re-iterating option 1, and can't = be used as a differentiator there either. if you made RD more resilient against packet loss, then you may end up solv= ing the "no periodic multicast" case as a side effect. so for the question of what to do with the resilient RS draft. there seems = to be at least three problems: 1) the initial connection problem 2) not robust enough in case of packet drop / what to do when (last) router= lifetime expires / last address expires 3) links without periodic RAs solving 2 may inadvertently solve 3. before posing the questions to the working group, let's agree on the questi= ons. can we ask the working group to choose between the following two options: i) only solve problem 1 in the resilient-rs draft. which implies remove tex= t about no periodic RAs ii) solve both problem 1 and 2. which implies taking the document back to t= he working group cheers, Ole From nobody Tue Jul 29 13:38:29 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77CF1A0AFF for ; Tue, 29 Jul 2014 13:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnMcy-bBvJh5 for ; Tue, 29 Jul 2014 13:38:20 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEF11B2815 for ; Tue, 29 Jul 2014 13:38:20 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so215528pdi.20 for ; Tue, 29 Jul 2014 13:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=alJxYaU8/T0/ZIWSb6FNDKCjeAlfJiu/flyosB8zSwI=; b=l+tPJ8Vuww+ouul4UcPV1zlFm8AZm/UlLQ2w0wkWwo5IPrLFAds5ZVuI3/TInrofai vGTs5F+kmG7HGfJXajodZm9+baFPQlK2DzW5F/z/LEajtHvqwPmK9XaVuxa1HjWJJLqR PgESkfRcAYcZMI5FfNwpK9b2SBbbX7+9T5kYgtq0mFiVEgK3ka2a5re6z7FD7jrtbrs1 EHAd+ZV1QUDXkyR8AETESEPKni92ATtk3d7Xa8CJdzdg/KEAv1XtPylXa3SPOnjIgSms 1qBuyRhmnLAubacOUIobPZT/MaU4GTC5V5U+8JLRd+hzFD8rxipM21BsJ8VOS51slkD/ 7mHg== X-Received: by 10.68.197.65 with SMTP id is1mr4374310pbc.125.1406666300105; Tue, 29 Jul 2014 13:38:20 -0700 (PDT) Received: from [192.168.178.23] (148.197.69.111.dynamic.snap.net.nz. [111.69.197.148]) by mx.google.com with ESMTPSA id cv2sm36012pbc.34.2014.07.29.13.38.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:38:19 -0700 (PDT) Message-ID: <53D8063D.5060504@gmail.com> Date: Wed, 30 Jul 2014 08:38:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: 6MAN WG Last Call: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Ik2OLsgjkbQucIf2sqfYGlhzufo Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:38:24 -0000 On 30/07/2014 02:53, Lorenzo Colitti wrote: > On Tue, Jul 29, 2014 at 9:46 AM, Ole Troan wrote: > >> "The fixed length limits the practical length of a routing prefix to >> 64 bits, whereas architecturally, and from the point of view of >> routing protocols, it could be anything (in theory) between /1 and / >> 128 inclusive. > > > Or /0? Well, that's the default route, and it seemed to me when I drafted that sentence that describing something of length zero as a prefix was a bit odd. I don't feel strongly, however. Ole: thanks for the comments. We'll wait for other reviews before editing the text. Brian From nobody Tue Jul 29 14:21:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EBF1A0178; Tue, 29 Jul 2014 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXb0jVXj5lSM; Tue, 29 Jul 2014 14:21:30 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB5C1A00E1; Tue, 29 Jul 2014 14:21:29 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so478010vcb.28 for ; Tue, 29 Jul 2014 14:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VurvvMSvsEsXETzvDQf6iZ4tOt4HbA7Ogv2j4PWP528=; b=fWvu4kWVGNhjH+U58TZz/ugNj6WAx0WDl/Bs+Zs06EJy5CANymDC4uErq2rSjOKdJo R+WuCWhM44Pme4JX22ntbMW+OsdgtjbrQ4KSLWWMYA1zlVBDDsrgEyI7w3ltQMl8LXtf mbzlScvpS52EVKmY+Y2kBZny4jMo2fnADYlbrx+Xdh9jt9Q3M7mdN7Ow4WiSfkztXgXR TzCEwc43Rm1CJb48RqVIUhjE5daIY/GjAFu/hOZ8kG2fTQ5ByekZgXVn67kIveQ/mbXI ZwSnulRPpJFWNHdrOLC2b0v5kWH78nhlZeZq0Ddtv38uMv6gwz3SHu0MDK/lhsNH2sj+ PStQ== MIME-Version: 1.0 X-Received: by 10.52.251.195 with SMTP id zm3mr3900030vdc.36.1406668888995; Tue, 29 Jul 2014 14:21:28 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Tue, 29 Jul 2014 14:21:28 -0700 (PDT) Date: Wed, 30 Jul 2014 00:21:28 +0300 Message-ID: Subject: WGLC for draft-thubert-6man-flow-label-for-rpl-03 From: Ines Robles To: "ipv6@ietf.org" , roll Content-Type: multipart/alternative; boundary=001a1136030a71ffe304ff5b9f48 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ESNTa3VHsiXQG8_2rInfsIcRCeU Cc: Brian Haberman , Michael Richardson , Bob Hinden , Ole Troan , "Pascal Thubert \(pthubert\)" , Adrian Farrel X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:21:31 -0000 --001a1136030a71ffe304ff5b9f48 Content-Type: text/plain; charset=UTF-8 Dear 6man and roll WGs, We announce a joint Working Group Last Call for draft-thubert-6man-flow-label-for-rpl-03 , since this document is related to both WGs, we ask for comments to 6man and roll members. We are going to request for an AD sponsored document. This WGLC is going to take from 07/30/2014 to 08/13/2014. Thank you very much, 6man and roll chairs. --001a1136030a71ffe304ff5b9f48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear 6man and roll WGs,

We announce a j= oint Working Group Last Call for=C2=A0draft-thubert-6man-flow-label-fo= r-rpl-03, since this document is related to both WGs, we ask for commen= ts to 6man and roll members. We are going to=C2=A0request for an AD sponsored document.

This WGLC is going to take from 07/30/2014 to 08/13/201= 4.

Thank you very much,

6man and roll chairs.


--001a1136030a71ffe304ff5b9f48-- From nobody Tue Jul 29 17:02:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBC1B2A28; Tue, 29 Jul 2014 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9CpefRPLJkK; Tue, 29 Jul 2014 17:02:23 -0700 (PDT) Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B94A1A038D; Tue, 29 Jul 2014 17:02:23 -0700 (PDT) Received: from [76.14.66.110] (port=55794 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCHLY-0004Ah-A0; Tue, 29 Jul 2014 17:02:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 From: Philip Levis In-Reply-To: Date: Tue, 29 Jul 2014 17:02:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> References: To: Ines Robles X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 1620fcb02ed1792cf65161168a9fe1e9 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7oDltSAxBCfbZ1Gneni26AyxlQE Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Bob Hinden , Ole Troan , "Pascal Thubert \(pthubert\)" , Adrian Farrel X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 00:02:27 -0000 On Jul 29, 2014, at 2:21 PM, Ines Robles = wrote: > Dear 6man and roll WGs, >=20 > We announce a joint Working Group Last Call for = draft-thubert-6man-flow-label-for-rpl-03, since this document is related = to both WGs, we ask for comments to 6man and roll members. We are going = to request for an AD sponsored document. >=20 > This WGLC is going to take from 07/30/2014 to 08/13/2014. >=20 > Thank you very much, I'm worried by the fundamental premise of the approach: "The 8-octets overhead is detrimental to the LLN operation, in = particular with regards to bandwidth and battery constraints. The extra = encapsulation may cause a containing frame to grow above maximum frame = size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in = turn cause even more energy spending and issues discussed in the LLN = Fragment Forwarding and Recovery = [I-D.thubert-6lo-forwarding-fragments]." The basic assumption of this paragraph is that energy consumption is = dominated by transmission time. Has anyone presented any actual evidence = -- i.e., actual energy numbers -- of the cost this introduces?=20 Because "This specification suggests that energy-saving is another compelling = reason for a violation to the aforementioned rule." makes the assumption that the energy saving is significant. Breaking the = end-to-end nature of the flow label for some tiny saving seems like a = mistake. But if this would actually save a significant amount of energy = that couldn't be saved through other, simpler, means, then it seems like = a great idea. My fear is that this area -- low-power link layers, energy saving = protocols -- is an area that is still new to the IETF and tends to have = very subtle issues. What's being proposed here is pretty significant. = Simple, intuitive arguments might not hold up to scrutiny in real = networks. If you look at it in this light, one comment the draft makes is = especially troubling: "But if we consider the whole RPL domain as a large virtual host from = the standpoint of the rest of the Internet" This is completely contrary to the deep, fundamental premise of the = Internet of Things and when we started down the path of bringing IPv6 to = LLNs. Before 6lowpan, LLN devices were typically considered peripherals, = devices that connect to an Internet host through other interfaces and = protocols (USB, ZWave, ZigBee, etc., etc.). This gave greater = flexibility on what those networks could do, but it placed a hard = barrier on the Internet. You needed new tools, management interfaces, = software, and policies for managing the two sides of the network. E.g, = you manage your IP network and separately manage your embedded network. = The big promise of 6lowpan and all of the subsequent technologies the = IETF has developed is that instead, we can consider it IP down into = these networks as well. Considering an entire LLN as a virtual host goes = back to this segmented model, and so is a step backwards. In summary, this draft presents a tradeoff: break the end-to-end = behavior of the flow label for improved energy efficiency. I'd argue = strongly in favor of this draft if "improved" meant "doubles". But if it = means "5% in 1% of use cases", this seems like a poor tradeoff. The IETF = 90 slides say it's a "show stopper" for SDOs. I'm not sure what that = means? Is there any greater detail on this? I'd like to make an informed = engineering decision, but don't have enough data to do so. Phil= From nobody Tue Jul 29 18:36:49 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0109D1A0AC7; Tue, 29 Jul 2014 18:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaYwcBlOfV8J; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942F81A04B8; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wm4so92488obc.41 for ; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yrQ9LoTrf1Q4U9V34/5txGmGYjCRtxv9TwB0OnBOpb8=; b=WcysxmVcch3hDugj5Df2Q0QUtgu4644Rdnel+DkA0UbT5kR3bdCtVGhV/ATJX4I1CO lwwM+EhBznzy7HrmpPAz3J+KjeVkS24QqfNInzwOA9ewLtJddqDJu0hW0IH2cQaPk6WG +IOttgfG9G2gI2jcL+dGk5sO4MrLFnZza5O6sJagldQ6xxJ1ef4DDTaFd7ZqIz5hdc24 fKaFn513MXDKP15APANftOaQF7btdjHzV+JE89PJP/GY00BncQOx1Kdi//oJVe2odbbQ sv6CdGOaQN55xHLm7QdfuRJJ7pv+eIBfxG1unFrb/RFWVW5EWUoBcI4ZrXx9SJA5HmG3 e/OA== X-Received: by 10.182.113.199 with SMTP id ja7mr556539obb.74.1406684203040; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id d3sm3031667oez.5.2014.07.29.18.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 18:36:42 -0700 (PDT) Message-ID: <53D84C2C.9050709@gmail.com> Date: Wed, 30 Jul 2014 13:36:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> In-Reply-To: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ROEbaaNmtGeWbRMRuHRmoCfi6ng Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , Ole Troan , "Pascal Thubert \(pthubert\)" , Adrian Farrel X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 01:36:45 -0000 On 30/07/2014 12:02, Philip Levis wrote: ... > "This specification suggests that energy-saving is another > compelling reason for a violation to the aforementioned > rule." > > makes the assumption that the energy saving is significant. > Breaking the end-to-end nature of the flow label for some > tiny saving seems like a mistake. I can't evaluate whether the energy saving is significant. However, I don't have any deep faith in the e2e-ness of the flow label. The reality (as RFC 6437 tries to recognise) is that it's a mutable field, and is therefore untrustworthy for e2e use. It has value for load balancing if all packets of a given flow have the same label, whether the label is set by the source or by a border device. For that reason, I think the usage proposed in this draft is OK. However, I do agree that at least a hand-waving estimate of the % energy saving would be useful. Brian Carpenter From nobody Wed Jul 30 04:28:54 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA01A0313 for ; Wed, 30 Jul 2014 04:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUc5kiJHdaxV for ; Wed, 30 Jul 2014 04:28:51 -0700 (PDT) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B3E1A02FF for ; Wed, 30 Jul 2014 04:28:51 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jul 2014 11:28:50 -0000 Received: from [98.138.100.116] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jul 2014 11:25:56 -0000 Received: from [66.196.81.170] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jul 2014 11:25:55 -0000 Received: from [98.139.212.245] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jul 2014 11:25:55 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 30 Jul 2014 11:25:55 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 756908.34970.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 12784 invoked by uid 60001); 30 Jul 2014 11:25:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1406719555; bh=tiXhu36LZ4b57DsXmAaQz7ph0IcPJ+D/VZDQHFaeGRU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lG12B9uVFiNh+Ic3XiQjWQFsYy9FD1uDbNpHzll2a8wAhwEoW3CFaPvDGJcIG/1GTLWxJf5FFxzs6c+wOEHaRql6xdx9bdqVGJaxuDhSj24zOtFLaxFX0eap1IIBFd9Kb8GDEHzTnpJkPo/yUwJ25X9bsm0ZMVrJNz+CShzBfYo= X-YMail-OSG: LQeSZrsVM1lDcHWFhg9uPAFL5lvstRUGUh.73DjABJ9_nmE AZYkk0Z7T1WYonj6YtHeF6LqbdvhiVoe5sEmOHR4f8cHNX3IHRyA0VtkmSIw EGTnVan4yQQSzuIvKFVilXVcnEG5THzKWQvtQuoNTBgHNFwAOT4UcFjvMV8e p2URjq_p0G09AyzfnAnhA1AQxQKvHXIbHsVxWXlIsa5aibH3KS5B5ey1NIVA IdJMvKWxRnmetCGE5xKZshSB8_qdLLZBHYTNLKv8F2ovDB_WYCkr4dPdU3T1 IhPD418N1Pbdyz7j8d1DY3Q40p5G3qdcUQSPZAbpTrrtrQInk9PvfgQFz1Df Ms8xt57rjTz3rZD9ZvjivgXk2bByEBKE94EcfLbM9K3bV1nxFsGG3FfY5j.2 VbEcX92ZjvUd.zKaSyF_W3B4EddT6bjbbo4nJo.SoQ50NrwS_qrEtiBKA.Zx iJfZHSQf3zRQrzS_XO6hXECPDVg8C4H44ImqEcaaAPLp2FGEH4n1o0ij8PLS Lb0WMohafXS9DK3Z.kXtJKUT0ZiYJYDg8i1ExVGlR.BedDBcb2F8cyF07Z2Z 44r0MhH9EuOBbzlJD Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Wed, 30 Jul 2014 04:25:55 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPiBDYzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPgo.IFNlbnQ6IFdlZG5lc2RheSwgMzAgSnVseSAyMDE0IDY6MzggQU0KPiBTdWJqZWN0OiBSZTogNk1BTiBXRyBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLTZtYW4td2gBMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> <53D8063D.5060504@gmail.com> Message-ID: <1406719555.68763.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Wed, 30 Jul 2014 04:25:55 -0700 From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Brian E Carpenter , Lorenzo Colitti In-Reply-To: <53D8063D.5060504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Aw9c39Y1mSGVbr5bsf4tAfKEEQI Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:28:52 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Lorenzo Colitti =0A> Cc= : 6man WG ; Bob Hinden =0A> Sent: Wedn= esday, 30 July 2014 6:38 AM=0A> Subject: Re: 6MAN WG Last Call: =0A> =0A> On 30/07/2014 02:53, Lorenzo Colitti wrote:=0A= >> On Tue, Jul 29, 2014 at 9:46 AM, Ole Troan =0A> = wrote:=0A>> =0A>>> =A0 =A0 "The fixed length limits the practical length of= a routing =0A> prefix to=0A>>> =A0 =A0 64 bits, whereas architecturally, a= nd from the point of view of=0A>>> =A0 =A0 routing protocols, it could be a= nything (in theory) between /1 and /=0A>>> =A0 =A0 128 inclusive.=0A>> =0A>= > =0A>> Or /0?=0A> =0A> Well, that's the default route, and it seemed to m= e when I drafted=0A> that sentence that describing something of length zero= as a prefix=0A> was a bit odd. I don't feel strongly, however.=0A> =0A> Ol= e: thanks for the comments. We'll wait for other reviews before=0A> editing= the text.=0A>=A0=0A=0AI've done a first run though, I'll do another over t= he next few days and should be able to send comments etc. through Sunday ev= ening.=0A=0ARegards,=0AMark.=0A=0A=0A> =A0 =A0 Brian=0A> =0A> =0A> --------= ------------------------------------------------------------=0A> IETF IPv6 = working group mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: h= ttps://www.ietf.org/mailman/listinfo/ipv6=0A> -----------------------------= ---------------------------------------=0A> From nobody Wed Jul 30 11:55:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762A1A02D2 for ; Wed, 30 Jul 2014 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74VmvC-vxPRD for ; Wed, 30 Jul 2014 11:55:49 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3032F1A0195 for ; Wed, 30 Jul 2014 11:55:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so2874526wib.14 for ; Wed, 30 Jul 2014 11:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=F6X0nQteamVa+Vgui5Eu3MTv9R3BcAGkGIPs4olsmy8=; b=CkEjPUMeg7QQLK8/7IqSMVf6CYpa8B0m4Mmom/cfwgknVRl1NDilKslvZtzxfdjVWZ UQItLPchQzIDaMJcUELR0Jr1bQ8RDwbN7Bm4Xd5qid+vWD9bJh3FPRpSjzuo4CG+MSlN RRXgvKTU/d0kwsH16L4rfBW9V7fTcJPXRBkwNGEmRXboh6HvcxEtiTZNyp31moT+Zfeq dbfQubA+MwanAf/ltX2Wx2ilSoS33O3AKJ8BkjsNXm93zPh3c+BvbHPF/t/EounIpSrd tWpJ+4sER6qXpNyY4NtvJ8dBF9sgXGzCSrPqjEH19yFtilPkmQiMG2OxMwqkC2uVDPHm cUtg== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr8940123wjb.87.1406746547761; Wed, 30 Jul 2014 11:55:47 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Wed, 30 Jul 2014 11:55:47 -0700 (PDT) In-Reply-To: <5D0C837C-0ADA-4309-B470-B2547F161984@employees.org> References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org> <5D0C837C-0ADA-4309-B470-B2547F161984@employees.org> Date: Wed, 30 Jul 2014 11:55:47 -0700 X-Google-Sender-Auth: hn3dZga-XDHLIjX4osr8WxAR1EI Message-ID: Subject: Re: draft-ietf-6man-resilient-rs update From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hII8vtKIRIefnewsHhKSmtGlXE0 Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:55:51 -0000 At Tue, 29 Jul 2014 10:48:31 +0200, Ole Troan wrote: > can we ask the working group to choose between the following two options: > i) only solve problem 1 in the resilient-rs draft. which implies remove text about no periodic RAs > ii) solve both problem 1 and 2. which implies taking the document back to the working group Not a strong opinion, but given that we've already spent quite a long time for the draft, I think I'd prefer option (i). -- JINMEI, Tatuya From nobody Wed Jul 30 13:44:04 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8011A0145 for ; Wed, 30 Jul 2014 13:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esmSIoNhmAht for ; Wed, 30 Jul 2014 13:44:01 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C7F1A0125 for ; Wed, 30 Jul 2014 13:44:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so8290148wib.9 for ; Wed, 30 Jul 2014 13:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1wk14a+299ZBmL1Z9KIFGNIqf7nGNPGRHFbo7Tun9wU=; b=VkmRPZLh3i4UNInd1ZE7211D1VmsUBZCuy57BhvI9f9o+SSy1KuJqoRwazNLbFsM5n 6bKduE191KtdkFEB6V/V+hPeGEw8JRlxh0oX3y3idywFpg9T7VohLgomAO1hrIPXw6Rl cEScr3IhrQ1NL1Ch87FCeDp9Nh+qS9LupawcL7UQGXQgub+BcQhB4oomXtI/Tk8cJYX2 TArqqTugDbRrXX4H6Xv9qE81gRNOSCLX0e8NQhovtA0tkc+NYNrDTm8i6Xi0gZepaRfi yfzTmHUEoltr/aMyin8DyxO7KO91u2wDNFV/QgatuvRPbsN6EtCMsOJN6v46L+z4VD9C HQYg== MIME-Version: 1.0 X-Received: by 10.180.80.133 with SMTP id r5mr10269541wix.62.1406753039852; Wed, 30 Jul 2014 13:43:59 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Wed, 30 Jul 2014 13:43:59 -0700 (PDT) In-Reply-To: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> Date: Wed, 30 Jul 2014 13:43:59 -0700 X-Google-Sender-Auth: S00o6Kl6UtqpSVj2PnS3Q7V-PRE Message-ID: Subject: Re: 6MAN WG Last Call: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/C8XNvOIdonRhrmeIOJ86C-A2yWQ Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:44:03 -0000 At Tue, 29 Jul 2014 15:46:29 +0200, Ole Troan wrote: > Section 4.4: > At least one DHCPv6 client unconditionally installs a /64 prefix as > on-link when it configures an interface with an address, although > some specific operating system vendors seem to change this default > behavior by tweaking a client-side script. It does this (even if > technically it violates the protocol) because if there is no router > on the link, the hosts effectively would fail to communicate each > other with the configured addresses because the "on-link assumption" > was removed in [RFC4861]. This is not really about the magic number > of 64, but an implementation may sometimes pick a specific value of > prefix length due to the removal of the on-link assumption, and the > value chosen will most likely be 64. > > if so, that is in violation of RFC5942. I don't think this document should make a case for different behaviour than 5942 requires. > just drop the whole paragraph? (I believe) it was me who suggested including this issue in this document, so I'll respond: at least I didn't intend to endorse this behavior by mentioning it (if you meant that by "make a case for"). In fact, this text event explicitly notes that it violates the protocol, although today we might remove "even if", and explicitly refer to RFC5942 instead of just saying "the protocol". Also, my understanding of Section 4.4 is that it generally discusses known real world issues with implementations that assume a prefix length of 64 bits, some of which could in fact violate the standard. So I don't think we should necessarily remove an example simply because it's about a non-compliant implementation. In this specific case, I thought it would be worth noting because this particular implementation (ISC DHCPv6 client) should be quite widely used, and because the seeming background reason for this behavior could lead to other similar broken implementations. If you and others still think this issue should be dropped with the clarified intent, I wouldn't necessarily be opposed to that; I just thought this issue would be useful in general in the context of this document but that's probably only me. On the other hand, if the issue is about specific text rather than the intent and specific example, IMO we should try to fix the textual issue rather than remove it. In the latter case, it would depends on specifically what you thought was a problem, but if it's that this text could read as if it endorses the broken behavior, one resolution would clarify that it violates RFC5942 more explicitly. -- JINMEI, Tatuya From nobody Wed Jul 30 13:54:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498681A040F for ; Wed, 30 Jul 2014 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYfPRi_ns-Nk for ; Wed, 30 Jul 2014 13:53:58 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B751A040D for ; Wed, 30 Jul 2014 13:53:58 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so2200642pab.33 for ; Wed, 30 Jul 2014 13:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KImw4bFi0joK2v3Kl00yAkpIthuc71IWGoR7oW16SJY=; b=fOc9FUYUG97Q+5rtKJIRPjhV/nhao0AfDiTXXsconV0aOj+AB0MRxlDjAEEaQcWJ4f ZLLhbkIKTrDvA0Vnoi+SfKkhoLX2IRdvZ+E1cuYz4MNPEtCigZlefstK/RMFBOopMhP+ qjHdAiRBSmiLA6ufo5qsmmsy74yJbaer8RhC/ViiK+v3si73yxgZEb+uwztWMzxrKybm 0KnGF8XofrPlLYxqTGvluWWy4lWV2EUvelBjGn0tN6QDWBrM2WC4d0B15I1kvRk1SvKc AG64PylOgWguoEKad1RRTeJx2dRKHslu+3ZRkRuu1sczszAVfRSKi4L+7hxAQoXbWnMP MgMA== X-Received: by 10.70.38.134 with SMTP id g6mr642528pdk.135.1406753638263; Wed, 30 Jul 2014 13:53:58 -0700 (PDT) Received: from [192.168.178.23] (147.199.69.111.dynamic.snap.net.nz. [111.69.199.147]) by mx.google.com with ESMTPSA id a4sm3298554pdc.88.2014.07.30.13.53.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 13:53:57 -0700 (PDT) Message-ID: <53D95B69.7050403@gmail.com> Date: Thu, 31 Jul 2014 08:54:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: 6MAN WG Last Call: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/tu9Hx3icdp_7Lln9hH2op7Az6Qk Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:54:00 -0000 Ole, I think we shouldn't drop it; IMHO we should adjust the text to make it clear that this is faulty behaviour. Brian On 31/07/2014 08:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 29 Jul 2014 15:46:29 +0200, > Ole Troan wrote: >=20 >> Section 4.4: >> At least one DHCPv6 client unconditionally installs a /64 prefix as >> on-link when it configures an interface with an address, although >> some specific operating system vendors seem to change this default >> behavior by tweaking a client-side script. It does this (even if >> technically it violates the protocol) because if there is no router= >> on the link, the hosts effectively would fail to communicate each >> other with the configured addresses because the "on-link assumption= " >> was removed in [RFC4861]. This is not really about the magic numbe= r >> of 64, but an implementation may sometimes pick a specific value of= >> prefix length due to the removal of the on-link assumption, and the= >> value chosen will most likely be 64. >> >> if so, that is in violation of RFC5942. I don't think this document sh= ould make a case for different behaviour than 5942 requires. >> just drop the whole paragraph? >=20 > (I believe) it was me who suggested including this issue in this > document, so I'll respond: at least I didn't intend to endorse this > behavior by mentioning it (if you meant that by "make a case for"). > In fact, this text event explicitly notes that it violates the > protocol, although today we might remove "even if", and explicitly > refer to RFC5942 instead of just saying "the protocol". Also, my > understanding of Section 4.4 is that it generally discusses known real > world issues with implementations that assume a prefix length of 64 > bits, some of which could in fact violate the standard. So I don't > think we should necessarily remove an example simply because it's > about a non-compliant implementation. In this specific case, I > thought it would be worth noting because this particular > implementation (ISC DHCPv6 client) should be quite widely used, and > because the seeming background reason for this behavior could lead to > other similar broken implementations. >=20 > If you and others still think this issue should be dropped with the > clarified intent, I wouldn't necessarily be opposed to that; I just > thought this issue would be useful in general in the context of this > document but that's probably only me. On the other hand, if the > issue is about specific text rather than the intent and specific > example, IMO we should try to fix the textual issue rather than remove > it. In the latter case, it would depends on specifically what you > thought was a problem, but if it's that this text could read as if it > endorses the broken behavior, one resolution would clarify that it > violates RFC5942 more explicitly. >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Jul 30 14:59:18 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59B91A039C for ; Wed, 30 Jul 2014 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0erUlfN37g8 for ; Wed, 30 Jul 2014 14:59:14 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id CE6DF1A0119 for ; Wed, 30 Jul 2014 14:59:09 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 30 Jul 2014 16:59:08 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f182.google.com [209.85.223.182] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f182.google.com with SMTP id y20so2461742ier.13 for ; Wed, 30 Jul 2014 14:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yLoWAV0jGKvK47ZvMcjipPKLKXKCDXCPmSZXLduKkmU=; b=Wb0oSgtQMY809R9tFppsGGBGTrlOPDVNxU6XAmpni+HxwyY2I/ExJUi0uwvgpMW4TH y691RadjKwfDHC1MYSvj7/sNsBUDBBepEs9jHQp9ZF8fw3q6B5hrW4ejnkKCtedKJB9x qG0n8b5PkTCkhe0QZdhgjkqi4tfW1oxsi0/yI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yLoWAV0jGKvK47ZvMcjipPKLKXKCDXCPmSZXLduKkmU=; b=dUkQOdl7fcj123Tv/5NyahnHXY6j4vgVE+M7FGEK6zFAXbryVwvrVho7iFwVZWOHv7 QFTu/md31/Z4vkEKKSeIZ3WWWPR4HlIS6UN8xtxJSiS3wNBtREys76CLE2wHj8CsBN8G gQVH7YMYbzLnp259unOvEMJ9SVYvp5pehpybTdo4v6V8d/xBeDDS3PmW7tQQPRuF7ZBn 86nBLELm/Ru4lKgUNfIjH98N5zsilUUrlUsG9OKLbEfFR39VYkQJuBYU8neluNq24PW4 DehRBix6GB5GX9vu1Fmxmbb6MEwRhzgDUx9ZaP8zQab1h2bKP8T7bb+XehgXBviH4CaS Ahmg== X-Gm-Message-State: ALoCoQkThXuEE1ViXCTXkc8YuNQoOZ53gaE2cIwqWLX5pePY/om66e+/QrGM8jyUECn/mhln0hOQJBlIXlbXl93ezESzxnjLQpQLMH2bepUWV2QUrEW/FrA= X-Received: by 10.43.70.205 with SMTP id yh13mr9572896icb.44.1406757548292; Wed, 30 Jul 2014 14:59:08 -0700 (PDT) X-Received: by 10.43.70.205 with SMTP id yh13mr9572866icb.44.1406757548038; Wed, 30 Jul 2014 14:59:08 -0700 (PDT) Received: from x-128-101-235-160.uofm-secure.wireless.umn.edu (x-128-101-235-160.uofm-secure.wireless.umn.edu. [128.101.235.160]) by mx.google.com with ESMTPSA id tp2sm14053442igb.7.2014.07.30.14.59.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:59:07 -0700 (PDT) Message-ID: <53D96AA6.7090006@umn.edu> Date: Wed, 30 Jul 2014 16:59:02 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= Subject: Re: 6MAN WG Last Call: References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> <53D95B69.7050403@gmail.com> In-Reply-To: <53D95B69.7050403@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/PPZRFpkg0L6usKcQ_ksY6ummtkw Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:59:17 -0000 I concur it shouldn't just be dropped. This is the kind of misunderstanding that needs to be pointed out. I always read the text as pointing out faulty behavior that should be corrected and not repeated. But if that intent can be clarified and strengthened, then please do so. On 7/30/14, 15:54 , Brian E Carpenter wrote: > Ole, > > I think we shouldn't drop it; IMHO we should adjust the text to make > it clear that this is faulty behaviour. > > Brian > > > On 31/07/2014 08:43, 神明達哉 wrote: >> At Tue, 29 Jul 2014 15:46:29 +0200, >> Ole Troan wrote: >> >>> Section 4.4: >>> At least one DHCPv6 client unconditionally installs a /64 prefix as >>> on-link when it configures an interface with an address, although >>> some specific operating system vendors seem to change this default >>> behavior by tweaking a client-side script. It does this (even if >>> technically it violates the protocol) because if there is no router >>> on the link, the hosts effectively would fail to communicate each >>> other with the configured addresses because the "on-link assumption" >>> was removed in [RFC4861]. This is not really about the magic number >>> of 64, but an implementation may sometimes pick a specific value of >>> prefix length due to the removal of the on-link assumption, and the >>> value chosen will most likely be 64. >>> >>> if so, that is in violation of RFC5942. I don't think this document should make a case for different behaviour than 5942 requires. >>> just drop the whole paragraph? >> >> (I believe) it was me who suggested including this issue in this >> document, so I'll respond: at least I didn't intend to endorse this >> behavior by mentioning it (if you meant that by "make a case for"). >> In fact, this text event explicitly notes that it violates the >> protocol, although today we might remove "even if", and explicitly >> refer to RFC5942 instead of just saying "the protocol". Also, my >> understanding of Section 4.4 is that it generally discusses known real >> world issues with implementations that assume a prefix length of 64 >> bits, some of which could in fact violate the standard. So I don't >> think we should necessarily remove an example simply because it's >> about a non-compliant implementation. In this specific case, I >> thought it would be worth noting because this particular >> implementation (ISC DHCPv6 client) should be quite widely used, and >> because the seeming background reason for this behavior could lead to >> other similar broken implementations. >> >> If you and others still think this issue should be dropped with the >> clarified intent, I wouldn't necessarily be opposed to that; I just >> thought this issue would be useful in general in the context of this >> document but that's probably only me. On the other hand, if the >> issue is about specific text rather than the intent and specific >> example, IMO we should try to fix the textual issue rather than remove >> it. In the latter case, it would depends on specifically what you >> thought was a problem, but if it's that this text could read as if it >> endorses the broken behavior, one resolution would clarify that it >> violates RFC5942 more explicitly. >> >> -- >> JINMEI, Tatuya >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Jul 31 00:25:30 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4E1A0383 for ; Thu, 31 Jul 2014 00:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUsniLYzyxKY for ; Thu, 31 Jul 2014 00:25:28 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA521A0292 for ; Thu, 31 Jul 2014 00:25:27 -0700 (PDT) Received: from dhcp-10-61-106-15.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0FA6F60CA; Thu, 31 Jul 2014 00:25:22 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1B2BC5CC-8E44-4D26-AAFA-F67D9312A7D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: <53D95B69.7050403@gmail.com> Date: Thu, 31 Jul 2014 09:25:21 +0200 Message-Id: <88FC0656-150C-43EB-A861-AE81E81AD873@employees.org> References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> <53D95B69.7050403@gmail.com> To: Brian E Carpenter , =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/WkA8oxBkwgV4iY18McEurNXKRWA Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 07:25:29 -0000 --Apple-Mail=_1B2BC5CC-8E44-4D26-AAFA-F67D9312A7D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I think we shouldn't drop it; IMHO we should adjust the text to make > it clear that this is faulty behaviour. that's fine with me. my reading of the current text was that it made it appear that it was = acceptable of an implementation to just make up a prefix length, if none = was given. as long as the text makes it clear that if it has no prefix = length, then there is no on-link prefix... cheers, Ole >> At Tue, 29 Jul 2014 15:46:29 +0200, >> Ole Troan wrote: >>=20 >>> Section 4.4: >>> At least one DHCPv6 client unconditionally installs a /64 prefix as >>> on-link when it configures an interface with an address, although >>> some specific operating system vendors seem to change this default >>> behavior by tweaking a client-side script. It does this (even if >>> technically it violates the protocol) because if there is no = router >>> on the link, the hosts effectively would fail to communicate each >>> other with the configured addresses because the "on-link = assumption" >>> was removed in [RFC4861]. This is not really about the magic = number >>> of 64, but an implementation may sometimes pick a specific value = of >>> prefix length due to the removal of the on-link assumption, and = the >>> value chosen will most likely be 64. >>>=20 >>> if so, that is in violation of RFC5942. I don't think this document = should make a case for different behaviour than 5942 requires. >>> just drop the whole paragraph? >>=20 >> (I believe) it was me who suggested including this issue in this >> document, so I'll respond: at least I didn't intend to endorse this >> behavior by mentioning it (if you meant that by "make a case for"). >> In fact, this text event explicitly notes that it violates the >> protocol, although today we might remove "even if", and explicitly >> refer to RFC5942 instead of just saying "the protocol". Also, my >> understanding of Section 4.4 is that it generally discusses known = real >> world issues with implementations that assume a prefix length of 64 >> bits, some of which could in fact violate the standard. So I don't >> think we should necessarily remove an example simply because it's >> about a non-compliant implementation. In this specific case, I >> thought it would be worth noting because this particular >> implementation (ISC DHCPv6 client) should be quite widely used, and >> because the seeming background reason for this behavior could lead to >> other similar broken implementations. >>=20 >> If you and others still think this issue should be dropped with the >> clarified intent, I wouldn't necessarily be opposed to that; I just >> thought this issue would be useful in general in the context of this >> document but that's probably only me. On the other hand, if the >> issue is about specific text rather than the intent and specific >> example, IMO we should try to fix the textual issue rather than = remove >> it. In the latter case, it would depends on specifically what you >> thought was a problem, but if it's that this text could read as if it >> endorses the broken behavior, one resolution would clarify that it >> violates RFC5942 more explicitly. >>=20 >> -- >> JINMEI, Tatuya >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 --Apple-Mail=_1B2BC5CC-8E44-4D26-AAFA-F67D9312A7D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT2e9iAAoJEFuJXizso86gyWEH/1IY5wS3IQkFwQ9f2htBumqz E7qqabyPTQaMyN2KSPQW1bUhsbYfeHssYcjEdPRcZMXL27hikmFxLhJEki40R9hw zbQL/SWqSpyQ7m2fVK3IorUizxS7untsDcj/TibVp+lZIFVJTk8YWBraPMsxlxoo 9trOnc97LqQkGMixTx+d4mnT3fdUzmvf6Aop62tx4Xg8JX+B4oHhWKt5QEIi3KCU 8O7Md3plk8n30DHpD9wJarVD2+vmild5KhOjUuMFEpFLK95f0qcwMriEBkih7sAY Cdh5T0KvQKz5Ukq4ayy4ZqzD7bQ+tkUx5Sc2iIlZ6xP2V8H5Wi5MR094dfJ3XkE= =UhW+ -----END PGP SIGNATURE----- --Apple-Mail=_1B2BC5CC-8E44-4D26-AAFA-F67D9312A7D7-- From nobody Thu Jul 31 15:11:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8463F1A01D6; Thu, 31 Jul 2014 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ0FDCJq_YdI; Thu, 31 Jul 2014 15:11:27 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085831A01CB; Thu, 31 Jul 2014 15:11:27 -0700 (PDT) Received: from [76.14.66.110] (port=50440 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCyZH-00082Z-0U; Thu, 31 Jul 2014 15:11:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 From: Philip Levis In-Reply-To: <53D84C2C.9050709@gmail.com> Date: Thu, 31 Jul 2014 15:11:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 3912120d3a1bcf28d29a6770933a4e79 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EBHCwNJ4izWPHR4KOzM-fZzHgJ0 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , Ole Troan , "Pascal Thubert \(pthubert\)" , Adrian Farrel X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:11:30 -0000 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter = wrote: > On 30/07/2014 12:02, Philip Levis wrote: > ... >> "This specification suggests that energy-saving is another >> compelling reason for a violation to the aforementioned >> rule." >>=20 >> makes the assumption that the energy saving is significant. >> Breaking the end-to-end nature of the flow label for some >> tiny saving seems like a mistake.=20 >=20 > I can't evaluate whether the energy saving is significant. > However, I don't have any deep faith in the e2e-ness of the > flow label. The reality (as RFC 6437 tries to recognise) > is that it's a mutable field, and is therefore untrustworthy > for e2e use. It has value for load balancing if all packets > of a given flow have the same label, whether the label is > set by the source or by a border device. For that reason, > I think the usage proposed in this draft is OK. >=20 > However, I do agree that at least a hand-waving estimate of > the % energy saving would be useful. >=20 > Brian Carpenter *shrug* My thoughts are pretty simple. I'm sure you know all this (as = one of the authors!) but I'll revisit for everyone else's sake. 6437 = states "A forwarding node MUST either leave a non-zero flow label value = unchanged or change it only for compelling operational security reasons = as described in Section 6.1." So, this is a MUST. Either the RPL flow label draft contradicts 6437 = (and should say so explicitly), or there should be an explicit update to = 6437. In fact, the current draft is misleading and incorrect. It says "but the RFC also indicates a violation to the rule can be accepted for = compelling reasons, and that security is a case justifying such a = violation. This specification suggests that energy-saving is another = compelling reason for a violation to the aforementioned rule." This is *not* what 6437 says. It says for compelling operational = security reasons, not compelling reasons, of which one case is security. Having been researching, implementing, and deploying low-power protocols = for over a decade, I've become exceedingly skeptical when someone = proposes a protocol with energy as a motivation without quantifying it. = For example, there are tons of protocols in the research literature = which talk about using transmission power control to save energy = (trading off range for power). But almost all of these papers ignore the = fact that (unlike mobile/cellular systems, which the authors have been = publishing in for years) RF is a tiny sliver of power in low-power = networks. So reducing your transmission (RF) power by 99% only reduces = your radio power by 50%. Generally a losing proposition. This is the = same reason why power saving in WiFi involves synchronization on AP = beacons and not adjusting transmit power. If someone doesn't quantify = the potential benefit based on real hardware and protocols, then it = could be based on mistaken assumptions. I mean, it doesn't take much here. Start with a working low-power RPL = network. Send packets with sizes following a reasonable distribution = based on an actual application. In one experiment send just those = packets. In another add the 8 bytes. In a third add 8 + the IP-in-IP = encapsulation. Measure the energy cost. And, generally speaking, if you can't demonstrate the problem very = easily, then perhaps it isn't a real problem at all. All that being said, I think using the flow label in this way is a good = idea, and definitely valuable. But as it is now, doing so violates 6437, = and so the assumptions implementers make when reading 6437. I think the = bar for doing so should be high, higher than vague suggestions and hand = waving which might not be correct. Phil From nobody Thu Jul 31 19:43:07 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F691A03BE for ; Thu, 31 Jul 2014 19:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW0mzSYgEay9 for ; Thu, 31 Jul 2014 19:43:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708C61A03BB for ; Thu, 31 Jul 2014 19:43:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU43359; Fri, 01 Aug 2014 02:43:02 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 03:43:01 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.141]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 10:42:55 +0800 From: "Zhangdacheng (Dacheng)" To: "ipv6@ietf.org" Subject: RE: I-D Action: draft-jiang-6man-cga-sec-option-00.txt Thread-Topic: I-D Action: draft-jiang-6man-cga-sec-option-00.txt Thread-Index: AQHPl11FmrcxRe6b0UGYLR500wsZBJuUYbKQgCbSBtA= Date: Fri, 1 Aug 2014 02:42:54 +0000 Message-ID: References: <20140704075441.19774.85374.idtracker@ietfa.amsl.com> <814D0BFB77D95844A01CA29B44CBF8A7A0C8DC@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A0C8DC@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lYdbX0QIpCdODvY7zqfQ4GIMUo8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 02:43:06 -0000 Hi, Hosnieh: I think you talking about a issues in the CGA specification rather than in = our document. You are indicating if the sec value is checked during the ver= ification process, this issues will no longer exist, right? Correct me if I= misunderstood anything. ^_^ Cheers Dacheng > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee > Sent: Monday, July 07, 2014 5:56 PM > To: ipv6@ietf.org > Subject: RE: I-D Action: draft-jiang-6man-cga-sec-option-00.txt >=20 > Hi, > I've read this document and I have some questions It was for purpose that= in > CGA document, they used 3 bits sec values as a part of an IP address. How= ever, > based on the current CGA specification document, this value has been igno= red > during the verification process and that was the result that I wrote > http://tools.ietf.org/html/draft-rafiee-6man-cga-attack-01 > But when you add new option but not a part of a CGA IP address, then the > attack explained in my document can be applicable like with current CGA > specification document. In other words, the attacker easily can try to ma= tch > different CGA sec values with the CGA value of the legitimate node. >=20 > So, I guess you need to somehow protect CGA from this attack. >=20 > Best, > Hosnieh >=20 >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, July 04, 2014 9:55 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jiang-6man-cga-sec-option-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CGA SEC Option for Secure Neighbor Discovery > Protocol > Authors : Sheng Jiang > Dacheng Zhang > Suresh Krishnan > Filename : draft-jiang-6man-cga-sec-option-00.txt > Pages : 5 > Date : 2014-07-04 >=20 > Abstract: > A Cryptographically Generated Address is an IPv6 addresses binding > with a public/private key pair. It is a vital component of Secure > Neighbor Discovery (SeND) protocol. The current SeND specifications > are lack of procedures to specify the Sec bits. A new SEC option is > defined accordingly to address this issue. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jiang-6man-cga-sec-option/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jiang-6man-cga-sec-option-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------