From nobody Wed Jun 1 09:27:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E025D12D5EB for ; Wed, 1 Jun 2016 09:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hnZkOvxcNqKf for ; Wed, 1 Jun 2016 09:27:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5D012D1E8 for ; Wed, 1 Jun 2016 09:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1195; q=dns/txt; s=iport; t=1464798421; x=1466008021; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ywRTtNl0lBO1AbefD1OOoCz85fvTJxrjfbrhy1slDn8=; b=O7Ug9Hu6zpOTf9/Z3eoEJ192Pot2Z/oozgGYCe0AQXoIDWhDYDDH1V32 aySTYbzbHm9ETudlwFy7NZhDOx9B/CBxjJ8i+p6nPbOLuceIyUl5FIOk8 cYYVGcAox+SEvcLCBDdvifkMKLxWsYXU8zQeDeHSRJEsPHdiEzA8/TMz+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgD3C09X/40NJK1dgz1WgQO6EgENg?= =?us-ascii?q?Xoigj2EZjgUAQEBAQEBAWUnhEyBCwGBACcEhyWBHQ6gC6EjAQEBAQYBAQEBAQE?= =?us-ascii?q?BGwWGJ4YGAYJ2hWoFjh2FGoUAAYV/iCCPHI9LAR4BAUKCE4FaiiZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,401,1459814400"; d="scan'208";a="278949421" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2016 16:26:58 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u51GQwTj027843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Jun 2016 16:26:58 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 11:26:58 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 11:26:57 -0500 From: "Shwetha Bhandari (shwethab)" To: 6man WG Subject: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvCJqnPiBA7R2OEO3VFjWqJgDtA== Date: Wed, 1 Jun 2016 16:26:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.40.6] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <142A92D49B4A9741AD398C673F888881@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:27:03 -0000 In view of the last call and the text added to 2460bis following the discussion on the thread "Adding headers and adding options to headers=B2.. We have been experimenting with HbyH header injection and removal for the purpose of collecting measurements relating to packet telemetry and we have a working implementation of the same in VPP [https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are testing and will be publishing results of this experiments in due course. While I am not proposing to add text to allow insertion and removal of header in 2460bis, I most definitely do not want new text - "Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473 ].=B2 banning it completely. I propose to continue having the text on extension header processing from 2460 as is without the new addition, as we do not have enough evidence/data on this ambiguity leading to interop issues and that being alleviated by addition of the above text. Thanks, Shwetha=20 From nobody Wed Jun 1 09:33:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3712D5EB for ; Wed, 1 Jun 2016 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RlagiNgxdS6Z for ; Wed, 1 Jun 2016 09:33:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A42B12D5FB for ; Wed, 1 Jun 2016 09:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2039; q=dns/txt; s=iport; t=1464798780; x=1466008380; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iATwL5200TFtSNaOlnkOP5zliCrRRzoUEuIUgSSjZLI=; b=Khms9fLOLw7/UV8q78QRnDndHT7/JzfEqSJXed3xMy4i6hfaZ8Fca4qa 1oubGbnfiW2GbLQTWAsIvx9PFeDP0GLrmqV951nXJhmkgwIj9D50TbVav sPGf91s3s6GBRLMkexlYgqu4KooiIiTMUEwNNqy4Edp8Y4lOVus/vT8TF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgBhDU9X/5xdJa1dgz1WfQa6EgENg?= =?us-ascii?q?XoXC4I9gzICgTI4FAEBAQEBAQFlJ4RFAQEBBAEBAWsXBAIBCBEEAQEoBycLFAk?= =?us-ascii?q?IAgQBEgiHCoEdDsEyAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNgTkBgnaFa?= =?us-ascii?q?gWIBIYZhRqFAAGFf4gZjyOPSwEeAQFCg21uiTh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,402,1459814400"; d="scan'208";a="108694751" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2016 16:32:59 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u51GWxNh007322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Jun 2016 16:32:59 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 11:32:58 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 11:32:58 -0500 From: "Frank Brockners (fbrockne)" To: "Shwetha Bhandari (shwethab)" , 6man WG Subject: RE: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvCJqnPiBA7R2OEO3VFjWqJgDtJ/UzQkA Date: Wed, 1 Jun 2016 16:32:58 +0000 Message-ID: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.190.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:33:07 -0000 +1 Agree that there are efforts (segment routing is another one) which experim= ent with in-flight insertion/removal of EH, and those efforts have running = code available. IMHO it would be way too early to decide banning that capability. Let's ke= ep the text in 2460 as is for now. Regards, Frank -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha Bhandari (sh= wethab) Sent: Wednesday, June 01, 2016 6:27 PM To: 6man WG Subject: RFC2460bis - Ticket #9 - Header injection issue=20 In view of the last call and the text added to 2460bis following the discus= sion on the thread "Adding headers and adding options to headers=B2.. We have been experimenting with HbyH header injection and removal for the p= urpose of collecting measurements relating to packet telemetry and we have = a working implementation of the same in VPP [https://gerrit.fd.io/r/#/admin= /projects/vpp] software data plane. We are testing and will be publishing r= esults of this experiments in due course. While I am not proposing to add text to allow insertion and removal of head= er in 2460bis, I most definitely do not want new text - "Extension headers must never be inserted by any node other than the source= of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473 ].=B2 banning it completely. I propose to continue having the text on extension header processing from 2460 as is without the new addition, as we do not have enough evidence/data= on this ambiguity leading to interop issues and that being alleviated by a= ddition of the above text. Thanks, Shwetha=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Wed Jun 1 13:47:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0A12D609 for ; Wed, 1 Jun 2016 13:47:49 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZwwE23FyogkC for ; Wed, 1 Jun 2016 13:47:48 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D0312D600 for ; Wed, 1 Jun 2016 13:47:48 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id g64so21819833pfb.2 for ; Wed, 01 Jun 2016 13:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xK7HI2OJL9Irkw27HIHjbWciUIV9EQFoZMQdVofPRj4=; b=qoou8ZKjMxI5x7LNzM3RNbRCwn9pP56GTqubCCrbT3uJkaw0SAPT8L4M8ftAjpRUFh kWjhHXbLiQgUNdBcdtV1VYucJYh8zv1l3ASONzVpUzeYACpIJxGM0iISUNPPiba6TEwA D48pmhrk5inT8inwNvwoVv7EU/Kn4WsEeeO/jIh/KHniNTNfC7Isq0758spWik532UHT 37NwldTC6oduh9gWrmCx+bUz7ZNqITZznHT82dAqtfl3fNz65V/dtrGu7syubXFEcAuS c8AgJ7xSCrHxSsuBvsLG8Zkkdl/bcXKzfJE9Be4kFd70ZivC6Nf3O+SgyYZIy1PA7WVN eb+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xK7HI2OJL9Irkw27HIHjbWciUIV9EQFoZMQdVofPRj4=; b=fafxwzu0n/J724EPt/5w8wOeZvVT2a0y/MKQVP4v2+JYR7iEA2VV7At8vl7/VKZZZr 6H5ZiDunH6StHK3n1su2tGKW/JAyOmmARiYj8hLDmRtVcR7f5Zj5YDPyrwAThnBAa8Wu Toj5P2g30cA2ZtzuyXI/1yu0WW+8qjqQ27qldlRoawYiRY3qfo/XdxcOa/vPKwgDVI8c BIoI/A5kWHD+j158opiFBMq2fTbv4+PPtGujD8IxJ4eIDu0aCbqr1SOhX11Bzg6I+SSW ppXdMq21MNAOWkMCXzC61mmlyCWCbKF7z/JeSVPb3UNr+2og5nYd35uT8UkvKVnW0Qk6 zNBQ== X-Gm-Message-State: ALyK8tIr7zX5rOdQo+llKXGNC1y5U9KJ0BmXuYluRUIv9iclx/njUe/cuM/VAdtitMS6yw== X-Received: by 10.98.66.149 with SMTP id h21mr12634465pfd.56.1464814067792; Wed, 01 Jun 2016 13:47:47 -0700 (PDT) Received: from [192.168.178.22] (139.22.255.123.dynamic.snap.net.nz. [123.255.22.139]) by smtp.gmail.com with ESMTPSA id 83sm50183962pfl.12.2016.06.01.13.47.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 13:47:47 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Frank Brockners (fbrockne)" , "Shwetha Bhandari (shwethab)" , 6man WG References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 2 Jun 2016 08:47:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 20:47:50 -0000 Hi, The reason for that text (which I and others assert is a clarifcation of the intent of RFC 2460 and its predecessor RFC 1883) is to make it clear that such insertions are not OK. The reasons that they are not OK have been discussed here several times. The fact that such insertions and deletions can be made to work inside a closed domain doesn't make them OK for general use on the Internet. Regards Brian Carpenter On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote: > +1 >=20 > Agree that there are efforts (segment routing is another one) which exp= eriment with in-flight insertion/removal of EH, and those efforts have ru= nning code available. > IMHO it would be way too early to decide banning that capability. Let'= s keep the text in 2460 as is for now. >=20 > Regards, Frank >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha Bhandari= (shwethab) > Sent: Wednesday, June 01, 2016 6:27 PM > To: 6man WG > Subject: RFC2460bis - Ticket #9 - Header injection issue=20 >=20 > In view of the last call and the text added to 2460bis following the di= scussion on the thread "Adding headers and adding options to headers=C2=B2= =2E. >=20 > We have been experimenting with HbyH header injection and removal for t= he purpose of collecting measurements relating to packet telemetry and we= have a working implementation of the same in VPP [https://gerrit.fd.io/r= /#/admin/projects/vpp] software data plane. We are testing and will be pu= blishing results of this experiments in due course. >=20 > While I am not proposing to add text to allow insertion and removal of = header in 2460bis, I most definitely do not want new text - >=20 > "Extension headers must never be inserted by any node other than the so= urce of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in [RFC247= 3 > ].=C2=B2 >=20 > banning it completely. >=20 >=20 > I propose to continue having the text on extension header processing fr= om > 2460 as is without the new addition, as we do not have enough evidence/= data on this ambiguity leading to interop issues and that being alleviate= d by addition of the above text. >=20 > Thanks, > Shwetha=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Jun 1 13:55:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4812D611 for ; Wed, 1 Jun 2016 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 cZlGcy9lmF38 for ; Wed, 1 Jun 2016 13:55:18 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA5A12D609 for ; Wed, 1 Jun 2016 13:55:18 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0020.outbound.protection.outlook.com [213.199.154.20]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-67-9ponmY0WRJ6hDEQwkyuI6w-1; Wed, 01 Jun 2016 21:55:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=veshGGmhtIRVaYbIgnHLiogGomKE23QYVorZUYreKBQ=; b=fonlEjaw7Duuvk0OOexTj1VmX+dqiKJKxVx7P3bcoRmPiM7Lj5JwKfAEGbMfQTVwmI1oNVbt83E6k30QKCdpVdP/jrQfNE9Lr2riWW+3nk01x7gN3gLj8SvCKn4wlz5GbRQ9ekBzxhO8npdTROKqD2SaLSu5havxdU/W40nePS0= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.501.7; Wed, 1 Jun 2016 20:55:11 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0501.013; Wed, 1 Jun 2016 20:55:11 +0000 From: Tim Chown To: Brian E Carpenter Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvCJqnPiBA7R2OEO3VFjWqJgDtJ/UzQkAgABIaYCAAAIugA== Date: Wed, 1 Jun 2016 20:55:11 +0000 Message-ID: <946079A5-0408-4365-BBF0-420EE1E7C929@jisc.ac.uk> References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:c53:bb71:6fef:a6ff] x-ms-office365-filtering-correlation-id: 9e4a3f06-1f85-4b95-a0a9-08d38a5f060f x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 5:MkZdcEtqPuuhk5UPxXIYLxHbXjG1t+IGI/GuaUf4S+9dLcjRj34/QC125xkpVu6sCPWeu3RLbBIfYCB5xEhSAzIXgOUVsvC2wXwHE33C6DRQ6D2nbzkoSaOXtXR8UnPU8hokZ1LJLFCPgJ9CPtxRGg==; 24:s+XSZ06L7pRrRzrUTx2RrL/zQ0NSTSOsBgCN3fNSMpKLEC4wWvkLK7LA5PBQlrYxQ7OaWE0kupjufBjPyKBWANtI4O4Nv44Md5sN4TpgJXY=; 7:Cr94kEtaYku0b8llGI9EYzmAqWsSvokkqR0+D2AnWHy3yNXyK1TrIjYb3qNBiXDqzVxKGE67ApYioyX7br4g/aPBV2GKJNjyTWcYch61ZmHHqB4H4HFfnQhA0Rhh1BqCTX0KjXs3dn4LWzPcMg4UaKg08CzDgABP5tdQ1h7xtPT9O+SXz0xgrTI+L6sODkSC; 20:ois4xkWRzSPmP8eeroxqM3UPQbAaA5j0GokAAm6+oCoOndeU+70Vq74jg3w9TGLMbkdzR8zREw3ko7aV6nMGMlBYIWIuEZEJ4mCq62Of/WQ9jjoWediz3pdVHVdcWKO5pk1A+sQFcE/OiOAyFZ4jdA4PhtNcLBBc4ex7HasE/pM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(5213294742642)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(24454002)(5002640100001)(8936002)(82746002)(92566002)(5004730100002)(83716003)(81166006)(2900100001)(3280700002)(77096005)(2950100001)(57306001)(8676002)(106116001)(10400500002)(87936001)(86362001)(4326007)(122556002)(2906002)(74482002)(50986999)(189998001)(36756003)(50226002)(586003)(110136002)(5008740100001)(19580405001)(3660700001)(19580395003)(102836003)(15975445007)(11100500001)(6116002)(33656002)(76176999)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <876D761EB2B484479B4AA1320009B78C@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 20:55:11.5866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: 9ponmY0WRJ6hDEQwkyuI6w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 20:55:21 -0000 SGksDQoNCj4gT24gMSBKdW4gMjAxNiwgYXQgMjE6NDcsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBUaGUgcmVh c29uIGZvciB0aGF0IHRleHQgKHdoaWNoIEkgYW5kIG90aGVycyBhc3NlcnQgaXMgYSBjbGFyaWZj YXRpb24NCj4gb2YgdGhlIGludGVudCBvZiBSRkMgMjQ2MCBhbmQgaXRzIHByZWRlY2Vzc29yIFJG QyAxODgzKSBpcyB0byBtYWtlDQo+IGl0IGNsZWFyIHRoYXQgc3VjaCBpbnNlcnRpb25zIGFyZSBu b3QgT0suIFRoZSByZWFzb25zIHRoYXQgdGhleSBhcmUNCj4gbm90IE9LIGhhdmUgYmVlbiBkaXNj dXNzZWQgaGVyZSBzZXZlcmFsIHRpbWVzLiBUaGUgZmFjdCB0aGF0IHN1Y2gNCj4gaW5zZXJ0aW9u cyBhbmQgZGVsZXRpb25zIGNhbiBiZSBtYWRlIHRvIHdvcmsgaW5zaWRlIGEgY2xvc2VkIGRvbWFp bg0KPiBkb2Vzbid0IG1ha2UgdGhlbSBPSyBmb3IgZ2VuZXJhbCB1c2Ugb24gdGhlIEludGVybmV0 Lg0KDQpJbmRlZWQuIEFuZCB0aGVyZSBhcmUgbWFueSBtb3JlIGV4YW1wbGVzIHdoZXJlIHRoZSBz YW1lIGFwcGxpZXMuDQoNClRpbQ0KDQo+IFJlZ2FyZHMNCj4gICBCcmlhbiBDYXJwZW50ZXINCj4g DQo+IE9uIDAyLzA2LzIwMTYgMDQ6MzIsIEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIHdyb3Rl Og0KPj4gKzENCj4+IA0KPj4gQWdyZWUgdGhhdCB0aGVyZSBhcmUgZWZmb3J0cyAoc2VnbWVudCBy b3V0aW5nIGlzIGFub3RoZXIgb25lKSB3aGljaCBleHBlcmltZW50IHdpdGggaW4tZmxpZ2h0IGlu c2VydGlvbi9yZW1vdmFsIG9mIEVILCBhbmQgdGhvc2UgZWZmb3J0cyBoYXZlIHJ1bm5pbmcgY29k ZSBhdmFpbGFibGUuDQo+PiBJTUhPIGl0ICB3b3VsZCBiZSB3YXkgdG9vIGVhcmx5IHRvIGRlY2lk ZSBiYW5uaW5nIHRoYXQgY2FwYWJpbGl0eS4gTGV0J3Mga2VlcCB0aGUgdGV4dCBpbiAyNDYwIGFz IGlzIGZvciBub3cuDQo+PiANCj4+IFJlZ2FyZHMsIEZyYW5rDQo+PiANCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU2h3ZXRoYSBCaGFuZGFyaSAoc2h3ZXRoYWIpDQo+PiBTZW50OiBX ZWRuZXNkYXksIEp1bmUgMDEsIDIwMTYgNjoyNyBQTQ0KPj4gVG86IDZtYW4gV0cgPGlwdjZAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRkMyNDYwYmlzIC0gVGlja2V0ICM5IC0gSGVhZGVyIGluamVj dGlvbiBpc3N1ZSANCj4+IA0KPj4gSW4gdmlldyBvZiB0aGUgbGFzdCBjYWxsIGFuZCB0aGUgdGV4 dCBhZGRlZCB0byAyNDYwYmlzIGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgdGhyZWFk ICJBZGRpbmcgaGVhZGVycyBhbmQgYWRkaW5nIG9wdGlvbnMgdG8gaGVhZGVyc8KyLi4NCj4+IA0K Pj4gV2UgaGF2ZSBiZWVuIGV4cGVyaW1lbnRpbmcgd2l0aCBIYnlIIGhlYWRlciBpbmplY3Rpb24g YW5kIHJlbW92YWwgZm9yIHRoZSBwdXJwb3NlIG9mIGNvbGxlY3RpbmcgbWVhc3VyZW1lbnRzIHJl bGF0aW5nIHRvIHBhY2tldCB0ZWxlbWV0cnkgYW5kIHdlIGhhdmUgYSB3b3JraW5nIGltcGxlbWVu dGF0aW9uIG9mIHRoZSBzYW1lIGluIFZQUCBbaHR0cHM6Ly9nZXJyaXQuZmQuaW8vci8jL2FkbWlu L3Byb2plY3RzL3ZwcF0gc29mdHdhcmUgZGF0YSBwbGFuZS4gV2UgYXJlIHRlc3RpbmcgYW5kIHdp bGwgYmUgcHVibGlzaGluZyByZXN1bHRzIG9mIHRoaXMgZXhwZXJpbWVudHMgaW4gZHVlIGNvdXJz ZS4NCj4+IA0KPj4gV2hpbGUgSSBhbSBub3QgcHJvcG9zaW5nIHRvIGFkZCB0ZXh0IHRvIGFsbG93 IGluc2VydGlvbiBhbmQgcmVtb3ZhbCBvZiBoZWFkZXIgaW4gMjQ2MGJpcywgSSBtb3N0IGRlZmlu aXRlbHkgZG8gbm90IHdhbnQgbmV3IHRleHQgLQ0KPj4gDQo+PiAiRXh0ZW5zaW9uIGhlYWRlcnMg bXVzdCBuZXZlciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZSBvdGhlciB0aGFuIHRoZSBzb3VyY2Ug b2YgdGhlIHBhY2tldC4gIElQIEVuY2Fwc3VsYXRpb24gbXVzdCBiZSB1c2VkIHRvIG1lZXQgYW55 DQo+PiByZXF1aXJlbWVudCBmb3IgaW5zZXJ0aW5nIGhlYWRlcnMsIGZvciBleGFtcGxlLCBhcyBk ZWZpbmVkIGluICAgW1JGQzI0NzMNCj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MjQ3Mz5dLsKyDQo+PiANCj4+IGJhbm5pbmcgaXQgY29tcGxldGVseS4NCj4+IA0KPj4gDQo+PiBJ IHByb3Bvc2UgdG8gY29udGludWUgaGF2aW5nIHRoZSB0ZXh0IG9uIGV4dGVuc2lvbiBoZWFkZXIg cHJvY2Vzc2luZyBmcm9tDQo+PiAyNDYwIGFzIGlzIHdpdGhvdXQgdGhlIG5ldyBhZGRpdGlvbiwg YXMgd2UgZG8gbm90IGhhdmUgZW5vdWdoIGV2aWRlbmNlL2RhdGEgb24gdGhpcyBhbWJpZ3VpdHkg bGVhZGluZyB0byBpbnRlcm9wIGlzc3VlcyBhbmQgdGhhdCBiZWluZyBhbGxldmlhdGVkIGJ5IGFk ZGl0aW9uIG9mIHRoZSBhYm92ZSB0ZXh0Lg0KPj4gDQo+PiBUaGFua3MsDQo+PiBTaHdldGhhIA0K Pj4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Wed Jun 1 17:15:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A057012B005 for ; Wed, 1 Jun 2016 17:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OmiB-XM4EUw5 for ; Wed, 1 Jun 2016 17:15:35 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1275A12B059 for ; Wed, 1 Jun 2016 17:15:34 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d127so50192149vkh.2 for ; Wed, 01 Jun 2016 17:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=egPjJ2RBfkgv6K9OY9wxjQ6HPZGIXYPy2N5odSRtI4A=; b=myhRzgx7SG7QmcwpKbyRIW84mv6pitJV4V2C9g1fQmCVy/4bTl9vDPfdLQ8NPw6vE7 jpfMRBw/U2VZeWuu3OgtCcCGlR4tuX/d5G6W4p0QB/SrUhnL2zorFGqsMOw5xutZhC8p fCFsn5t4VY079Y+/5iDC1wpEcp2QAY/jq8VPbg+1Bkw5O74VOJz2d8cUoOOcbuDY+fOQ UM+HEqP3bTEPy5EaSO19n6Dvu1Ei9yTdOhXRLlxODs2o8pJ0nASNjF7OO1CQUyBrPNBN cwIJVw2KEpX87x0MiKalRWj/A1im0dlRhtYuqfNJsCw2LNh4VXwoFD/6xjxLdmr8dEeA Tk8w== 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:date :message-id:subject:from:to:cc; bh=egPjJ2RBfkgv6K9OY9wxjQ6HPZGIXYPy2N5odSRtI4A=; b=V54qsHj0b1mu8Z6W+nQnvh7Drs4N5LKaMe+yumMVTWOeSs9JdYxhDCvFnVOw02iewZ Adwo9p45nZs7EzZUpXS620oT9z58KCIrG8qinRCMEFa/XcdfHFjcxNaCAPoLFICzO6eP oW/5UTY8BpQhHEYoesY9mkfWJH9V71JnWOn6IBlQRrEfFLC3jb2xyRmyrPOjxWXTftJ9 K29wUQ2YrdoZv/jbvDmQCguVRk5P6NuqqBGUHTPVPQj0mnN8J6C6yLo6a79Jz3VA3a3P eDPydnamLfkDgpqu8cQdbnwA38pb/L1LQUKCWbgU+Tx58TEoEZuOG21RtQM3XF/oltU8 TNcQ== X-Gm-Message-State: ALyK8tKp1Xs5MVx14eUQ4/QNb4SWyW0nf9e8w1lFy9b58tHM3gHmTWbJ3ZnAjznZhbjHNg4+m0APJNegsLmyQg== MIME-Version: 1.0 X-Received: by 10.159.37.100 with SMTP id 91mr2902788uaz.67.1464826533978; Wed, 01 Jun 2016 17:15:33 -0700 (PDT) Received: by 10.176.3.168 with HTTP; Wed, 1 Jun 2016 17:15:33 -0700 (PDT) Received: by 10.176.3.168 with HTTP; Wed, 1 Jun 2016 17:15:33 -0700 (PDT) In-Reply-To: <946079A5-0408-4365-BBF0-420EE1E7C929@jisc.ac.uk> References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> <946079A5-0408-4365-BBF0-420EE1E7C929@jisc.ac.uk> Date: Thu, 2 Jun 2016 10:15:33 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue From: Mark Smith To: Tim Chown Content-Type: multipart/alternative; boundary=94eb2c122da437275105344081fc Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 00:15:38 -0000 --94eb2c122da437275105344081fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 Jun 2016 06:25, "Tim Chown" wrote: > > Hi, > > > On 1 Jun 2016, at 21:47, Brian E Carpenter wrote: > > > > Hi, > > > > The reason for that text (which I and others assert is a clarifcation > > of the intent of RFC 2460 and its predecessor RFC 1883) is to make > > it clear that such insertions are not OK. The reasons that they are > > not OK have been discussed here several times. The fact that such > > insertions and deletions can be made to work inside a closed domain > > doesn't make them OK for general use on the Internet. > > Indeed. And there are many more examples where the same applies. > I would also be expecting an update to the definition of the source address field if this was to go ahead. Regards, Mark. > Tim > > > Regards > > Brian Carpenter > > > > On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote: > >> +1 > >> > >> Agree that there are efforts (segment routing is another one) which experiment with in-flight insertion/removal of EH, and those efforts have running code available. > >> IMHO it would be way too early to decide banning that capability. Let's keep the text in 2460 as is for now. > >> > >> Regards, Frank > >> > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha Bhandari (shwethab) > >> Sent: Wednesday, June 01, 2016 6:27 PM > >> To: 6man WG > >> Subject: RFC2460bis - Ticket #9 - Header injection issue > >> > >> In view of the last call and the text added to 2460bis following the discussion on the thread "Adding headers and adding options to headers=C2= =B2.. > >> > >> We have been experimenting with HbyH header injection and removal for the purpose of collecting measurements relating to packet telemetry and we have a working implementation of the same in VPP [ https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are testing and will be publishing results of this experiments in due course. > >> > >> While I am not proposing to add text to allow insertion and removal of header in 2460bis, I most definitely do not want new text - > >> > >> "Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any > >> requirement for inserting headers, for example, as defined in [RFC2473 > >> ].=C2=B2 > >> > >> banning it completely. > >> > >> > >> I propose to continue having the text on extension header processing from > >> 2460 as is without the new addition, as we do not have enough evidence/data on this ambiguity leading to interop issues and that being alleviated by addition of the above text. > >> > >> Thanks, > >> Shwetha > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c122da437275105344081fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 Jun 2016 06:25, "Tim Chown" <Tim.Chown@jisc.ac.uk> wrote:
>
> Hi,
>
> > On 1 Jun 2016, at 21:47, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> >
> > Hi,
> >
> > The reason for that text (which I and others assert is a clarifca= tion
> > of the intent of RFC 2460 and its predecessor RFC 1883) is to mak= e
> > it clear that such insertions are not OK. The reasons that they a= re
> > not OK have been discussed here several times. The fact that such=
> > insertions and deletions can be made to work inside a closed doma= in
> > doesn't make them OK for general use on the Internet.
>
> Indeed. And there are many more examples where the same applies.
>

I would also be expecting an update to the definition of the= source address field if this was to go ahead.

Regards,
Mark.

> Tim
>
> > Regards
> >=C2=A0 =C2=A0Brian Carpenter
> >
> > On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote:
> >> +1
> >>
> >> Agree that there are efforts (segment routing is another one)= which experiment with in-flight insertion/removal of EH, and those efforts= have running code available.
> >> IMHO it=C2=A0 would be way too early to decide banning that c= apability. Let's keep the text in 2460 as is for now.
> >>
> >> Regards, Frank
> >>
> >> -----Original Message-----
> >> From: ipv6 [mailto:i= pv6-bounces@ietf.org] On Behalf Of Shwetha Bhandari (shwethab)
> >> Sent: Wednesday, June 01, 2016 6:27 PM
> >> To: 6man WG <ipv6@ietf.or= g>
> >> Subject: RFC2460bis - Ticket #9 - Header injection issue
> >>
> >> In view of the last call and the text added to 2460bis follow= ing the discussion on the thread "Adding headers and adding options to= headers=C2=B2..
> >>
> >> We have been experimenting with HbyH header injection and rem= oval for the purpose of collecting measurements relating to packet telemetr= y and we have a working implementation of the same in VPP [https://gerrit.fd.io/r/#/admin/proj= ects/vpp] software data plane. We are testing and will be publishing re= sults of this experiments in due course.
> >>
> >> While I am not proposing to add text to allow insertion and r= emoval of header in 2460bis, I most definitely do not want new text -
> >>
> >> "Extension headers must never be inserted by any node ot= her than the source of the packet.=C2=A0 IP Encapsulation must be used to m= eet any
> >> requirement for inserting headers, for example, as defined in= =C2=A0 =C2=A0[RFC2473
> >> <https://t= ools.ietf.org/html/rfc2473>].=C2=B2
> >>
> >> banning it completely.
> >>
> >>
> >> I propose to continue having the text on extension header pro= cessing from
> >> 2460 as is without the new addition, as we do not have enough= evidence/data on this ambiguity leading to interop issues and that being a= lleviated by addition of the above text.
> >>
> >> Thanks,
> >> Shwetha
> >>
> >>
> >> -------------------------------------------------------------= -------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> -------------------------------------------------------------= -------
> >>
> >> -------------------------------------------------------------= -------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> -------------------------------------------------------------= -------
> >>
> >
> > -----------------------------------------------------------------= ---
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > -----------------------------------------------------------------= ---
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--94eb2c122da437275105344081fc-- From nobody Wed Jun 1 17:20:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8A12D629 for ; Wed, 1 Jun 2016 17:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LHvnGhFRXTAJ for ; Wed, 1 Jun 2016 17:19:57 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7460812D573 for ; Wed, 1 Jun 2016 17:19:57 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id z189so97789857itg.0 for ; Wed, 01 Jun 2016 17:19:57 -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; bh=Xkh04unBpt+UDYqqR7DWbv8cZ5R5s92Ia5YMHMQDYTI=; b=sbXtKx/rI1mDedfxgIZntOxuiQHlOHp2cAj4tOG31Ry0NNgc2YkGsTghUESX4wmnFd RFuO9ORrlRzbtEu4As+G94VKIE05mcV1O+6Y2WkqrUzcDrPkTEDOC3EvqPJ9a2QciddH an4whvviA1Tn2W4XGhmp/x/bHAr6oiI9xwABd0fy3hh2XeMtd50f+aWx2CfsH17sEOUc RzYp2ukcKo1ToS1EjiHH5F2O37mNIqwg6V/x7ne/oZdvWYXDU0XSgn+9j5Q7JxVmoVND J8LdWZVHpMOkv6pSc4GqcLO0j668DzT+BVSO7QsSut9OAVRWu3CFhXmTZRlc13w4c9jr WMbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Xkh04unBpt+UDYqqR7DWbv8cZ5R5s92Ia5YMHMQDYTI=; b=FoVMhF1+56PHGyc8oYH9JpOKkhqziooy04jVwm88d5O4HZAvn4AwT/5FB7aWggqTec KH+2/lOCH2QAjmziaMorc14YchIwLZe3W2AlE7AnOnWlaEI1KxKM/rEr+eTA4mjZNQa+ JNeRIf5Fm7sfTUwds3tPvC5w1aD44LeJuQPpAbFayxFCEV91H0cFjROs/JJgLPq1oBmx yET5Xc8ha/4yF8kNuNU2vi65z+0wkE/fqqAyuQKcgsnuF3YZZS9jPajKRQj3G9FO8L14 2aRUvEcaVQuwltm2iii+KrQRTHsfz6/Z1DiSr1mq0McO/JChSAbvmwWybU4NWw2fKAk+ JQXA== X-Gm-Message-State: ALyK8tIgau4l0EC/rp4JUQnKCvWYsBua+RxfyLyB8znxxToUqazy9EylLV2vOLhQkNYcM2Yp/Ipig5ldbD5u+Q== MIME-Version: 1.0 X-Received: by 10.36.13.76 with SMTP id 73mr576602itx.79.1464826796831; Wed, 01 Jun 2016 17:19:56 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.159.148 with HTTP; Wed, 1 Jun 2016 17:19:56 -0700 (PDT) In-Reply-To: References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> Date: Wed, 1 Jun 2016 17:19:56 -0700 X-Google-Sender-Auth: AW2zIXRHilE5-cFuxgIoVBtTul0 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 00:19:59 -0000 At Thu, 2 Jun 2016 08:47:49 +1200, Brian E Carpenter wrote: > The reason for that text (which I and others assert is a clarifcation > of the intent of RFC 2460 and its predecessor RFC 1883) is to make > it clear that such insertions are not OK. The reasons that they are > not OK have been discussed here several times. The fact that such > insertions and deletions can be made to work inside a closed domain > doesn't make them OK for general use on the Internet. +1. I've stated my points on this several times, so I won't repeat them in detail, but the "rationale" for leaving it unclear referring to "interop issues" simply doesn't make sense to me. I'm happy to hear the discussion on revisiting the original intent as an update to rfc2460bis, but for the scope of rfc2460bis itself clarifying it is the right thing to do. -- JINMEI, Tatuya From nobody Thu Jun 2 00:41:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7112D0F5 for ; Thu, 2 Jun 2016 00:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 mpeNdSq3WpR6 for ; Thu, 2 Jun 2016 00:41:36 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C7412D63E for ; Thu, 2 Jun 2016 00:41:35 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 07:41:33 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 804A49CC51; Thu, 2 Jun 2016 00:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=jaZN6TqU09OgVzvc6lzv5MgF/r4=; b= AWso9ikImv0Fi3F1ss6sJko3snCUAiCvXcvOXWs7bemEOxjQIUSJvg0v6TaaD7FY I8nul5+dNIWoV6MMpkRnnxesynEzlAiCmbfJmH3VbEZeAs4Es8+/Z65COoc2a28h Wc+vBQ1cCc5j6N1afypFcWHqPelCPQ5GovqHEUFZTUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=O1CslM/IFSohW27LZAfizbEpgn GoYG2mp3A/7j/1MYrK4s4Gcq0uVUkReP+B8ixTI0aFcXKcXemFA3Z7Rn7GK5PN+X uKT5pG4dj1bzv3Jr3xes+CtxUDdqM5PWJhr70zSuLxsFeztu6AxdbAKS+LJwL0Yb g0UcHp+xoL8g8ROWg= Received: from h.hanazo.no (eduroam-0-91.enst.fr [137.194.56.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 47D4F9CC4E; Thu, 2 Jun 2016 00:41:32 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BD97A1791D60; Thu, 2 Jun 2016 09:41:34 +0200 (CEST) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A6B3012D-8561-478D-BC6F-BF533E38C335"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160531.111923.74710755.sthaug@nethelp.no> Date: Thu, 2 Jun 2016 09:41:32 +0200 Message-Id: References: <02BC17C8-35B8-4BC4-9A3B-D7DF61C84CAA@employees.org> <90628A01-A7C0-4D2C-83ED-74F3F9963E00@employees.org> <20160531.111923.74710755.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 07:41:38 -0000 --Apple-Mail=_A6B3012D-8561-478D-BC6F-BF533E38C335 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Minor comment: >=20 >>> Your statement does not mean much unless you define "public". The = difference between RFC 4941 addresses and other addresses is not are = that RFC 4941 addresses are not persistent. >>=20 >> IPv6 addresses are not persistent. they are all ephemeral. it is just = a matter of the lifetime. >=20 > While that may be technically true, it certainly goes against the way > a lot of people *think* about IPv6 addresses, and could easily lead to > misunderstanding. >=20 > For example, I have a fixed /64 for the link to my home server, and > another fixed /64 (out of a /56) for my home LAN. The server has these > two /64 addresses statically configured on separate Ethernet = interfaces. > To me it's not particularly useful to think of these addresses as > ephemeral. Understood. Although you'll thank me the day your ISP renumbers your top = 56 bits. (Even in this case, that's you meeting yourself in the door. ;-)) Cheers, Ole --Apple-Mail=_A6B3012D-8561-478D-BC6F-BF533E38C335 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 iQEcBAEBCgAGBQJXT+MuAAoJED4aXnjSQuKWMsEH/2jvscYnQz+C+61QabQAPIKm K3j8F7K0IsUG+5bYrg1L2AMwI1rTuyxO3hEvCugsgYruSwT2cf2PQXeEkUqzvnSp V2MYke+T2bvTT4GegZkq3rdbQQvFRO25gJAaRjZ5bOM0EMmrTZIzGeIPlKNeoxfe fDBcr/WkZlqBO4UGOXG/jElk/zdRod57CFFr7u3s6ID4rmKZ+pauo/KGr2L9kxzM VI+2rF6+dJWvXNDrHKGI9BO/uBNbIOoKM9kc7SCU5sLfwC3a0iFjg8HXR2k33D1D qMAnsKC0GEBeT1XR7nvcvX45EpoE9RvHVLzSVNjuk5Mg8LImZxUiHbZgt2Ik9X8= =9eCv -----END PGP SIGNATURE----- --Apple-Mail=_A6B3012D-8561-478D-BC6F-BF533E38C335-- From nobody Thu Jun 2 01:00:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873DE12D0F5 for ; Thu, 2 Jun 2016 01:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 C9szXww_b_O7 for ; Thu, 2 Jun 2016 01:00:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7358112B050 for ; Thu, 2 Jun 2016 01:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5436; q=dns/txt; s=iport; t=1464854448; x=1466064048; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0OjFEWBCDRYcbnj9hdhSHk6K6wDOabwh2BzzQYphMsU=; b=RkWkyUerUmxFJ6N6iCO4T7lC6eCYEemkIYA+xMEX2PyURxaTKWkguR8p 7c7BRdOthlr82lapewCDCZ5wfIPc2a+CHzNvTf3JX2e7Tn6eScQFCWxpj iga/xfqkg4lfhqoJUwovgBvSjtiZc7BUEfzBH9zCEpLEk8goroNi2pAla 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgDh5k9X/5tdJa1egzpWfQauOotvA?= =?us-ascii?q?Q2BeRcLgj2DMgIcgRg4FAEBAQEBAQFlJ4RFAQEBBAEBASAROhcEAgEIEQQBAQE?= =?us-ascii?q?CAiMDAgICHwYLFAEICAIEARIIhwqBAwMXDrANjHENhB8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYEBhSaETYE5AYEJgW0ngmqCWQWIBJAAMwGFf4YngXKPI4dkh2c?= =?us-ascii?q?BHgEBQoNtbgGJfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,405,1459814400"; d="scan'208";a="110712567" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 08:00:47 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5280lc3031980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2016 08:00:47 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 03:00:46 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 2 Jun 2016 03:00:46 -0500 From: "Frank Brockners (fbrockne)" To: Brian E Carpenter , "Shwetha Bhandari (shwethab)" , 6man WG Subject: RE: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvEbc6kctX/SPtUSZkxhYtoSl8Z/VziCg Date: Thu, 2 Jun 2016 08:00:46 +0000 Message-ID: <29e5093f14124a7da8b1d615778db25f@XCH-RCD-008.cisco.com> References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.190.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 08:00:51 -0000 SGksDQoNClNvIGZhciBJIHVuZGVyc3Rvb2QgUkZDMjQ2MCBhcyBhIHByb3RvY29sIHNwZWMgLSBu b3QgYW4gZXhjbHVzaXZlIGRlcGxveW1lbnQgZ3VpZGVsaW5lIGZvciB0aGUgImJpZyBJIiBJbnRl cm5ldC4gSWYgYSBwcm90b2NvbCBiZWhhdmlvciBjYW4gYmUgbGV2ZXJhZ2VkIGJ5IGEgc3BlY2lm aWMgZG9tYWluLCB3aHkgd291bGQgd2UgbmVlZCB0byBiYW4gaXQgY29tcGxldGVseSBieSBhIGNs YXVzZSBsaWtlIHdoYXQgaXMgY3VycmVudGx5IHByb3Bvc2VkICgiRXh0ZW5zaW9uIGhlYWRlcnMg bXVzdCBuZXZlciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZSBvdGhlciB0aGFuIHRoZSBzb3VyY2Ug b2YgdGhlIHBhY2tldCIgIC0gbGV0IGFsb25nIHdoYXQgdGhlIGRlZmluaXRpb24gb2YgInNvdXJj ZSIgaXMpIC0gd2hpY2ggd291bGQgYXBwbHkgdG8gYW55IHVzZSBvZiB0aGUgcHJvdG9jb2wsIGJl IGl0IGluIHNwZWNpZmljIGRvbWFpbnMgb3IgdGhlIGdsb2JhbCBJbnRlcm5ldC4gSWYgd2Ugc3Rh cnQgdG8gYmFuIGRvbWFpbiBzcGVjaWZpYyBwcm90b2NvbHMgb3IgcHJvdG9jb2wgYXNwZWN0cywg SSB3b25kZXIgd2hhdCBkb21haW4gc3BlY2lmaWMgcHJvdG9jb2wgd2UgYmFuIG5leHQuIA0KDQpD b3VsZCB3ZSByYXRoZXIgY29uc2lkZXIgYWRkaW5nIGEgZGVwbG95bWVudCBndWlkZWxpbmUgdG8g MjQ2MGJpcyBmb3IgdXNlIG9mIEVIIG9uIHRoZSBnbG9iYWwgSW50ZXJuZXQgKHdoZXJlIHRoZSBh Zm9yZSBtZW50aW9uZWQgY29uY2VybnMgYXBwbHkpPw0KDQpUaGFua3MsIEZyYW5rIA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpi cmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDAxLCAy MDE2IDEwOjQ4IFBNDQpUbzogRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNp c2NvLmNvbT47IFNod2V0aGEgQmhhbmRhcmkgKHNod2V0aGFiKSA8c2h3ZXRoYWJAY2lzY28uY29t PjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSRkMyNDYwYmlzIC0gVGlj a2V0ICM5IC0gSGVhZGVyIGluamVjdGlvbiBpc3N1ZQ0KDQpIaSwNCg0KVGhlIHJlYXNvbiBmb3Ig dGhhdCB0ZXh0ICh3aGljaCBJIGFuZCBvdGhlcnMgYXNzZXJ0IGlzIGEgY2xhcmlmY2F0aW9uIG9m IHRoZSBpbnRlbnQgb2YgUkZDIDI0NjAgYW5kIGl0cyBwcmVkZWNlc3NvciBSRkMgMTg4MykgaXMg dG8gbWFrZSBpdCBjbGVhciB0aGF0IHN1Y2ggaW5zZXJ0aW9ucyBhcmUgbm90IE9LLiBUaGUgcmVh c29ucyB0aGF0IHRoZXkgYXJlIG5vdCBPSyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc2V2ZXJh bCB0aW1lcy4gVGhlIGZhY3QgdGhhdCBzdWNoIGluc2VydGlvbnMgYW5kIGRlbGV0aW9ucyBjYW4g YmUgbWFkZSB0byB3b3JrIGluc2lkZSBhIGNsb3NlZCBkb21haW4gZG9lc24ndCBtYWtlIHRoZW0g T0sgZm9yIGdlbmVyYWwgdXNlIG9uIHRoZSBJbnRlcm5ldC4NCg0KUmVnYXJkcw0KICAgQnJpYW4g Q2FycGVudGVyDQoNCk9uIDAyLzA2LzIwMTYgMDQ6MzIsIEZyYW5rIEJyb2NrbmVycyAoZmJyb2Nr bmUpIHdyb3RlOg0KPiArMQ0KPiANCj4gQWdyZWUgdGhhdCB0aGVyZSBhcmUgZWZmb3J0cyAoc2Vn bWVudCByb3V0aW5nIGlzIGFub3RoZXIgb25lKSB3aGljaCBleHBlcmltZW50IHdpdGggaW4tZmxp Z2h0IGluc2VydGlvbi9yZW1vdmFsIG9mIEVILCBhbmQgdGhvc2UgZWZmb3J0cyBoYXZlIHJ1bm5p bmcgY29kZSBhdmFpbGFibGUuDQo+IElNSE8gaXQgIHdvdWxkIGJlIHdheSB0b28gZWFybHkgdG8g ZGVjaWRlIGJhbm5pbmcgdGhhdCBjYXBhYmlsaXR5LiBMZXQncyBrZWVwIHRoZSB0ZXh0IGluIDI0 NjAgYXMgaXMgZm9yIG5vdy4NCj4gDQo+IFJlZ2FyZHMsIEZyYW5rDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU2h3ZXRoYSANCj4gQmhhbmRhcmkgKHNod2V0aGFiKQ0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTYgNjoyNyBQTQ0KPiBUbzogNm1hbiBXRyA8aXB2NkBp ZXRmLm9yZz4NCj4gU3ViamVjdDogUkZDMjQ2MGJpcyAtIFRpY2tldCAjOSAtIEhlYWRlciBpbmpl Y3Rpb24gaXNzdWUNCj4gDQo+IEluIHZpZXcgb2YgdGhlIGxhc3QgY2FsbCBhbmQgdGhlIHRleHQg YWRkZWQgdG8gMjQ2MGJpcyBmb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gb24gdGhlIHRocmVhZCAi QWRkaW5nIGhlYWRlcnMgYW5kIGFkZGluZyBvcHRpb25zIHRvIGhlYWRlcnPCsi4uDQo+IA0KPiBX ZSBoYXZlIGJlZW4gZXhwZXJpbWVudGluZyB3aXRoIEhieUggaGVhZGVyIGluamVjdGlvbiBhbmQg cmVtb3ZhbCBmb3IgdGhlIHB1cnBvc2Ugb2YgY29sbGVjdGluZyBtZWFzdXJlbWVudHMgcmVsYXRp bmcgdG8gcGFja2V0IHRlbGVtZXRyeSBhbmQgd2UgaGF2ZSBhIHdvcmtpbmcgaW1wbGVtZW50YXRp b24gb2YgdGhlIHNhbWUgaW4gVlBQIFtodHRwczovL2dlcnJpdC5mZC5pby9yLyMvYWRtaW4vcHJv amVjdHMvdnBwXSBzb2Z0d2FyZSBkYXRhIHBsYW5lLiBXZSBhcmUgdGVzdGluZyBhbmQgd2lsbCBi ZSBwdWJsaXNoaW5nIHJlc3VsdHMgb2YgdGhpcyBleHBlcmltZW50cyBpbiBkdWUgY291cnNlLg0K PiANCj4gV2hpbGUgSSBhbSBub3QgcHJvcG9zaW5nIHRvIGFkZCB0ZXh0IHRvIGFsbG93IGluc2Vy dGlvbiBhbmQgcmVtb3ZhbCBvZiANCj4gaGVhZGVyIGluIDI0NjBiaXMsIEkgbW9zdCBkZWZpbml0 ZWx5IGRvIG5vdCB3YW50IG5ldyB0ZXh0IC0NCj4gDQo+ICJFeHRlbnNpb24gaGVhZGVycyBtdXN0 IG5ldmVyIGJlIGluc2VydGVkIGJ5IGFueSBub2RlIG90aGVyIHRoYW4gdGhlIHNvdXJjZSBvZiB0 aGUgcGFja2V0LiAgSVAgRW5jYXBzdWxhdGlvbiBtdXN0IGJlIHVzZWQgdG8gbWVldCBhbnkNCj4g cmVxdWlyZW1lbnQgZm9yIGluc2VydGluZyBoZWFkZXJzLCBmb3IgZXhhbXBsZSwgYXMgZGVmaW5l ZCBpbiAgIFtSRkMyNDczDQo+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjQ3Mz5d LsKyDQo+IA0KPiBiYW5uaW5nIGl0IGNvbXBsZXRlbHkuDQo+IA0KPiANCj4gSSBwcm9wb3NlIHRv IGNvbnRpbnVlIGhhdmluZyB0aGUgdGV4dCBvbiBleHRlbnNpb24gaGVhZGVyIHByb2Nlc3Npbmcg DQo+IGZyb20NCj4gMjQ2MCBhcyBpcyB3aXRob3V0IHRoZSBuZXcgYWRkaXRpb24sIGFzIHdlIGRv IG5vdCBoYXZlIGVub3VnaCBldmlkZW5jZS9kYXRhIG9uIHRoaXMgYW1iaWd1aXR5IGxlYWRpbmcg dG8gaW50ZXJvcCBpc3N1ZXMgYW5kIHRoYXQgYmVpbmcgYWxsZXZpYXRlZCBieSBhZGRpdGlvbiBv ZiB0aGUgYWJvdmUgdGV4dC4NCj4gDQo+IFRoYW5rcywNCj4gU2h3ZXRoYQ0KPiANCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2 QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3Jn DQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Thu Jun 2 01:02:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FA712D639 for ; Thu, 2 Jun 2016 01:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ErdJqu506guj for ; Thu, 2 Jun 2016 01:02:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B9A12D175 for ; Thu, 2 Jun 2016 01:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2131; q=dns/txt; s=iport; t=1464854543; x=1466064143; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WgFkMZA2II/939ywRzcjJoSLC5x2oeKjJNy1rinLZFA=; b=Us2pYtyCG0y5oaxiwy6AB9vu6EBcQNdrlk0S1CLj2xNxLcgwKq46vynZ XNpqYhUFMf2RGXmJDRhSvH93eEV6hpYN8dGpSVmgyDq/nW4K06o9iMCXt pWtVKGDEe+Jq5FwH+zOaF98oG55eEyxQrGht3VsITpUm6YQ3CRnc/FbmR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDh5k9X/5ldJa1egzpWfQa6KQENg?= =?us-ascii?q?XkXC4I9gzICgTQ4FAEBAQEBAQFlJ4RFAQEBBAEBAWsXBAIBCBEEAQEoBycLFAk?= =?us-ascii?q?IAgQBEgiHCoEdDsEqAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNgTkBgnaFa?= =?us-ascii?q?gWIBIYZihoBhX+IGY8jj0sBHgEBQoNtbol9fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,405,1459814400"; d="scan'208";a="114409596" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 08:02:22 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5282MI0025398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Jun 2016 08:02:22 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 03:02:21 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 2 Jun 2016 03:02:21 -0500 From: "Pascal Thubert (pthubert)" To: "Shwetha Bhandari (shwethab)" , 6man WG Subject: RE: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvCJqnPiBA7R2OEO3VFjWqJgDtJ/V0D+w Date: Thu, 2 Jun 2016 08:02:01 +0000 Deferred-Delivery: Thu, 2 Jun 2016 08:01:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.49.80.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 08:02:25 -0000 Agreed, At the moment, useful text would indicate what the perceived hazards are, a= nd maybe provide BCP recommendations to ensure, say, traceability. Once we get return from experience from the existing deployments, eg RPL or= segment routing, we may fine tune those recommendations. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha Bhandari > (shwethab) > Sent: mercredi 1 juin 2016 18:27 > To: 6man WG > Subject: RFC2460bis - Ticket #9 - Header injection issue >=20 > In view of the last call and the text added to 2460bis following the disc= ussion on > the thread "Adding headers and adding options to headers=B2.. >=20 > We have been experimenting with HbyH header injection and removal for the > purpose of collecting measurements relating to packet telemetry and we ha= ve a > working implementation of the same in VPP > [https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are > testing and will be publishing results of this experiments in due course. >=20 > While I am not proposing to add text to allow insertion and removal of he= ader in > 2460bis, I most definitely do not want new text - >=20 > "Extension headers must never be inserted by any node other than the sour= ce of > the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in [RFC2473 > ].=B2 >=20 > banning it completely. >=20 >=20 > I propose to continue having the text on extension header processing from > 2460 as is without the new addition, as we do not have enough evidence/da= ta > on this ambiguity leading to interop issues and that being alleviated by = addition > of the above text. >=20 > Thanks, > Shwetha >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jun 2 03:54:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569B212D113 for ; Thu, 2 Jun 2016 03:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ISAoz252Yg4b for ; Thu, 2 Jun 2016 03:54:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5841A12B076 for ; Thu, 2 Jun 2016 03:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4825; q=dns/txt; s=iport; t=1464864883; x=1466074483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2lWnuXntKugnt0qUVJdzbzuJo0C6vKdvV+Ux2jCWlmg=; b=O8smaFh2Hq/fYnne4vq/I6E+ofzw6K60ooU9RXTtvdTKuJ8AGmgftoCe Ci/H9tDnnCFJ/bgrzV2qeFR+QJmGNTfZeFZipKRbh9UpeRszOb4RHGb3B mhVklK4AEwlKtpZn69VZY57XV3y5QK5EszfKqimpu+78sf+mwNfaEXxKH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgAzD1BX/4sNJK1egzpWfa5Ai2+Be?= =?us-ascii?q?RcLgj2DMgKBNDgUAQEBAQEBAWUnhEUBAQEDAQEBAWsLBQcEAgEIEQQBAQEnByE?= =?us-ascii?q?GCxQJCAIEDgWHEoEDAw8IDr0KDYQfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ?= =?us-ascii?q?4F3CIJOgTkBgQmBbRCDLIIuBYgEhhmJZzMBhX+GJ4F5jxyHZIdnAR42ghOBWm4?= =?us-ascii?q?BinsBAQE?= X-IronPort-AV: E=Sophos;i="5.26,405,1459814400"; d="scan'208";a="280824568" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2016 10:54:42 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u52Asgww006229 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2016 10:54:42 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 05:54:41 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Thu, 2 Jun 2016 05:54:41 -0500 From: "Rajiv Asati (rajiva)" To: 6man WG Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvEbc6kctX/SPtUSZkxhYtoSl8Z/VziCggAAzpoU= Date: Thu, 2 Jun 2016 10:54:41 +0000 Message-ID: <85428B51-2057-438A-8D71-507DFCF8474F@cisco.com> References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> , <29e5093f14124a7da8b1d615778db25f@XCH-RCD-008.cisco.com> In-Reply-To: <29e5093f14124a7da8b1d615778db25f@XCH-RCD-008.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 10:54:46 -0000 Having a deployment guideline seems reasonable, given that the protocols g= et used beyond public Internet.=20 Perhaps, makes a distinction between public Internet and closed networks su= ch as govt/classified networks. =20 Cheers, Rajiv=20 > On Jun 2, 2016, at 4:01 AM, Frank Brockners (fbrockne) wrote: >=20 > Hi, >=20 > So far I understood RFC2460 as a protocol spec - not an exclusive deploym= ent guideline for the "big I" Internet. If a protocol behavior can be lever= aged by a specific domain, why would we need to ban it completely by a clau= se like what is currently proposed ("Extension headers must never be insert= ed by any node other than the source of the packet" - let along what the d= efinition of "source" is) - which would apply to any use of the protocol, b= e it in specific domains or the global Internet. If we start to ban domain = specific protocols or protocol aspects, I wonder what domain specific proto= col we ban next.=20 >=20 > Could we rather consider adding a deployment guideline to 2460bis for use= of EH on the global Internet (where the afore mentioned concerns apply)? >=20 > Thanks, Frank=20 >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Wednesday, June 01, 2016 10:48 PM > To: Frank Brockners (fbrockne) ; Shwetha Bhandari (sh= wethab) ; 6man WG > Subject: Re: RFC2460bis - Ticket #9 - Header injection issue >=20 > Hi, >=20 > The reason for that text (which I and others assert is a clarifcation of = the intent of RFC 2460 and its predecessor RFC 1883) is to make it clear th= at such insertions are not OK. The reasons that they are not OK have been d= iscussed here several times. The fact that such insertions and deletions ca= n be made to work inside a closed domain doesn't make them OK for general u= se on the Internet. >=20 > Regards > Brian Carpenter >=20 >> On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote: >> +1 >>=20 >> Agree that there are efforts (segment routing is another one) which expe= riment with in-flight insertion/removal of EH, and those efforts have runni= ng code available. >> IMHO it would be way too early to decide banning that capability. Let's= keep the text in 2460 as is for now. >>=20 >> Regards, Frank >>=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha=20 >> Bhandari (shwethab) >> Sent: Wednesday, June 01, 2016 6:27 PM >> To: 6man WG >> Subject: RFC2460bis - Ticket #9 - Header injection issue >>=20 >> In view of the last call and the text added to 2460bis following the dis= cussion on the thread "Adding headers and adding options to headers=B2.. >>=20 >> We have been experimenting with HbyH header injection and removal for th= e purpose of collecting measurements relating to packet telemetry and we ha= ve a working implementation of the same in VPP [https://gerrit.fd.io/r/#/ad= min/projects/vpp] software data plane. We are testing and will be publishin= g results of this experiments in due course. >>=20 >> While I am not proposing to add text to allow insertion and removal of=20 >> header in 2460bis, I most definitely do not want new text - >>=20 >> "Extension headers must never be inserted by any node other than the sou= rce of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in [RFC2473 >> ].=B2 >>=20 >> banning it completely. >>=20 >>=20 >> I propose to continue having the text on extension header processing=20 >> from >> 2460 as is without the new addition, as we do not have enough evidence/d= ata on this ambiguity leading to interop issues and that being alleviated b= y addition of the above text. >>=20 >> Thanks, >> Shwetha >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jun 2 04:07:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1007A12D69B for ; Thu, 2 Jun 2016 04:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cQ7K-zpQFfyS for ; Thu, 2 Jun 2016 04:06:57 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA9B12B076 for ; Thu, 2 Jun 2016 04:06:55 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id s186so3466340qkc.1 for ; Thu, 02 Jun 2016 04:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=l4UUIqtZdpjRQHHRTydsuxnx3XTx6Dx94w8+zH6PDSk=; b=aP9gdsKTxNtrV47gcBViLq0aTXybaYcw6umHUTgs41skuy7mNHGLTKUjw5Fd45LAZF j58Z+d/dOAaADku0Yp/WQ8qfXUQI/1/2LPfxPcstQyPatw4sod13ypqO+1Evc8eQBUqX C4qPhn39ndoOLzAkGID/fsOX3eU04xgMLPiP6sZcGG5y84FgLBpDyfIWIGOJMczgeEDM JnRP+0XANiPIdOiu6+S0iW0gGuyM6z8YwhmE2zDoo1OFw3d8orh9/vOHvNZIKSvjvhfs xBDt8O6MHT2nMT8aP4P9fSCObS2NHjPmwnzdaEOLV+65JZUyJwfuwbX/kZuxLaC+odqW 9B4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=l4UUIqtZdpjRQHHRTydsuxnx3XTx6Dx94w8+zH6PDSk=; b=RFVwxYD50qnGPDUGZsupkmpkR+QedP8y/oRYwvoxmqRS8u1r+wS5TEnfSMi9fYzxGY scBmUxrkZhUSFV/cZru1YrfJCsV/gKLRs88GPhY8Exw1dj4MCs/Ct4L3EJgy0xRyMRM5 6PsnEms08eH2o0t4JZbuerIIUaNMHQCgRIo66PMtrYi2TvENSYsCogxGOQmBPNDhhoPq /7PFeTgQbnOLr6OuZJCk8TXnZNjpgnhwuIm/O4lzWyze0BbgDGWCfeb3hyOH8uLUNWFC UoYw52P6z6iv5cgKG5TX4BSWtTJ7LsdszVzdXH3tN+QaUcbu2gjwVF1F/IxOzfHSzGVb 0gJg== X-Gm-Message-State: ALyK8tIbv3SDRY5bTNGHgRx6Py5IcZLKltt9QrCp0dpZi86QqjSV5nIERN2Ww2cA6ojs9Q== X-Received: by 10.55.130.1 with SMTP id e1mr43340496qkd.204.1464865595601; Thu, 02 Jun 2016 04:06:35 -0700 (PDT) Received: from rtp-vpn2-21.cisco.com ([173.38.117.79]) by smtp.gmail.com with ESMTPSA id 52sm10905845qgz.46.2016.06.02.04.06.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 04:06:34 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D9EE464E-DBBD-402A-A484-480C9659D323"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Ralph Droms In-Reply-To: Date: Thu, 2 Jun 2016 07:06:33 -0400 Message-Id: <3D4DC932-16B6-4DC4-912F-41D3551D2311@gmail.com> References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 11:06:59 -0000 --Apple-Mail=_D9EE464E-DBBD-402A-A484-480C9659D323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 1, 2016, at 4:47 PM 6/1/16, Brian E Carpenter = wrote: >=20 > Hi, >=20 > The reason for that text (which I and others assert is a clarifcation > of the intent of RFC 2460 and its predecessor RFC 1883) is to make > it clear that such insertions are not OK. The reasons that they are > not OK have been discussed here several times. The fact that such > insertions and deletions can be made to work inside a closed domain > doesn't make them OK for general use on the Internet. The IETF has strenuously (and, from personal experience, painfully) = argued with other SDOs against similar extensions to IETF protocols to = be used only inside a loser domain. For example, look at = Q.flowstatesig, which specified headers to be inserted into a TCP stream = in an ingress router for a "bounded sub-network of an NGN" and deleted = at the corresponding egress router. The IETF took the position that = such sub-domains cannot be enforced and leakage of the modified TCP = stream would cause protocol breakage in hosts. - Ralph >=20 > Regards > Brian Carpenter >=20 > On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote: >> +1 >>=20 >> Agree that there are efforts (segment routing is another one) which = experiment with in-flight insertion/removal of EH, and those efforts = have running code available. >> IMHO it would be way too early to decide banning that capability. = Let's keep the text in 2460 as is for now. >>=20 >> Regards, Frank >>=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha = Bhandari (shwethab) >> Sent: Wednesday, June 01, 2016 6:27 PM >> To: 6man WG >> Subject: RFC2460bis - Ticket #9 - Header injection issue >>=20 >> In view of the last call and the text added to 2460bis following the = discussion on the thread "Adding headers and adding options to = headers=C2=B2.. >>=20 >> We have been experimenting with HbyH header injection and removal for = the purpose of collecting measurements relating to packet telemetry and = we have a working implementation of the same in VPP = [https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We = are testing and will be publishing results of this experiments in due = course. >>=20 >> While I am not proposing to add text to allow insertion and removal = of header in 2460bis, I most definitely do not want new text - >>=20 >> "Extension headers must never be inserted by any node other than the = source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in = [RFC2473 >> ].=C2=B2 >>=20 >> banning it completely. >>=20 >>=20 >> I propose to continue having the text on extension header processing = from >> 2460 as is without the new addition, as we do not have enough = evidence/data on this ambiguity leading to interop issues and that being = alleviated by addition of the above text. >>=20 >> Thanks, >> Shwetha >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_D9EE464E-DBBD-402A-A484-480C9659D323 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 - http://gpgtools.org iQIcBAEBCAAGBQJXUBM6AAoJEINeeBNmFjV5dAAQAIx1qbTk4u0uHGK+B29wH/8T JgniTBLjW46FKNzfhdefux1pWXWdf3Vpk6pPUx0Uu6cwVtvadBq0847QitHSrDv8 XPn+2PRfNfFaGADKvKRfsLn8/aJiOw17jQP+UuL7+xlBBCsMJE2CvjYOG0oIcz/c JD714qMgI5DBzIaKMALxyc+Cr35s+Q6OKud0UYz1YM0b/Y/CCo7ful5vLU5eF2Ae +9Jvcu3sz0jlweoZjRoCEbNCBDT456cFHDjfjuhPbBFyJhHYqWhUTrFuoCWd+aHY hwxsAiwEgEmIwvzjmlTgMNpo1lVgdKxuYd+yB+GB6SrZG24RCfcASha8lr9THkZ1 GQNB1fVOIgLL9ZsxTSPX20kUYg92fwNqkGwEASAio0rAuj6VPoSLbxQqQ9XB/rwt gMeZYtrUl8lc3KghqSyFH8gskWXDZKr4FYWgSy2tvxZ/EgitI99Lam402R6+zo0S KgXGHe9GDeLQAKoxw5x3Fg38ZE0SET4UG6GcS4yM4fcqndnir0Euix3VdcZD2HPu bcgUsT2f33PoYB59akAV6lFFCSqgCUAV8oh6y04PkKMatkRjUPGlf7yLCN/tTu9O /24+XQR8u3qfWt+EpSHQWGYJT7lhbuD2Zx/OF64wSxlSAE/9MwOnbKqjKjcMZNAM B8iVqESdeIqOnW3ecpwB =eijk -----END PGP SIGNATURE----- --Apple-Mail=_D9EE464E-DBBD-402A-A484-480C9659D323-- From nobody Thu Jun 2 13:41:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F0F12D1DE for ; Thu, 2 Jun 2016 13:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pPceGn77DSXS for ; Thu, 2 Jun 2016 13:41:26 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E64512B01C for ; Thu, 2 Jun 2016 13:41:26 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id f144so35278633pfa.3 for ; Thu, 02 Jun 2016 13:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GpmFesl9hd7lkjjC6fGUBY6q46VNAjeTXnG0IDONqM0=; b=OzLnlnd/ZDNEiRjfOwjT5ADCqip5dghccLnz46zlv2EcLVTolfBoDAjHQLKiCgDQyN FPrRAX/wI3t2vuUS4oRaVBfKhRaUVc3MfnXjfrN/OXkwfGTEFZKgtYroE5GcYBVK+cAD kbWr2hzgZ7O0aP65UFKftivGpZrwovZ5S1Sr7PSOwRqfWS02oWpAzIJ+8KbDfepX4Tpa +9cerjVIqqoTU3zwm6OV6NTMcY5TQ4/d4thSCdp0/4BB8DJ7y5Bhq8XrKLa+sYgFeTQY BUROGfqmjmgcXOLTLuYuEqw/Kp7Sen8OoQlDtvHGmzE7paPRCRn+29dfbZbwJIcUfWRM xX8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GpmFesl9hd7lkjjC6fGUBY6q46VNAjeTXnG0IDONqM0=; b=DDpCBPlekIYcB0gPAxuPWQc3UmRDtJVquaNuKEcq5m5d18tSPAc8fbX0A0KFaa8BBy 0b+MA/jk1QqqtXh5/R7siBgaAxZyllQLoiFops5PgSkRUYcpG1fRX2F2cRQjhmNo24ap hyf9egF7EibqkLxopIQN5uM+m5G2b0yeuFTW6d0P/uNEPUneUxW1DkEP+/DDZV8kHmHq QFCmnEzZlMRP/1i8owdl30AQ31sDPCuV6HRxe8czBMlEgizyqPMMaie9LksnFH6KQk7K 9/Ah/c5PlJeJKENUQDTW/WZPppYnUwKUinoSf+SA0Xuj4hRMkanvIz7+Ctq59T9rfbGb fAoQ== X-Gm-Message-State: ALyK8tInW5O+SB1n1FvbRhz9TnFx0BpFDFkhvXnjRx585GNWmy7ogcg+7Zx9LTY9txdC6Q== X-Received: by 10.98.192.17 with SMTP id x17mr236392pff.78.1464900085472; Thu, 02 Jun 2016 13:41:25 -0700 (PDT) Received: from ?IPv6:2406:e007:49cd:1:4030:d762:56e:7b19? ([2406:e007:49cd:1:4030:d762:56e:7b19]) by smtp.gmail.com with ESMTPSA id 4sm2911382pfm.15.2016.06.02.13.41.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 13:41:24 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Rajiv Asati (rajiva)" , 6man WG References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> <29e5093f14124a7da8b1d615778db25f@XCH-RCD-008.cisco.com> <85428B51-2057-438A-8D71-507DFCF8474F@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8536a9ee-fdb1-151c-436d-f3085d4bb7d6@gmail.com> Date: Fri, 3 Jun 2016 08:41:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <85428B51-2057-438A-8D71-507DFCF8474F@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:41:28 -0000 The primary job of the IETF is to "make the Internet work better" (RFC393= 5). In that context, I think that our *primary* standard for the future (RFC2= 460bis) must provide global interoperability across any random path on the Internet as an absolute requirement. We can't stop people deploying non-interoperable variations within closed= domains, but see Ralph's message. Regards Brian On 02/06/2016 22:54, Rajiv Asati (rajiva) wrote: > Having a deployment guideline seems reasonable, given that the protoco= ls get used beyond public Internet.=20 >=20 > Perhaps, makes a distinction between public Internet and closed network= s such as govt/classified networks. =20 >=20 >=20 > Cheers, > Rajiv=20 >=20 >=20 >=20 >> On Jun 2, 2016, at 4:01 AM, Frank Brockners (fbrockne) wrote: >> >> Hi, >> >> So far I understood RFC2460 as a protocol spec - not an exclusive depl= oyment guideline for the "big I" Internet. If a protocol behavior can be = leveraged by a specific domain, why would we need to ban it completely by= a clause like what is currently proposed ("Extension headers must never = be inserted by any node other than the source of the packet" - let along= what the definition of "source" is) - which would apply to any use of th= e protocol, be it in specific domains or the global Internet. If we start= to ban domain specific protocols or protocol aspects, I wonder what doma= in specific protocol we ban next.=20 >> >> Could we rather consider adding a deployment guideline to 2460bis for = use of EH on the global Internet (where the afore mentioned concerns appl= y)? >> >> Thanks, Frank=20 >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 >> Sent: Wednesday, June 01, 2016 10:48 PM >> To: Frank Brockners (fbrockne) ; Shwetha Bhandari = (shwethab) ; 6man WG >> Subject: Re: RFC2460bis - Ticket #9 - Header injection issue >> >> Hi, >> >> The reason for that text (which I and others assert is a clarifcation = of the intent of RFC 2460 and its predecessor RFC 1883) is to make it cle= ar that such insertions are not OK. The reasons that they are not OK have= been discussed here several times. The fact that such insertions and del= etions can be made to work inside a closed domain doesn't make them OK fo= r general use on the Internet. >> >> Regards >> Brian Carpenter >> >>> On 02/06/2016 04:32, Frank Brockners (fbrockne) wrote: >>> +1 >>> >>> Agree that there are efforts (segment routing is another one) which e= xperiment with in-flight insertion/removal of EH, and those efforts have = running code available. >>> IMHO it would be way too early to decide banning that capability. Le= t's keep the text in 2460 as is for now. >>> >>> Regards, Frank >>> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Shwetha=20 >>> Bhandari (shwethab) >>> Sent: Wednesday, June 01, 2016 6:27 PM >>> To: 6man WG >>> Subject: RFC2460bis - Ticket #9 - Header injection issue >>> >>> In view of the last call and the text added to 2460bis following the = discussion on the thread "Adding headers and adding options to headers=C2= =B2.. >>> >>> We have been experimenting with HbyH header injection and removal for= the purpose of collecting measurements relating to packet telemetry and = we have a working implementation of the same in VPP [https://gerrit.fd.io= /r/#/admin/projects/vpp] software data plane. We are testing and will be = publishing results of this experiments in due course. >>> >>> While I am not proposing to add text to allow insertion and removal o= f=20 >>> header in 2460bis, I most definitely do not want new text - >>> >>> "Extension headers must never be inserted by any node other than the = source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in [RFC2= 473 >>> ].=C2=B2 >>> >>> banning it completely. >>> >>> >>> I propose to continue having the text on extension header processing = >>> from >>> 2460 as is without the new addition, as we do not have enough evidenc= e/data on this ambiguity leading to interop issues and that being allevia= ted by addition of the above text. >>> >>> Thanks, >>> Shwetha >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > . >=20 From nobody Fri Jun 3 00:20:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82BF12D16D for ; Fri, 3 Jun 2016 00:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 uH9W57TG4uQd for ; Fri, 3 Jun 2016 00:20:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7AC12D148 for ; Fri, 3 Jun 2016 00:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1670; q=dns/txt; s=iport; t=1464938406; x=1466148006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jo8Hz1QXTjYAtzSvpSRCRVLN7+1QHVIJOkRSJljAoAg=; b=VQSD2vHBorjFAc2KWLxkAv2HdwVSweurfBHUdZODLIll7oBn9D4wf9Qc L+paJt3I0UWiXD4ZWjAvs2gnPH5X+Lbxd4u6FtfMuU64Rm4tKijY6S8Mh w81gfXPDAJTOgbkbgaWuUQMzu6jnynvFWR3GlU2ivcc35mPwZCL+omp8z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDCLlFX/5xdJa1egzpWbg8GulCBe?= =?us-ascii?q?RcLgj2DMwKBLzgUAQEBAQEBAWUnhEUBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgW?= =?us-ascii?q?HEoEVCA7CZgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieBd4JWgTkBgnYQgyyCL?= =?us-ascii?q?gWIBYYZhRqFDQGGAoghjxyPUQEeNoIUgVpuiRN/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,411,1459814400"; d="scan'208";a="109330774" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2016 07:20:05 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u537K5oj018484 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Jun 2016 07:20:05 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 3 Jun 2016 03:20:04 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Fri, 3 Jun 2016 03:20:04 -0400 From: "Stefano Previdi (sprevidi)" To: "Shwetha Bhandari (shwethab)" Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRvWhZnPiBA7R2OEO3VFjWqJgDtA== Date: Fri, 3 Jun 2016 07:20:04 +0000 Message-ID: <8B561A41-F82C-4AE4-865E-17E92D1EACB1@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.78.24] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71ADB59E254E674287A4F4ACD2C538BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:20:09 -0000 I fully agree. s. > On Jun 1, 2016, at 6:26 PM, Shwetha Bhandari (shwethab) wrote: >=20 > In view of the last call and the text added to 2460bis following the > discussion on the thread "Adding headers and adding options to headers=B2= .. >=20 > We have been experimenting with HbyH header injection and removal for the > purpose of collecting measurements relating to packet telemetry and we > have a working implementation of the same in VPP > [https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are > testing and will be publishing results of this experiments in due course. >=20 > While I am not proposing to add text to allow insertion and removal of > header in 2460bis, I most definitely do not want new text - >=20 > "Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in [RFC2473 > ].=B2 >=20 > banning it completely. >=20 >=20 > I propose to continue having the text on extension header processing from > 2460 as is without the new addition, as we do not have enough > evidence/data on this ambiguity leading to interop issues and that being > alleviated by addition of the above text. >=20 > Thanks, > Shwetha=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 3 02:09:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3400712D60F for ; Fri, 3 Jun 2016 02:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 UkK2jBP7aFSQ for ; Fri, 3 Jun 2016 02:09:19 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4223A12D621 for ; Fri, 3 Jun 2016 02:09:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u5399GXq017892 for ; Fri, 3 Jun 2016 11:09:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4E0C42068B0 for ; Fri, 3 Jun 2016 11:09:40 +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 452D5206866 for ; Fri, 3 Jun 2016 11:09:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u5399GAa004633 for ; Fri, 3 Jun 2016 11:09:16 +0200 Subject: Re: possibility of a MAC randomization algorithm (was: Discussion of default-iids and MAC address randomization and RFC4941) To: ipv6@ietf.org References: <5704F1C8.8010508@gont.com.ar> From: Alexandre Petrescu Message-ID: <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> Date: Fri, 3 Jun 2016 11:09:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 09:09:22 -0000 Hi, About the possibility of a MAC randomization algorithm, regardless of being used in an IP address: > we do not control whether MAC addr randomization algorithm is > appropriate or if it is actually possible. The algorithm output should be checked against the authoritative oui.txt, and not generate an existing OUI (organizationally unique id). Is such an algorithm documented somewhere? Alex > is appropriate or if it is actually possible. Not true - or rather, > it's mostly not true. The exact level of incorrectness depends on who > "we" is. If "we" = "Apple", then that statement is completely false. > If "we" = "Windows" or "we" = "Android" then it is only mostly false. > If "we" = "Linux" it is almost certainly false unless the host is > using binary-only drivers. * Wastes 18 bits of entropy: "wastes" how? > What's the downside? * Interoperability problems: depends heavily on > the link layer. It's not true that you can't recover from DAD > failures using SLAAC, you can just pick another number and try > again. > > Of course, there's nothing new in my position, just like there's > nothing new in yours. I'd just like to make sure that nobody can > later state that the people who objected to the document are no > longer objecting :-) > > Cheers, Lorenzo > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 3 11:55:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF412D890 for ; Fri, 3 Jun 2016 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 UJgx9swt3wtQ for ; Fri, 3 Jun 2016 11:55:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858F912D90E for ; Fri, 3 Jun 2016 11:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Vnob/OIIp6pEbwwbFsTNEI4xJtQA8eNnKHhtWvlWVg=; b=l7KOAWXkgGdZYDj+yycs2SoHvZRmoNfDf6lZ6zUXlLhx5t//2CyQz3QwPeoUSWptNcrIWKIFO8DbOtl48JY5N3ZzGpO1onEbd/bTdxpD8u0eKxO+su+CMsVjvGvPfYM1zi3K96QHNj5e+TlY+5n+iYyKomvFh3fwDPpNtqWg+U8= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 3 Jun 2016 18:55:34 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0501.017; Fri, 3 Jun 2016 18:55:33 +0000 From: Christian Huitema To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: possibility of a MAC randomization algorithm (was: Discussion of default-iids and MAC address randomization and RFC4941) Thread-Topic: possibility of a MAC randomization algorithm (was: Discussion of default-iids and MAC address randomization and RFC4941) Thread-Index: AQHRvXem9TD1ACzATU23KqWPln5N9Z/YFqxw Date: Fri, 3 Jun 2016 18:55:33 +0000 Message-ID: References: <5704F1C8.8010508@gont.com.ar> <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> In-Reply-To: <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::559] x-ms-office365-filtering-correlation-id: b2f9484d-e093-437b-a6a5-08d38be0a467 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:EQa7ZdV2sQzyyvya31IBSF3QqbV3yzbUf0d+SaDjFX6HVsqwwezym1dQyd8KB2dT0O5P6Oy+I2V8forIAgddVVWuHSBRnX1mvo0Ca9Oc5rC+LQM79ffI9PPYm+p/QOcdP6xgZzTOoYVuI3qNtEOCxQ==; 24:6Am4zpihmECMH6IHBLHljnfycaT3inWEc9KsV+x9Mk0kaVhXdA2deihnQtoIwNEhw0N9Ff2AGQimmB1y691ZZpAF7qPLKC0XgqNqrp7lbaw=; 7:L0AeMGNp+lks40kYOrKc0ewqFfoHIOQ8Nu+Sszj0siMc4J0NsJbg0HH3vq84mnob8tj2D+UdFclav1+iTxty5IWopQyTmRL5pZCuYdTDO09+xsxGPSwUd/NrmA7SbMwAv0/IGp7kYJw00Uuyor7uQp+dWcK+DSqX3vr5ZF16xd6Hk5wIgh5uPNemCl7dcojzRPRAQyngVjgHdhkRgdu1kIGvy8bA4NXvDzGESAV5MNByzIIp9bOF9kpcf6DV+Q+A x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(5003600100002)(10090500001)(5008740100001)(54356999)(33656002)(106116001)(86362001)(6116002)(50986999)(99286002)(2900100001)(2950100001)(76176999)(2906002)(5004730100002)(2501003)(77096005)(15975445007)(19580395003)(92566002)(8936002)(87936001)(5005710100001)(5002640100001)(8676002)(76576001)(122556002)(107886002)(10400500002)(10290500002)(586003)(3660700001)(102836003)(3280700002)(74316001)(5001770100001)(189998001)(81166006)(9686002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 18:55:33.5313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:55:43 -0000 On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote: >=20 > About the possibility of a MAC randomization algorithm, regardless of bei= ng > used in an IP address: >=20 > > we do not control whether MAC addr randomization algorithm is > > appropriate or if it is actually possible. It is certainly possible, since it is shipping in Windows 10. > The algorithm output should be checked against the authoritative oui.txt,= and > not generate an existing OUI (organizationally unique id). There is a potential debate about that. What we are doing in Windows 10 is = set the "local" bit to true, which means that the OUI does not apply. > Is such an algorithm documented somewhere? Mathy Vanhoef, PhD Student Computer Security at KU Leuven, wrote a nice blo= g containing such a description: http://www.mathyvanhoef.com/2016/03/how-ma= c-address-randomization-works-on.html -- Christian Huitema From nobody Fri Jun 3 17:59:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2429812D19F for ; Fri, 3 Jun 2016 17:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c9O1A6nDQCvK for ; Fri, 3 Jun 2016 17:58:59 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B35612D544 for ; Fri, 3 Jun 2016 17:58:59 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id xk1so18678126pac.2 for ; Fri, 03 Jun 2016 17:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=b9vsLjRtad1zKS8K58aN7Nd1zycv0FH7I66+OUJEy+0=; b=bYiSFJBVt6Atvf+ngA3xAd6bpwvC7qpPaecFd6ZN6MrCOaYa4voDZPY5EgtH0HkUnO eZmHGHgq34xtlGX2sHV5H4EJGkjAoQGAxW8jg8jWdNLy+jgd39WjoP1OjkZnv6SjZVmh 6eIENhiQHeojwzE9AT0AQrT+SFofyJVB+SoskQLnEqt5ZdiFQhTPuhAZsYbOkzX3dvHy sYJcLp+UQlyHRnUEJsNTnqm8g7mKCqsVO5i61Y8i/vYxrTN7eaRdDd9VsJz05fzlKYNc RMPFRz/o9y8/y0dDXuYHwcwDJfE+cC0IYe7N0NjVzjHdcPdMALgElhHqAp+LfvZEU4US nODw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=b9vsLjRtad1zKS8K58aN7Nd1zycv0FH7I66+OUJEy+0=; b=Y4YSGDQkYxA3jiVPUhsPyZl5vcX+ZUrZmFPlDK0um+ME6Fp2R0KtEnfpGCFi0AdtW2 R0+7fdHOUXasqqmSb1sfh4kZYwwDS7sfwv56mKXKTgR8amS5TsF0wJ35DN0VnSXwT6qk YbFGPEbOc+2yoKw1dAxySK3Bl2Je/wd6F3Ji727YkCRD7/g29mzMZ+5iX7lKjtspZV0O i1VLN8ca7ojuGMlkg5PuHld0ixYsXZfjVEWGxGXKY03IQ2v1o8KFqHdVtVNqH/cBXLff /7Wz8Ml4pF5rsDN45+I0HO90V+0DfV6KtnYwGHMq32092N+wTHLvKgmqH24fgRw2Jz1Y bKCg== X-Gm-Message-State: ALyK8tIKcGW4ANbeCaOYC2v78fdX1KKnj1WtKCYefW0jM9yiiStatm3OUy2GvT9rNWGOAg== X-Received: by 10.66.166.176 with SMTP id zh16mr8400195pab.42.1465001939005; Fri, 03 Jun 2016 17:58:59 -0700 (PDT) Received: from ?IPv6:2406:e007:5197:1:180b:69ab:fb21:1707? ([2406:e007:5197:1:180b:69ab:fb21:1707]) by smtp.gmail.com with ESMTPSA id t65sm11015496pfb.37.2016.06.03.17.58.57 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 17:58:58 -0700 (PDT) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> To: 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 4 Jun 2016 12:59:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 00:59:01 -0000 FYI, I've just decided to end my experiment in running my laptop without a stable IPv6 address, which I started on May 19th. The only very minor issue that I noted with my regular workload is that occasionally the gmail SMTP server asks me for my password again. However, I did have to spend an hour or so making my prototype of the Anima WG GRASP protocol robust against unplanned address changes, especially its discovery mechanism. So the caveat is obvious: there is certainly software around that has not been made renumbering-proof. But if something is already roaming-proof, it most likely doesn't care about stable addresses. (The only tricky part was that on Windows, the stable address keeps reappearing every few minutes automatically, so rather than dig around looking for a way to stop that, I've been running a script that deletes it every time it appears...) Regards, Brian On 26/05/2016 16:54, Brian E Carpenter wrote: > On 26/05/2016 16:45, Lorenzo Colitti wrote: >> On Tue, May 24, 2016 at 7:38 AM, Fernando Gont >> wrote: >> >>>> P.S. My personal experiment in running my laptop for several days >>>> with no stable address has been completely successful. Including the >>>> fact that my prototype of the Anima signaling protocol crashed after >>>> a while, because the address it was relying on went away, which is of >>>> course the expected behaviour. >>> >>> So, the question is: can this be considered "acceptable" behavior? >>> >> >> Yes, because IPv6 address can expire and be replaced at any time in a >> renumbering event. > > Need I add that we will be putting some words about address stability or > its absence into the appropriate Anima documents. Obviously, we want the > autonomic networking infrastructure to be both stable and self-repairing. > But then I think we'd like all applications to have those properties. > > Brian > From nobody Sat Jun 4 21:37:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDC12D123 for ; Sat, 4 Jun 2016 21:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P7jqs3hAZ9m4 for ; Sat, 4 Jun 2016 21:37:16 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C675412B033 for ; Sat, 4 Jun 2016 21:37:15 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id ec8so19670532pac.0 for ; Sat, 04 Jun 2016 21:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=WE5JMhYlWFJEws1SRpcwfRfJxc6bGVAa8nT4ug5UPcQ=; b=BsKcPljHNo4NayQox5O6emz5rHf6EXup67ivBBvPUgz/bk2zK1s9HB6ON+MWDx2ZPx 3QBqfqeB8U0W7LXMmSSal0RpBHs3Rf93ujHX/Ho+vlaOqMl8vrkt8nIMwYICHerJckBK 1SzUvo6h8DAf8EkIi43Gow+k01YN9ulylL9qfJXliB0IFWiJI/AkkzoY/OjQMCoSt1pd S6zKt7N5BINabnNG7qYgdr/72hhEl6AcVyu5gBc71zlpxIy5oLTjwLL3lN77r/GwVsd8 G3bUBZRBMu/GgKagcvdouR455DZ4UDDMp6kVkrvULDTS3rrwfWUE4zJvP866kuhQPYb2 HYMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=WE5JMhYlWFJEws1SRpcwfRfJxc6bGVAa8nT4ug5UPcQ=; b=D6OuZcm92e9v/2EIaxxYgCw6eVQyi8+y/54D/9hu9MqOi0kTXivqJ1fk4+h53wQV7x K1IqUfo7w1MrCkRwhVF/X7tOHKFxRqiGqjmS9EUprLwOTrdSE2+40e46oDbJH1kMYmfN tmx4zt4x/3FTvwlHUmMn9Ato3ctD92kmVKDLD+1xQAeWTz53av2XlfJmxR5K5WIaGBlq J10DXj27MKedZSU1TC/zUDp7i6hy8R4eyl+Xzi0dWCG8rLQGcf7jYusb2KNbU+0WP3Kc it7YPPcKEmZx99JCTtlq3eS7u1OJb5lKmbnOo6zkDIlX4ZG/Re0Wbx15JSY5+dhxNqzD uzAg== X-Gm-Message-State: ALyK8tJIKNezDf8QLUMyk5I2RD6iCWk/GFUd94d1NEAilhU4OI9MFoG5i3b9i0dFeUg0bA== X-Received: by 10.66.2.168 with SMTP id 8mr15976507pav.152.1465101435339; Sat, 04 Jun 2016 21:37:15 -0700 (PDT) Received: from [192.168.178.22] ([118.148.64.37]) by smtp.gmail.com with ESMTPSA id v1sm18262024pfa.93.2016.06.04.21.37.13 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 21:37:14 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: 6man Subject: Testing ULAness Message-ID: Date: Sun, 5 Jun 2016 16:37:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 04:37:18 -0000 Hi, The IANA IPv6 Special-Purpose Address Registry* has a column marked "Global". For fc00::/7 (ULA) this is set to "False". That is surely wrong. ULAs are explicitly defined as having global scope. This has consequences. For example, in the Python ipaddress module, the property .is_global returns False on a ULA. The test for ULAness turns out to be (x.is_private and not x.is_link_local). *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml Regards Brian From nobody Sat Jun 4 21:42:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4993412B02D for ; Sat, 4 Jun 2016 21:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 74aTnPo7zRKb for ; Sat, 4 Jun 2016 21:42:46 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE72012B024 for ; Sat, 4 Jun 2016 21:42:46 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h19so114579984ywc.0 for ; Sat, 04 Jun 2016 21:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Uc3MYfC2PwK6sTntlpFL5B4A9u9s17kAxTSDUCju3vQ=; b=CR0nem/Y+TfMsVO+AmfLNfy1FjYNZDyGQXfE9o95n+Vd2w1MBLyqihDmui/yA1euBN 3eAPNjO1WO5vfWdxyh6cWlLtYWTQMnmhMRY7G+jIVPB+2GGMVJTufvkSXbuf200UZc+7 cDjtDlQTb+3Lh5eqIHCSI7xyRydJD+eGC4dDiBT7Hyv52SAbmH+FFWrgkMeQVugMmq2O nuTki2A55oKbgCL7U9GEDpz+OinH2DCsU09XzDFr6e6uaZCHWX6tdX6PdPlOpDK8FcJ5 NknMO2IXi97HB8epxmUACwozFxXioWVQVs33WDsFuHz5JlUZS8jxD2WC4W54JCvFGCyJ 51EA== 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:date :message-id:subject:from:to:cc; bh=Uc3MYfC2PwK6sTntlpFL5B4A9u9s17kAxTSDUCju3vQ=; b=FyNsu6gjb2duOmSMMJLFtqbaN+yJ+fmnLH/X1MNp35iiUVyP458z8A6wv9arkB9zBT 9aN2xvk3DHfgCv76YVXKMb4iliXUrBYjYbJKMpWLIYyPPHas3BxQfF+9UwXDBu9u0mwB o3Hgcu2qraSeGZJbI4GDdXUnHXYAnpcYaP3KfP9FjMXKdcVJimsH8JIGu2YuLlmH+HAd qfvPOvxS8SjJ6r5ttaaedYVVxtQG8Cup/20umujClwK9fD8h8nV4koksQA2UQG8a+wbT aBh4Th8FHkaUfJJIKxMl13QGkzcgkSsRs62qOES7DSIo+yzFv0SasrFXmEaSkDdssbt8 w/tw== X-Gm-Message-State: ALyK8tJj/hFVlmFLZjAobY8Jq+Y+llKA8RMCicGmW+HUnwBZmoHhvrWmcvGcja01x7jszUQLx2kHU2sjaM5zv3SW MIME-Version: 1.0 X-Received: by 10.129.82.214 with SMTP id g205mr8088187ywb.66.1465101765874; Sat, 04 Jun 2016 21:42:45 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Sat, 4 Jun 2016 21:42:45 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Sat, 4 Jun 2016 21:42:45 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Jun 2016 13:42:45 +0900 Message-ID: Subject: Re: Testing ULAness From: Lorenzo Colitti To: "Brian E. Carpenter" Content-Type: multipart/alternative; boundary=001a114dc6945117d605348096cf Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 04:42:48 -0000 --001a114dc6945117d605348096cf Content-Type: text/plain; charset=UTF-8 On 5 Jun 2016 1:37 pm, "Brian E Carpenter" wrote: > The IANA IPv6 Special-Purpose Address Registry* has a column marked "Global". > For fc00::/7 (ULA) this is set to "False". > > That is surely wrong. Is it? ===== o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain. ===== Doesn't seem that obvious to me that ULAs are forwardable on the internet. --001a114dc6945117d605348096cf Content-Type: text/html; charset=UTF-8

On 5 Jun 2016 1:37 pm, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> The IANA IPv6 Special-Purpose Address Registry* has a column marked "Global".
> For fc00::/7 (ULA) this is set to "False".
>
> That is surely wrong.

Is it?

=====
o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain.
=====

Doesn't seem that obvious to me that ULAs are forwardable on the internet.

--001a114dc6945117d605348096cf-- From nobody Sat Jun 4 22:14:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2985A12B051 for ; Sat, 4 Jun 2016 22:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bfuDVeoRLf-t for ; Sat, 4 Jun 2016 22:14:29 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C00127058 for ; Sat, 4 Jun 2016 22:06:30 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id b73so76337704lfb.3 for ; Sat, 04 Jun 2016 22:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hwc3vudbHDpCLclc9Zi9F6EIr8wd7yTFzYfoQuVCKFA=; b=cG4pcRueWrucxzFZ5KM4vpr5TJgwTIGZ75tS76wWzaXSdx0wF0GJfwd4tyPTAaHixs qwfY1U4sHpS6SX5Xh/PXetIxLGOYJ31L9psdqWc4z+SMFpHxCYCDKKmvRfjoRuQy3PZ4 2uuMaFN9+7tIvUI9oEbx+VW+nBNdeObbyo21knkFqwTqXOddjXY5bF1YO9apuhbJp3tD dXvygTRMDC/B5omErB1V4Kz18BA1aq2PBb0kEUcUkyDoOJskH6SLUQ247Qv/HzoDLt/k WvEDyPUVld4JjFEWqrB/nTl7k/x3o9H3PDdiGd/RNSwTNgPdz5hCWrdGk7kkhkRn5S1G wLMA== 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; bh=hwc3vudbHDpCLclc9Zi9F6EIr8wd7yTFzYfoQuVCKFA=; b=ZnOcRudvK6xJPVW6QRYFeSM3gXyhGhYnnTlKqWV0fi+27X/pEqTHhbyy+Nf65hGQt7 NR6FXZCw3HSH9sDPalIcHBin4x/zjK/VhLj24s+J/MRisJ2t3E4ZWZDpROaILmULGUeH +t/bTM21qsfVK45mg4Vkkz2sPfUrLFAnIjdt7qlZ/7TNPYIozJLiozMoYzD/NHUFY6o3 j2KWFbkDBnNYKzRLPemegN/IeXqIq575Id6kIBq4aby1qkBiJhAF5gutGilLBp0V5IP5 NDqYi2r6NRaHKsueP2EtjHGoNxFU1Zoicc2EgtvOOXAlI1y79R6x+vkbzGIIEGQUarIG G+bw== X-Gm-Message-State: ALyK8tLxTy2cDk1q6KUzkTtqL+ypnimLVmzi/+QszzWEusnht/YEG2cn46glJB1N3x51PyOAHdlWbQ0DXTsG8A== X-Received: by 10.25.146.66 with SMTP id u63mr2403789lfd.42.1465103188837; Sat, 04 Jun 2016 22:06:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.232 with HTTP; Sat, 4 Jun 2016 22:06:28 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sun, 5 Jun 2016 07:06:28 +0200 Message-ID: Subject: Re: Testing ULAness To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:14:31 -0000 On Sun, Jun 5, 2016 at 6:42 AM, Lorenzo Colitti wrote: > On 5 Jun 2016 1:37 pm, "Brian E Carpenter" > wrote: >> The IANA IPv6 Special-Purpose Address Registry* has a column marked >> "Global". >> For fc00::/7 (ULA) this is set to "False". >> >> That is surely wrong. > > Is it? > > ===== > o Global - A boolean value indicating whether an IP datagram whose > destination address is drawn from the allocated special-purpose address > block is forwardable beyond a specified administrative domain. > ===== > > Doesn't seem that obvious to me that ULAs are forwardable on the internet. Global got nothing todo with being forwardable or not. It is more about if the prefix is unique or not. This remind me of a discussion with some years ago... ULA-C, ULA-G etc, one result of all that was https://www.sixxs.net/tools/grh/ula/ And about Brian's question, ULA-G/ULA-C was an attempt to make them more true global than ULA, so not sure if the global set to false is wrong. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Sat Jun 4 22:34:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B723112D5C6 for ; Sat, 4 Jun 2016 22:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Q3YghCfjBJKc for ; Sat, 4 Jun 2016 22:34:28 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D829012D5B9 for ; Sat, 4 Jun 2016 22:34:28 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id bz2so25736265pad.1 for ; Sat, 04 Jun 2016 22:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PHM+26UznxtCrEcOMBBFaG2mOTIhJbFNgTBmBbELRHI=; b=r0fczXuQtKQjvSHSd13FaFtaazvUZ6uj/RhShvWLuK26VcYZ7vheF2QFqTtQOHmh+0 vW5gTmmv7gyKfQW2Yt45DU2GNLGwkNSVf/KQDx4jwQ7LqUEKYWRdqlfPm/Z961nHFHdS R6vR38aDKMF0A6DOij4d7wm2SrZqQSKpt0C9OY5dORl++n98idrpqVRHW+2Ffxgl6IC0 ygnXrG45ryQnqsH+TOOGd0UqilhN6J13JSywt0lc7sYyWC7uqakB60Ua+6FOmyvx35iE FPLTPzRe/G7M9IJrOtc2HI6DQ2NF6BfsRKk5rnzGHYXPWsrnOrJE3mRFdNmbvmKLheiP TpaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PHM+26UznxtCrEcOMBBFaG2mOTIhJbFNgTBmBbELRHI=; b=lIfCJZoLNo5MO3rtxU9Ege0O7ARGBR6kWQ2dHMxN6U+XKiAZOv6zYndaTHkeTcwgt0 jkFkTQmGiWsyp2ZVvkNuDyLdC7MGYJkahJ+jls3JR7FFLvpQ3xg6YkKnd9MREFbm1GBp svnlUyDIDpFZswcUBczrT/vXhdwoyK+NflAueE8RTV5aeHslFEwc8dn2KNsF+ZozqPis m1p7v9M18M+WGvVCnJ7t7NVSedBorLTe9IlYuQEhWfg/tDFfA4tgpk//muZnvcoK+xNH xedZza0isD9KJDLXARk+wGCvHvCBPqmJY6cjGvgY9PPgIhu3DQMd18g2u0Fj5h7Sz13r 2htQ== X-Gm-Message-State: ALyK8tLt2LEVmf5GNGnq0Ab+lwhEq/Xrp7DdQh4VM7M9wZTuJCXZrTme5tpBR8xUFhARkA== X-Received: by 10.66.179.169 with SMTP id dh9mr16088020pac.133.1465104868407; Sat, 04 Jun 2016 22:34:28 -0700 (PDT) Received: from [192.168.178.22] ([118.148.64.37]) by smtp.gmail.com with ESMTPSA id ut6sm16155190pac.37.2016.06.04.22.34.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 22:34:27 -0700 (PDT) Subject: Re: Testing ULAness To: =?UTF-8?Q?Roger_J=c3=b8rgensen?= , Lorenzo Colitti References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 5 Jun 2016 17:34:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:34:31 -0000 On 05/06/2016 17:06, Roger J=C3=B8rgensen wrote: > On Sun, Jun 5, 2016 at 6:42 AM, Lorenzo Colitti wr= ote: >> On 5 Jun 2016 1:37 pm, "Brian E Carpenter" >> wrote: >>> The IANA IPv6 Special-Purpose Address Registry* has a column marked >>> "Global". >>> For fc00::/7 (ULA) this is set to "False". >>> >>> That is surely wrong. >> >> Is it? https://tools.ietf.org/html/rfc4193#section-3.3 >> >> =3D=3D=3D=3D=3D >> o Global - A boolean value indicating whether an IP datagram whose >> destination address is drawn from the allocated special-purpose addres= s >> block is forwardable beyond a specified administrative domain. >> =3D=3D=3D=3D=3D >> >> Doesn't seem that obvious to me that ULAs are forwardable on the inter= net. Doesn't seem to me that this is the agreed definition of global scope for= IPv6. > Global got nothing todo with being forwardable or not. It is more about= if the > prefix is unique or not. This remind me of a discussion with some years= ago... >=20 > ULA-C, ULA-G etc, one result of all that was > https://www.sixxs.net/tools/grh/ula/ >=20 >=20 > And about Brian's question, ULA-G/ULA-C was an attempt to make them > more true global than ULA, so not sure if the global set to false is wr= ong. ULA/C is a red herring, I think. We explicitly abolished site-local scope= , so if it isn't link-local, the scope is global. That's a matter of defini= tion. Brian From nobody Sat Jun 4 22:44:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0F12D58D for ; Sat, 4 Jun 2016 22:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 x6jr_iAlDdyR for ; Sat, 4 Jun 2016 22:44:14 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CE312B02D for ; Sat, 4 Jun 2016 22:44:14 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o16so115004961ywd.2 for ; Sat, 04 Jun 2016 22:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XVTfVzafFYWWHNcyTiBxsu1XWQkkRL0eg6qRNdOFPQM=; b=IGS3XncUrXWkye5DkN2YgfzWfEwkCx+45Jl+TDw/nBFHVhfvq2tMyhWloPjlJl1D7e qrF+PswAcDHJ3kzqTzg8wALOT5CL41iXWaiAF+PFeq/o8HfdhwRlQ5mJOYOCELQKRk8Y ngnkr8IU6YYZe1hGZcpr3iBebHpt1MZHvbj8Neu2BwxzSwLqdZVNJPfgEgbZMgNkPFRy F3J41S4vfFqxjB8Z15FKq2oiAEHtlLgAwuc+Y+UdKTVa2YHejHKn9Uh5YHuCIIr23wqh 3hK+oSYSh4XcOFq3oH/xRNLAPq+AJlinE4BZtbr+hsWRaVyaFQvhrqiHeXRzR0nSziKk P6bw== 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:date :message-id:subject:from:to:cc; bh=XVTfVzafFYWWHNcyTiBxsu1XWQkkRL0eg6qRNdOFPQM=; b=M6a1rTmo0pDqBHOPSPzruKmQVKrgYxsQTAktAsr93xD3pLTqxB5kO6RAtqeGGBg4R4 hXalV8t4Ywqj8LxkmIjxSo2k/z6d4wzFaTxcBt7xwLDl1vFQCwBTOWZQ2r+RGfskbx80 kZH/BDfOGbWat8W1ftqVDRBRejIEtJ90EkbDglMDppYS4KHJsIfurz/fAsTmmOxYw1YE rhdOGl/it/rO6TkBUBhvn6kkcPa2SuK/JoliAtD5+kYdiqTzmCMUwEb9KswSnBsXnq7g tO7Mv06ORAlaTltSjg1QeC4tBfETs+VaRqv8EsM6Q/1irCavdfYL8QR2KrS7w1bcW6Uk Zk7w== X-Gm-Message-State: ALyK8tIqHTExc2koBoVIfw3sbq+o2UsLOUEUI9hqeTs4cnGKuFM45hLWLkqOg47YGBUjU3u3hhf7iAYPsN1cRGo5 MIME-Version: 1.0 X-Received: by 10.129.146.87 with SMTP id j84mr8224383ywg.39.1465105453903; Sat, 04 Jun 2016 22:44:13 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Sat, 4 Jun 2016 22:44:13 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Sat, 4 Jun 2016 22:44:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Jun 2016 14:44:13 +0900 Message-ID: Subject: Re: Testing ULAness From: Lorenzo Colitti To: "Brian E. Carpenter" Content-Type: multipart/alternative; boundary=94eb2c0921fe23f120053481723f Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:44:16 -0000 --94eb2c0921fe23f120053481723f Content-Type: text/plain; charset=UTF-8 On 5 Jun 2016 2:34 pm, "Brian E Carpenter" wrote: > >> o Global - A boolean value indicating whether an IP datagram whose > >> destination address is drawn from the allocated special-purpose address > >> block is forwardable beyond a specified administrative domain. > >> ===== > >> > >> Doesn't seem that obvious to me that ULAs are forwardable on the internet. > > Doesn't seem to me that this is the agreed definition of global scope for IPv6. But it *is* the definition of global used by the registry. I think if you want the registry to say that ULA is global, the definition needs to change first. --94eb2c0921fe23f120053481723f Content-Type: text/html; charset=UTF-8


On 5 Jun 2016 2:34 pm, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> >> o Global - A boolean value indicating whether an IP datagram whose
> >> destination address is drawn from the allocated special-purpose address
> >> block is forwardable beyond a specified administrative domain.
> >> =====
> >>
> >> Doesn't seem that obvious to me that ULAs are forwardable on the internet.
>
> Doesn't seem to me that this is the agreed definition of global scope for IPv6.

But it *is* the definition of global used by the registry. I think if you want the registry to say that ULA is global, the definition needs to change first.

--94eb2c0921fe23f120053481723f-- From nobody Sun Jun 5 12:50:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10012D5AA for ; Sun, 5 Jun 2016 12:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wbv1OAnnzAOv for ; Sun, 5 Jun 2016 12:50:34 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E26712D50D for ; Sun, 5 Jun 2016 12:50:34 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id b5so170120pas.3 for ; Sun, 05 Jun 2016 12:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=et88yZyOpIhKp4llz7PHBxI8Uvv+25XRirYYolIvFB8=; b=SFuIr93yHLXtr/sx0jbfPOJ3cMMocB8dxbHTWkbAHyYE/3pKjcdQcOtk+84w0tYHRE M/5klUFEgCOILCChWX9X8AdNSH6pEqsVTC5fDsZN2xt9kTMIjelhw6TjcUh0+RHQuDWF wvgCkTqG0oaxmL1eRk4c7Uvl3OXWKZS6Mokhc6yQEEv/YmVl2VDr5eutfBr6ZS6Dr9/4 Hq68wZ9uKJSUzxauFqWxrPf9KYvJsLs6m7KHtjWxQmbcKD+3GYGL1KD46LZLZpilD1u9 W0ao7cxqF0UIf4KX6zVSgnJPPRF3rbhi5UkvSKWOkW/Hsfunye2Guwhqjf1h/4kD4+GC MmFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=et88yZyOpIhKp4llz7PHBxI8Uvv+25XRirYYolIvFB8=; b=N8HB8aYinQjNo5x5lS+bfzRnh1giHJSWaut1ABUQY/ORWi8Wvv+yXiDXM3z+UULwnw 0z5lgZl3u0JgAGu2EMu2U1+vyEDFFiIIouKBu+sDDTAkNoB2CXTeiSGMbt+vOO6vGZ65 NRc/f0MkCmIc14SYhnBmsukzvvkwbDSNQdRazGIHqCxcv2kMizsbsGJSm80CqfIgw386 J1S4p8GHSO1g8MUaEpPvjrHWShqBw2OvAJKHaPRbatP0wt2d7bD6ynpId6z5lnFWvApR rtveMA3wa6GB0nThSovuXOTJMuWjer9b5EBvI4OXoHqtNDY584WTFvP9QD++MQoCcSYA UZHg== X-Gm-Message-State: ALyK8tKw7Ubl+FuxDDQpJjgMiHp3t+C4QkrIPQqzH0wbIxL6+4FFRzGQT8A7L2lMW0gcwQ== X-Received: by 10.66.158.71 with SMTP id ws7mr15181215pab.159.1465156233800; Sun, 05 Jun 2016 12:50:33 -0700 (PDT) Received: from ?IPv6:2406:e007:5126:1:7c41:4ab7:7606:74a? ([2406:e007:5126:1:7c41:4ab7:7606:74a]) by smtp.gmail.com with ESMTPSA id r7sm2311610pfb.79.2016.06.05.12.50.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2016 12:50:32 -0700 (PDT) Subject: Re: Testing ULAness To: Lorenzo Colitti References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> Date: Mon, 6 Jun 2016 07:50:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 19:50:35 -0000 On 05/06/2016 17:44, Lorenzo Colitti wrote: > On 5 Jun 2016 2:34 pm, "Brian E Carpenter" > wrote: >>>> o Global - A boolean value indicating whether an IP datagram whose >>>> destination address is drawn from the allocated special-purpose address >>>> block is forwardable beyond a specified administrative domain. >>>> ===== >>>> >>>> Doesn't seem that obvious to me that ULAs are forwardable on the > internet. >> >> Doesn't seem to me that this is the agreed definition of global scope for > IPv6. > > But it *is* the definition of global used by the registry. I think if you > want the registry to say that ULA is global, the definition needs to change > first. I agree. And of course the appropriate definition may be different for IPv4. Maybe I should bring this up in Intarea. Brian From nobody Sun Jun 5 12:57:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ECE12D0E2 for ; Sun, 5 Jun 2016 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 3yv9RHy-bXx2 for ; Sun, 5 Jun 2016 12:57:45 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C6512D094 for ; Sun, 5 Jun 2016 12:57:45 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2016 19:57:43 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E1DB69CC4F; Sun, 5 Jun 2016 12:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=1YrObLR6VeEv/YwH6IbHTKzorYc=; b= TOK8TNeOqZ/eXDuCpvDAxH0INZ1wjmwRDndOiNN31T1nwR8rDcX9Zl5DjYyGsJ+8 BKARsQgXqL1APalDIakwfbmlS/So+eNAdwXk0VbSUYlw8BskvPOODYN3bW93tkRz tSBcUDle8FaQkQVBWy6iXm6iKeeXoMg8GaMVhneIMGw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ju+4rBAMvA3CueSHP+ceYrc0c3 q9fjNCerI9wcIIrJMy4Wc1Tb+0cYSicxb8bRvQE6+p6wTnZW0l1QPULq9AlkOHFN HqchxdOYWh7bDgvOlkUABhuYYDk39VBfjnyzZY7Xkbpy51Sxs+x/JA1xYzGis4S0 K2aWayWbK6URv3z50= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A1BE89CC4E; Sun, 5 Jun 2016 12:57:42 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5022418042EA; Sun, 5 Jun 2016 21:57:53 +0200 (CEST) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_82E23A74-2CB6-4A63-A3F8-F5F884689001"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> Date: Sun, 5 Jun 2016 21:57:50 +0200 Message-Id: <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 19:57:47 -0000 --Apple-Mail=_82E23A74-2CB6-4A63-A3F8-F5F884689001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >>>>> o Global - A boolean value indicating whether an IP datagram whose >>>>> destination address is drawn from the allocated special-purpose = address >>>>> block is forwardable beyond a specified administrative domain. >>>>> =3D=3D=3D=3D=3D >>>>>=20 >>>>> Doesn't seem that obvious to me that ULAs are forwardable on the >> internet. >>>=20 >>> Doesn't seem to me that this is the agreed definition of global = scope for >> IPv6. >>=20 >> But it *is* the definition of global used by the registry. I think if = you >> want the registry to say that ULA is global, the definition needs to = change >> first. >=20 > I agree. And of course the appropriate definition may be different for = IPv4. >=20 > Maybe I should bring this up in Intarea. RFC4773: 7. The registry will also note, for each designation, the intended routing scope of the address, indicating whether the address is intended to be routable only in scoped, local, or private contexts, or whether the address prefix is intended to be routed globally. http://tools.ietf.org/html/rfc4193#section-4.1 ULA addresses does not have global routing scope so the registry is = correct. I would be clearer if s/global/global routing scope/ in the IANA = registry. Ole --Apple-Mail=_82E23A74-2CB6-4A63-A3F8-F5F884689001 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 iQEcBAEBCgAGBQJXVIRBAAoJED4aXnjSQuKWw2AH/3R8pH/mORxC16vAq73GwSuf x4FgZj9DH+HTzlGCB5AuGUlJT37gWu+EEpDG0Ypnvp/QOSQWMC/kIo7aY50OwYW4 rn45gTAWu3Siwu2VIyzgVBpKkrq+QAGYukCoU1fzlm7VGtIKh56/BwNT+LSI13rP ileh206eViu3i/v0BTg0AoWkdulElLCQ6xwgAXxL92M8gEYqFj+uv/WFM5TqVQa4 essSgesIt/SGAa/Kt21OeCbI8ZxyjUgA3x4fkQ4fnTYnJTFYmfxO6ZbRChyRNVOd 3jImujy+lbNNfPF8PwMR/kU4AFTSbqjAgZwP+lLl0XbxJUEXr/m7Z6rkNrPKDQU= =PA0U -----END PGP SIGNATURE----- --Apple-Mail=_82E23A74-2CB6-4A63-A3F8-F5F884689001-- From nobody Sun Jun 5 13:50:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1AE12D54B for ; Sun, 5 Jun 2016 13:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 s5MPS1kKS9pq for ; Sun, 5 Jun 2016 13:50:38 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0178712D620 for ; Sun, 5 Jun 2016 13:50:38 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id bz2so28983773pad.1 for ; Sun, 05 Jun 2016 13:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NgKoum/gSmU8NCzvpluBA2Ug9DcxZdk9KJ2gyauIMlI=; b=sKV4M/1kxhRR4MtIUyTpFM5b6W+yPzYh/4C6UnMD+Dmpx2LCeM4umryWVUI14pXh7Z Pyrj9wQqEvu3bRqHVyTPjjWvz15p7RVAinb2ONNFADrWY98wzoDmoz9Qjp8o4EZKmkoG kM3nO+QAQWRonts+PTcpHbGzXBlwqsPeR5KNAu2cDfIPdx+RNg1WSaqkuqQqAZYIWg2K vfY/aTuPP1qtjgsSNiWcIFFPmJwIoRfkKwxRWsgKjwjQOqnKYFJseplvATGNM2KSl0wI /utfmQ2hM6808n9hgmtH+WcY/oxrN9W4SkfZTo71OAXr1T6Rfu0hn3a6ytycrrxIEQto yWpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NgKoum/gSmU8NCzvpluBA2Ug9DcxZdk9KJ2gyauIMlI=; b=e52b7pYcxlOxBQEwHdNZSsYZwyJZdvI+sLXWaoKlzbKdrZaS3QtUxnldxcQsEWc/3P yDmoNHgPPANNQp7uIeIa2NxFMAhgz90CJnfTca+M7OVheFajUhzGNZ+9ccBMI9AgIz1L e5KUdKxQZoHtDGnZx0gngUnoCde1GKNacSzXg+ac8IztsfxPLQjoxERiLI/7s8tvkPm0 oLYJR90FkMzPmgJtlqkvFVFfrUsfIsUqdvoRC9dt1ggG6QYXqYN0jUlKVxOSuAzPzCwl 53DWuqiMui4qpsnkhPKebXaf011/+HpTEd+o5FDvLoirFr9uBbRNB0HTWQxHGoXeNPTm M57A== X-Gm-Message-State: ALyK8tIRvfSKZ8ECjvihDysZDl9WLPSH1bkatrekOi5FVp3qeLPxgCtwbKuYoInJTysqZg== X-Received: by 10.66.132.103 with SMTP id ot7mr20614600pab.60.1465159837483; Sun, 05 Jun 2016 13:50:37 -0700 (PDT) Received: from ?IPv6:2406:e007:5126:1:7c41:4ab7:7606:74a? ([2406:e007:5126:1:7c41:4ab7:7606:74a]) by smtp.gmail.com with ESMTPSA id 83sm22338871pfl.12.2016.06.05.13.50.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2016 13:50:36 -0700 (PDT) Subject: Re: Testing ULAness To: otroan@employees.org References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 6 Jun 2016 08:50:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 20:50:57 -0000 On 06/06/2016 07:57, otroan@employees.org wrote: > Brian, > >>>>>> o Global - A boolean value indicating whether an IP datagram whose >>>>>> destination address is drawn from the allocated special-purpose address >>>>>> block is forwardable beyond a specified administrative domain. >>>>>> ===== >>>>>> >>>>>> Doesn't seem that obvious to me that ULAs are forwardable on the >>> internet. >>>> >>>> Doesn't seem to me that this is the agreed definition of global scope for >>> IPv6. >>> >>> But it *is* the definition of global used by the registry. I think if you >>> want the registry to say that ULA is global, the definition needs to change >>> first. >> >> I agree. And of course the appropriate definition may be different for IPv4. >> >> Maybe I should bring this up in Intarea. > > RFC4773: > 7. The registry will also note, for each designation, the intended > routing scope of the address, indicating whether the address is > intended to be routable only in scoped, local, or private > contexts, or whether the address prefix is intended to be routed > globally. Note that RFC4773 was obsoleted by RFC6890, so that's already a bug in the registry. This paragraph has been blown away. RFC6890 defines 'Global' in the same words used in the registry, and I believe those words are inconsistent with the IPv6 RFCs. > http://tools.ietf.org/html/rfc4193#section-4.1 > > ULA addresses does not have global routing scope so the registry is correct. > I would be clearer if s/global/global routing scope/ in the IANA registry. Firstly, this is a very unfortunate situation. We are using the same word to mean two significantly different things. If you think of the decisions you might need to make about an address, having (not global) different from (local) is an odd thing. By introducing the notion of 'private' which is not part of the IPv6 notion of scope, RFC4773 added confusion, IMNSHO. That has been removed by RFC6890, but is still present in (for example) Python. What's the real meaning of 'global' in IPv6? All I can see is 'forwardable beyond this subnet'. Beyond that, any GUA or ULA can be dropped by any router that feels like it; we simply have a recommendation that ULAs should be dropped at some administrative boundary. Brian P.S. I am not raising this to be picky. I'm raising it because I had to code around it a couple of days ago, when my ISP failed to give me an IPv6 prefix and my FritzBox gave me a ULA instead. It broke my code because the ULA tested as (not global). From nobody Sun Jun 5 15:51:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6012D567 for ; Sun, 5 Jun 2016 15:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WWsbe_2FeeCI for ; Sun, 5 Jun 2016 15:51:48 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 A8E3F12B00A for ; Sun, 5 Jun 2016 15:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u55Mpl7D031683; Sun, 5 Jun 2016 15:51:47 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u55MphI9031673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Sun, 5 Jun 2016 15:51:43 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Jun 2016 15:51:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Sun, 5 Jun 2016 15:51:42 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter Subject: RE: Testing ULAness Thread-Topic: Testing ULAness Thread-Index: AQHRvuQBtGEalT7iykOfiBLiE1JBV5/awPiAgAAGoACAAAfNgIAAAr+AgADscICAAAIQAIAADrkA//+oXyA= Date: Sun, 5 Jun 2016 22:51:42 +0000 Message-ID: <35c5890ca09c4da08ae1b23beb7aec56@XCH15-06-11.nw.nos.boeing.com> References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 22:51:50 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > P.S. I am not raising this to be picky. I'm raising it because I had > to code around it a couple of days ago, when my ISP failed to give me > an IPv6 prefix and my FritzBox gave me a ULA instead. It broke my code > because the ULA tested as (not global). Yes, and the FritzBox was right in doing so. ULAs should not be routable gl= obally, even if there's a reasonably good chance that the prefix might be u= nique. (There's no uniqueness test of any kind, however.) As a philosophical point, it seems that whenever we try too hard to make ru= les for IPv6 so different from the rules that evolved in IPv4, we run into = trouble. This looks like another example. ULAs might not be RFC 1918 privat= e addresses de jure, but I think it's not so far-fetched to think of them t= hat way de facto. ULAs should be routable as much as RFC 1918 addresses are= routable. Route all you like, within your administrative domain. Isn't thi= s the way they're meant to be used? Bert From nobody Sun Jun 5 16:17:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EFE12D60B for ; Sun, 5 Jun 2016 16:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JPfLXVHTZ5gs for ; Sun, 5 Jun 2016 16:17:39 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B9612D0B7 for ; Sun, 5 Jun 2016 16:17:39 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id 62so60675268pfd.1 for ; Sun, 05 Jun 2016 16:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LWeYfZUlQ3+yHIFZBKinmJtUQsEk05dxlIwAjFFAbbM=; b=ckYdUm3jP7FTGprkg+aACwURbm1zHOgAGJrs4iuK8nb1qCAYvTYwJtx9rk0PChWBZa mhB3kBu/Ht2qVC6Nz2V7SBU5XB0wtL4TBXaRRGhDN6FJLLLnzjCv8Z/0NPpn0/Cyl06C XzmoJy9TYM5mznvfhOGg1rz5Aa+MuxaguiG3MSDZKm1vjwD7YHghPtDKv+vKKjvri1UY BCaOH3VdB7lrPqLreqW69Px3PmBIJJvvptxq40Ryzq/QVouZyY2H0NEoy11eeX88YwVo TCEiKmZUJLo9CEPZeuF00R16FqWyTG/Oo8xVIS7+zkEvK4tHJgDBo43ltEzrGzRBfi0F /8xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=LWeYfZUlQ3+yHIFZBKinmJtUQsEk05dxlIwAjFFAbbM=; b=huLqoPq7+yfTcaZ+Z9pbk3ErUIB6gCWVa4FmZSSL0umCvevVSGh6hRIOO/g5LizJO5 W4c4/dywtvUQHLpwt0g5DES6nWbfK2zzSTpLU0c10h+IjS2dIySrvGzEfDZtcs1AXuMW H5XfwZ3zv0vl4XNV2Blc6haLTebg3bYzHgBW19vfs3xl0HOsCZ1Tnw+wn5PmtFrPjRyo EmWLtIEOa/aeWp7XUmOMhuWk2SWiIl4m4iJlqS4pwMS4C3oM2iOiTTI17safoDe4awCd H1SFH60y2Z7375sib3SajFUOPvEsI8mK0PgPDbmbJiFqnO8JggiNpkqMlJsQaYwbUUN1 HsJQ== X-Gm-Message-State: ALyK8tIeeCS4cXqfkbYO4FV+Nx1XyD4Df/yp50x8Miq5AyCEuyKl3EJXoG+eL0xxetpuLw== X-Received: by 10.98.102.205 with SMTP id s74mr21452645pfj.54.1465168658410; Sun, 05 Jun 2016 16:17:38 -0700 (PDT) Received: from ?IPv6:2406:e007:5126:1:b8a2:3b18:9ca4:38b4? ([2406:e007:5126:1:b8a2:3b18:9ca4:38b4]) by smtp.gmail.com with ESMTPSA id g86sm11545724pfd.67.2016.06.05.16.17.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2016 16:17:37 -0700 (PDT) Subject: Re: Testing ULAness To: "Manfredi, Albert E" References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> <35c5890ca09c4da08ae1b23beb7aec56@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 6 Jun 2016 11:17:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <35c5890ca09c4da08ae1b23beb7aec56@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 23:17:40 -0000 On 06/06/2016 10:51, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >> P.S. I am not raising this to be picky. I'm raising it because I had >> to code around it a couple of days ago, when my ISP failed to give me >> an IPv6 prefix and my FritzBox gave me a ULA instead. It broke my code >> because the ULA tested as (not global). > > Yes, and the FritzBox was right in doing so. ULAs should not be routable globally, even if there's a reasonably good chance that the prefix might be unique. (There's no uniqueness test of any kind, however.) Of course. I was pleased with my FritzBox, it did exactly the right thing. > As a philosophical point, it seems that whenever we try too hard to make rules for IPv6 so different from the rules that evolved in IPv4, we run into trouble. This looks like another example. ULAs might not be RFC 1918 private addresses de jure, but I think it's not so far-fetched to think of them that way de facto. ULAs should be routable as much as RFC 1918 addresses are routable. Route all you like, within your administrative domain. Isn't this the way they're meant to be used? Exactly. But this isn't correctly reflected by a Boolean notion of global scope. (Neither is 100.64.0.0/10 .) Brian Brian From nobody Mon Jun 6 00:28:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8C912D5FD for ; Mon, 6 Jun 2016 00:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 xd4F4NQESjlj for ; Mon, 6 Jun 2016 00:28:32 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBBF12B02E for ; Mon, 6 Jun 2016 00:28:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0215.outbound.protection.outlook.com [213.199.154.215]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-32-D4S5npUqSuqGQ8JJ5ZWgug-1; Mon, 06 Jun 2016 08:28:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IK0qfSgeLSBISHgQOfglTJYRBKODWE2w+uNW9BVuNaE=; b=C5ouAmwuLlKC21QW3Oqrmlo1ElvYmIM7pGIq7UHpf5m7mV6GM93XTs9xhsB2yfpkonbqq74vJs7bUYmMfafx04J5gtJnexWuY3kvcV5DRmslPHfo/UlKSyAfaeIY9MmzxPR2qfqZ4FcZ061+gaNyuXAn/T5cPJZ6wSj+2+QLjZ0= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 6 Jun 2016 07:28:27 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0501.013; Mon, 6 Jun 2016 07:28:27 +0000 From: Tim Chown To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt Thread-Topic: I-D Action: draft-gont-6man-non-stable-iids-00.txt Thread-Index: AQHRtTJXYExvL/UfBECtOLOitRpqx5/HHSiAgAOLYACAAAJogIAN40KAgAORnQA= Date: Mon, 6 Jun 2016 07:28:26 +0000 Message-ID: <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.188.254.49] x-ms-office365-filtering-correlation-id: 649d4931-7228-4f87-d6d0-08d38ddc26b2 x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 5:LwFeXndOS/B+QCkDg3MwgwakJEX/WnOutuk6X5QysfdOPkYafWyyLbEYKlAv2DMLZXHq/YGNsVhn7jjli+o0ZQhN6Kb2X+41wlWZl8683hnyI2oZnXCEB3vso2v7QPR89en6ImyHL8Rdg2psifCpEw==; 24:1Ak3/Cwm1F415Z8r1baygwifzZVznzJey/Ryc1rjpXOWJuR+8DHyD0Vb8hPYpF+AC6Rfo7IP9wdUW4wFzQhIps2sWGhk2v/84OugRo9j25A=; 7:QmnWEeAyxq7Ktfjr33/3m23727/zR9ugnmthgxn7JF+hNH2xu6luG70qR9JuF0IRmcRm+mB63aHT1S0Js6RiMnN8I14kV/UENgXjWLbsEROHhEMjbr5le0ddryztKYyKwojktiXruV6TXl5Ae/KZbXzeHjUBB4aGBVfL12FCwdz/pkq3En5XfKNivX44nlGClLuZ5y0W7S1m4u5b8swHgePkQQKhHqnkZ9zo+LCwfnE=; 20:ZDDB0+Vbo66LRvXpi4Ilfg9TJsKaB9s/FMOP5X6srjbONTZq/RCxkz2plQHQwp3YWV3UBNmKu2GVl1Fb9bz/plMG74W02ZW56MzDkXzMl4V2KxYEP0a1EAlmHC7MId98Iydxs9pIur/WJZbM0rO2BnrO2JvoAscI0IXueINgUOo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(69234005)(24454002)(199003)(377454003)(92566002)(5002640100001)(97736004)(5004730100002)(8936002)(87936001)(106356001)(2900100001)(83716003)(81166006)(551544002)(77096005)(8676002)(106116001)(68736007)(93886004)(105586002)(3280700002)(4326007)(57306001)(82746002)(66066001)(3846002)(81156014)(230783001)(2950100001)(86362001)(101416001)(10400500002)(122556002)(2906002)(74482002)(33656002)(19580395003)(189998001)(36756003)(50226002)(586003)(5008740100001)(3660700001)(15975445007)(6116002)(50986999)(19580405001)(11100500001)(76176999)(110136002)(102836003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <60DA8E444357014D9BDC7266E6016076@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2016 07:28:26.9385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: D4S5npUqSuqGQ8JJ5ZWgug-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:28:49 -0000 Hi, > On 4 Jun 2016, at 01:59, Brian E Carpenter = wrote: >=20 > FYI, I've just decided to end my experiment in running my laptop without > a stable IPv6 address, which I started on May 19th. >=20 > The only very minor issue that I noted with my regular workload is that > occasionally the gmail SMTP server asks me for my password again. >=20 > However, I did have to spend an hour or so making my prototype of > the Anima WG GRASP protocol robust against unplanned address changes, > especially its discovery mechanism. So the caveat is obvious: there > is certainly software around that has not been made renumbering-proof. > But if something is already roaming-proof, it most likely doesn't care > about stable addresses. >=20 > (The only tricky part was that on Windows, the stable address keeps > reappearing every few minutes automatically, so rather than dig around > looking for a way to stop that, I've been running a script that deletes > it every time it appears=85) So there=92s two categories here; one is the issues because you=92re runnin= g privacy addressing, the other is the issues from not having a stable addr= ess. Would you have encountered the above even with a stable address runnin= g? And would the software that would in principle prefer a stable address (= e.g. the anima stuff) use an API to signal that preference (as per the last= part of 3.1 of RFC4941)? I suspect you would have seen the above effects even with stable addresses = available in addition to temporary / privacy addresses? Tim > Regards, > Brian >=20 > On 26/05/2016 16:54, Brian E Carpenter wrote: >> On 26/05/2016 16:45, Lorenzo Colitti wrote: >>> On Tue, May 24, 2016 at 7:38 AM, Fernando Gont >>> wrote: >>>=20 >>>>> P.S. My personal experiment in running my laptop for several days >>>>> with no stable address has been completely successful. Including the >>>>> fact that my prototype of the Anima signaling protocol crashed after >>>>> a while, because the address it was relying on went away, which is of >>>>> course the expected behaviour. >>>>=20 >>>> So, the question is: can this be considered "acceptable" behavior? >>>>=20 >>>=20 >>> Yes, because IPv6 address can expire and be replaced at any time in a >>> renumbering event. >>=20 >> Need I add that we will be putting some words about address stability or >> its absence into the appropriate Anima documents. Obviously, we want the >> autonomic networking infrastructure to be both stable and self-repairing= . >> But then I think we'd like all applications to have those properties. >>=20 >> Brian >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Jun 6 06:45:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA612D784 for ; Mon, 6 Jun 2016 06:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 TCyIZ5FiYKjS for ; Mon, 6 Jun 2016 06:45:01 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026E412D131 for ; Mon, 6 Jun 2016 06:45:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u56Diw9I016098; Mon, 6 Jun 2016 15:44:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 98D1D2085DA; Mon, 6 Jun 2016 15:45:26 +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 8B0EF208628; Mon, 6 Jun 2016 15:45:26 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u56DiwGd000814; Mon, 6 Jun 2016 15:44:58 +0200 Subject: Re: possibility of a MAC randomization algorithm To: Christian Huitema , "ipv6@ietf.org" References: <5704F1C8.8010508@gont.com.ar> <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 6 Jun 2016 15:44:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:45:03 -0000 Le 03/06/2016 à 20:55, Christian Huitema a écrit : > On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote: >> >> About the possibility of a MAC randomization algorithm, regardless >> of being used in an IP address: >> >>> we do not control whether MAC addr randomization algorithm is >>> appropriate or if it is actually possible. > > It is certainly possible, since it is shipping in Windows 10. > >> The algorithm output should be checked against the authoritative >> oui.txt, and not generate an existing OUI (organizationally unique >> id). > > There is a potential debate about that. What we are doing in Windows > 10 is set the "local" bit to true, which means that the OUI does not > apply. But, I understand the use of the u/l bit is no more desirable - it is part of an IID and the IID is opaque: RFC 7136 "Significance of IPv6 IIDs". >> Is such an algorithm documented somewhere? > > Mathy Vanhoef, PhD Student Computer Security at KU Leuven, wrote a > nice blog containing such a description: > http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html Thanks for the pointer, that's useful indeed. Whereas it does present an analysis on the algorithm, it could further be improved with the following aspects: - it should work not only on WiFi but also on other links which dont have SSID but do have 48bit MAC addresses (e.g. cellular, USB, 802.11p, others). The described algorithm uses SSID in the SHA calculation. - it should check a generated random MAC address does not clash with existing oui.txt assignments, otherwise it may involuntarily attack others (pretent to be someone else). Alex > > -- Christian Huitema > > > From nobody Mon Jun 6 07:01:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0446C12D6B1 for ; Mon, 6 Jun 2016 07:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rehcxLrGte71 for ; Mon, 6 Jun 2016 07:01:22 -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 CD8D612B02A for ; Mon, 6 Jun 2016 07:01:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEBA82015D for ; Mon, 6 Jun 2016 10:08:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AAD3638BF for ; Mon, 6 Jun 2016 10:01:20 -0400 (EDT) From: Michael Richardson To: IETF IPv6 Mailing List Subject: Re: Testing ULAness In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:01:24 -0000 --=-=-= Content-Type: text/plain I agree with Lorenzo. ULAs when created properly are probably globally unique, but there is no guarantee. They are RFC1918-like. That's why you don't get reverse DNS or whois. It's why I'd really like to revisit ULA-C, but I'm mostly alone in this view. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1WCLYCLcPvd0N1lAQLmvgf/QNioZPv9kP9f5EA98jPOEhwbZTaRo7JG N0rbvULdJ5sQ1hnwX0NHYdzKp9LFCH5t701Gv2CPIz8KsLcxNSvQssvs0uFQ50Ag Px+DB5W1gqclFeHP7NKrAdpvnWKcHTS1zPg7IndU1g6gS+RXwpP2wJIwyZ4ZFfxY c9ap9ZcsGq60Pc8LeEIPY2RFwi1VYpG8cUWBwKVxKDWczslboQ81Lt+Z69aKHl6P FCrWAHUu1sv1Zv0zrh0mKUjCn02Fiu2gPRWrM1d2AD7cdj10ihWgWF5Gf8BZNt/h ARe5s7R5bthjd40FM8lm1CD3insSQL2HVuLrmMtypYi6MIXPG4Sy9g== =rrVj -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 6 07:10:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4F12D7A7 for ; Mon, 6 Jun 2016 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 kmFd9pkq2AhO for ; Mon, 6 Jun 2016 07:10:39 -0700 (PDT) Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A7D12D0F4 for ; Mon, 6 Jun 2016 07:10:38 -0700 (PDT) X-MDAV-Processed: mail.consulintel.com, Mon, 06 Jun 2016 16:10:34 +0200 Received: from [10.10.10.99] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000586414.msg for ; Mon, 06 Jun 2016 16:10:33 +0200 X-Spam-Processed: mail.consulintel.com, Mon, 06 Jun 2016 16:10:33 +0200 (not processed: spam filter heuristic analysis disabled) X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Return-Path: prvs=196586e86e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Mon, 06 Jun 2016 16:10:28 +0200 Subject: Re: Testing ULAness From: JORDI PALET MARTINEZ To: IETF IPv6 Mailing List Message-ID: <9B57626B-2395-4C1C-A335-3FAD40024E47@consulintel.es> Thread-Topic: Testing ULAness References: <22582.1465221680@obiwan.sandelman.ca> In-Reply-To: <22582.1465221680@obiwan.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:10:42 -0000 I will be happy to work on that as well =E2=80=A6 I tried a couple of times, the main issue is that we also need to define th= e =E2=80=9Ccentral=E2=80=9D registration authority. One option will be IANA. The other o= ne the RIRs (they could delegate to one, or to the NRO, or a central registr= y handled by all them). Probably to be able to be done by the RIRs, we need = to global policy (I tried to push that as well in the 5 regions, no success)= , and a =E2=80=9Cregistration fee=E2=80=9D. May be the IETF can just ask IANA to hold that registry for free as part of= the IETF-IANA services agreement. Saludos, Jordi -----Mensaje original----- De: ipv6 en nombre de Michael Richardson Responder a: Fecha: lunes, 6 de junio de 2016, 16:01 Para: IETF IPv6 Mailing List Asunto: Re: Testing ULAness > >I agree with Lorenzo. >ULAs when created properly are probably globally unique, but there is >no guarantee. They are RFC1918-like. > >That's why you don't get reverse DNS or whois. >It's why I'd really like to revisit ULA-C, but I'm mostly alone in this vi= ew. > >-- >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From nobody Mon Jun 6 08:28:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE93812D802 for ; Mon, 6 Jun 2016 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Pa2JQwq4rlrX for ; Mon, 6 Jun 2016 08:28:42 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A126812D800 for ; Mon, 6 Jun 2016 08:28:42 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z189so45726238itg.0 for ; Mon, 06 Jun 2016 08:28:42 -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:from:date:message-id :subject:to:cc; bh=DnK89bFqEc1aEr26MY41mW+KBTmCxE+QbyspE+C9YgE=; b=xbmHnQ8uUkafWDhL9STkIxZR98XcuDNT4q2NXz3wM9zCZIMAwU21Wadd2PvPKT0hmJ ZvOl1+7J0Wy4nQYBXmKDwNwAcgNN0oE5w3gMR8AIEzRMm4iexGrm2eJq8dFPSjFu5LBs YIbL6vElWM7vqAaIwr/rSs7QYAIdcmtpXNyyFi1W1gm/tdeeu+itBIVC/ytY1jqrV5H4 TVx202AMEf71yAYH581eiXLSENphxjPegHIoYNh0lNpBIqTqRweYbCXHqr6fSemVnike r4hztUGatRzfs8iyCrlcjLlfKjw3EgNuBZ4IDGR49tmdz2pXl9PwCMXinQub1B7FzY63 QHfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DnK89bFqEc1aEr26MY41mW+KBTmCxE+QbyspE+C9YgE=; b=gliO5ib/W6Lgztr/6XWYrK9ANehU1fM352Os+svW05IiezyqWyHUnzKVlpZdVKSjkJ eJGi7ZRYLfl9jez7nFerM1DdWTvT3EiduFcoSJHDF/eZWRaruKQmIbUt+azPqPmLEYuX 6RkGhX0/ytFQyeXqhCjuOrIYNv2pLiqlPRFSzjnckVmOjPXyinCOQ0oJdJS+WfFIxoHx l+410O6cg/ibArWgxCzK6xOXcvu26+TDOJn3CizNO5R7hqusirLYB+fasUaQY4Wj5Q2e 1ZSgARKUGtcH+keSdVijafYThZTmZz0EOQPd6xIqI6K7yHiwsVwbjlagxHYQJWQbDrSx oZuw== X-Gm-Message-State: ALyK8tKng/E2k/JJGGZevwbKijgrj5euz89yo6GiV6R4cOfG+QZERgpGb+xeCKJQKUQxZux95v6TczsUm2Aezg== X-Received: by 10.36.80.4 with SMTP id m4mr18055850itb.37.1465226921925; Mon, 06 Jun 2016 08:28:41 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.79.129.2 with HTTP; Mon, 6 Jun 2016 08:28:41 -0700 (PDT) In-Reply-To: References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> From: Kerry Lynn Date: Mon, 6 Jun 2016 11:28:41 -0400 X-Google-Sender-Auth: ZXj8Y1h__D3zq8iQzaNNwCzqL7o Message-ID: Subject: Re: Testing ULAness To: Brian E Carpenter , Lemon Ted Content-Type: multipart/alternative; boundary=001a1143f4ee32636405349dba96 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 15:28:44 -0000 --001a1143f4ee32636405349dba96 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 5, 2016 at 4:50 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > RFC4773: > > 7. The registry will also note, for each designation, the intended > > routing scope of the address, indicating whether the address is > > intended to be routable only in scoped, local, or private > > contexts, or whether the address prefix is intended to be routed > > globally. > > Note that RFC4773 was obsoleted by RFC6890, so that's already a bug in the > registry. > This paragraph has been blown away. RFC6890 defines 'Global' in the same > words used > in the registry, and I believe those words are inconsistent with the IPv6 > RFCs. > > It appears the idea of making "global" N/A for ULAs was suggested by Errata ID 3879 but rejected: https://www.rfc-editor.org/errata_search.php?rfc=6890 I haven't found a discussion thread on the topic; perhaps Ted can provide additional insight. Kerry --001a1143f4ee32636405349dba96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jun 5, 2016 at 4:50 PM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
=C2=A0
> RFC4773:
> 7.=C2=A0 The registry will also note, for each designation, the intend= ed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 routing scope of the address, indicating wh= ether the address is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to be routable only in scoped, loc= al, or private
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 contexts, or whether the address prefix is = intended to be routed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 globally.

Note that RFC4773 was obsoleted by RFC6890, so that's already a = bug in the registry.
This paragraph has been blown away. RFC6890 defines 'Global' in the= same words used
in the registry, and I believe those words are inconsistent with the IPv6 R= FCs.

It appears the idea of = making "global" N/A for ULAs was suggested by Errata
I haven't found a discussion thread on t= he topic; perhaps Ted can provide
additional insight.
<= br>
Kerry
--001a1143f4ee32636405349dba96-- From nobody Mon Jun 6 10:41:38 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3310712D876 for ; Mon, 6 Jun 2016 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9m2Fu00IYy5T for ; Mon, 6 Jun 2016 10:41:34 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B12112D50A for ; Mon, 6 Jun 2016 10:41:31 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id b73so99354766lfb.3 for ; Mon, 06 Jun 2016 10:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yEio1rF/ZRIZBQesb/8kWvpxhkFCl4J+PBtb1/oDuR4=; b=x3MRMgzTnDxBb6cVE90xfPw13D0eyqY4fgxN+Ly3MrjMSg+eC96+qJxZydpALBJVfl 3tjzF/kNRb5AfJQo6wyJ9vd/yN0xjMUKv3DolP4KvNeKYGoofTUqS0NLaGEpEYwcuRMw XoF+qoGnjyzflcB1pf25q7bjig/q/27j5iVT0DqetgS7vcGGKcF1EI0fQe/fRKFfcyWb KjxKxIfO3ijVbGZECy9WW5nz6EjiCPpmS8gwQ1O/myaaloIxsPbjGptEARsYYh+QL+NL Jqp6kAyBj8yLlGYbczcTZkg6uMdHm5cVlxgyQF8NI1ch0eP+NZ5LNZnLL7/fCUvj79JE J1+g== 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; bh=yEio1rF/ZRIZBQesb/8kWvpxhkFCl4J+PBtb1/oDuR4=; b=laFl8dboXBkqvQ6xD/tllCER7f0yXDD+csS0+ittpfoOqldHSi39snFeKtHzq8cE7I d2BFXM3igNFkjFKva8gjohgPtrt6GLcWzQECrnVkQWws9J2lKe9aZH1Jxk6KwFxzr0O3 xjKOmva3R0Mv10sxgAYoOROA7Z5LGt/VKMtXUXCs1/mUiW7WBc5LhBg8snYgDY6JGvqe 4muROn76q4FJSgMFc56ro5n73XiJDJiGDS6BQWfHnrC1I2NuYydVAF5heBNxrLtfzFqv OID4+JgJJ6/PMI05+oBCC9UZoGGiWMbaxQJibjBokLx/sxszl4dIDtPZyikYzHb+aBXl fjGA== X-Gm-Message-State: ALyK8tJvueOnJ3MfotlMI5i6WdvjgVfISNYxnirQ9hgwY2N3H3IflMOBkYjQqfXALTAMY8lxjbTaPyJ8a6tiMA== X-Received: by 10.25.21.102 with SMTP id l99mr1573372lfi.27.1465234889441; Mon, 06 Jun 2016 10:41:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.39.1 with HTTP; Mon, 6 Jun 2016 10:41:28 -0700 (PDT) In-Reply-To: <22582.1465221680@obiwan.sandelman.ca> References: <22582.1465221680@obiwan.sandelman.ca> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Mon, 6 Jun 2016 19:41:28 +0200 Message-ID: Subject: Re: Testing ULAness To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:41:36 -0000 On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson wrote: > That's why you don't get reverse DNS or whois. > It's why I'd really like to revisit ULA-C, but I'm mostly alone in this view. no you're not alone there, I'm in on it to. Sixxs showed us how easy it could be done. The framework don't have to be that complicated to describe either but we'll see. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Mon Jun 6 13:20:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81912D90C for ; Mon, 6 Jun 2016 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jeaMdRA7JQ8i for ; Mon, 6 Jun 2016 13:20:11 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F5112D906 for ; Mon, 6 Jun 2016 13:20:08 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id z187so15978821pfz.3 for ; Mon, 06 Jun 2016 13:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BBhLFRMRCMoKrrTSDYXf9KbzRCMItvBQW/TQErECX1s=; b=ED+M/Wryoig7ErTrxORqFe42jROUiAx56oCzvlsGf9qg7Deeub3XxP5YsQTlRm0IkH kFRvDRr6O1eVi3b1kRvIMzh8/iGuObjbaR3V9+sUZRlOyXOMQZ2T57CFZFIyHFG0bPs1 pByaBG7Ep+0nS0tccjGxC95/Hrgv+D/e2pfrrBIG28iEzbateoX/K87eliPGTG4z8vqm sZqHpNB8kgNFg5dhloUAAoi7vuDOd8E1/ci4negJkTEID3Di7PWZYnjg85eRAzOJTzPI 4LHvLZ7hMzTpDwJg136COOPAeH8lmgXukqd9GdDVj5ec18ZFJnIhfUHvMzUL+pPrI96A fKEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BBhLFRMRCMoKrrTSDYXf9KbzRCMItvBQW/TQErECX1s=; b=B0tOrhL7N2vloVo7AwJ0ceErb77+uCP0yWXlDsJE6C1ICgoj+Bc4ERoQgG0M+85HUN 9NfTwhy3QzG0xg9WkOzWApen22DHij+/Z0SgmnsjPhv9CrcaqDDgncrukIuHzybRUF9J p+HM8WZET3pQiLN3rNqLn+V+5gyAn5mNqlI1Fs2kjmCIIEnZAyQxdXbJElMdDDN8XNo7 ZxxPH3GeqlfcJn4kWrxWpITGZLVeRMCs5iXelO++txFuJDuldIoI/ATZ0QwbqUZeLMtK B7sTUC+eT1ZwDqZlFs+BMS5RIL386HHufGsR77uuht5CFFzrAl6eyaPNMByP1TWLBng5 eJig== X-Gm-Message-State: ALyK8tLRKCMPk9Eahl3tokKPhbGQfuG6zSACH/MQp2KtLswMshphgqxgC415Sk1sWVGRqQ== X-Received: by 10.98.155.4 with SMTP id r4mr27491323pfd.1.1465244407601; Mon, 06 Jun 2016 13:20:07 -0700 (PDT) Received: from ?IPv6:2406:e007:77b7:1:7973:6585:6164:dd17? ([2406:e007:77b7:1:7973:6585:6164:dd17]) by smtp.gmail.com with ESMTPSA id d71sm29600898pfd.80.2016.06.06.13.20.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 13:20:06 -0700 (PDT) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Tim Chown References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> Date: Tue, 7 Jun 2016 08:20:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:20:15 -0000 Hi Tim, On 06/06/2016 19:28, Tim Chown wrote: > Hi, >=20 >> On 4 Jun 2016, at 01:59, Brian E Carpenter wrote: >> >> FYI, I've just decided to end my experiment in running my laptop witho= ut >> a stable IPv6 address, which I started on May 19th. >> >> The only very minor issue that I noted with my regular workload is tha= t >> occasionally the gmail SMTP server asks me for my password again. >> >> However, I did have to spend an hour or so making my prototype of >> the Anima WG GRASP protocol robust against unplanned address changes, >> especially its discovery mechanism. So the caveat is obvious: there >> is certainly software around that has not been made renumbering-proof.= >> But if something is already roaming-proof, it most likely doesn't care= >> about stable addresses. >> >> (The only tricky part was that on Windows, the stable address keeps >> reappearing every few minutes automatically, so rather than dig around= >> looking for a way to stop that, I've been running a script that delete= s >> it every time it appears=E2=80=A6) >=20 > So there=E2=80=99s two categories here; one is the issues because you=E2= =80=99re running privacy addressing, the other is the issues from not hav= ing a stable address. Would you have encountered the above even with a st= able address running? And would the software that would in principle pref= er a stable address (e.g. the anima stuff) use an API to signal that pref= erence (as per the last part of 3.1 of RFC4941)? >=20 > I suspect you would have seen the above effects even with stable addres= ses available in addition to temporary / privacy addresses? Taking the last question first, no, because when you bind a listening soc= ket to ::, it appears to latch onto the stable address if there is one, so the appea= rance or disapperance of RFC4941 addresses doesn't matter. When there is no stable= address, the listening socket will latch on to the most recent RFC4941 address, wh= ich of course changes from time to time. That is what I had to program around fo= r GRASP. So in answer to the first question, no, just switching on RFC4941 wasn't = a problem. It was switching off the stable address that gave my code something I wil= l call colittis (sorry, Lorenzo). And your second question: RFC4941 indeed says "This document also assumes= that an API will exist that allows individual applications to indicate whether= they prefer to use temporary or public addresses and override the system defau= lts." As far as I can see, "public" means what we've been calling "stable" here= =2E So in practice, the default behaviour (on Windows) is for a listening soc= ket to prefer a "public" address, and if there isn't one, to prefer the lates= t temporary address. Apart from explicit use of bind() to choose a particul= ar address, I don't know how to change that. Maybe a more experienced socket= programmer knows. Regards Brian From nobody Mon Jun 6 13:25:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A3B12D57B for ; Mon, 6 Jun 2016 13:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7j_PZrTxyPFI for ; Mon, 6 Jun 2016 13:25:47 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A793F12D1B8 for ; Mon, 6 Jun 2016 13:25:46 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id g64so70095128pfb.2 for ; Mon, 06 Jun 2016 13:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=y9PC/lz2gazm/eoM4jnWpn9ty5on66NXjsucmFStHYM=; b=ap/gCTedMetZVkJWDNDWUWCSucmbDUFA9X4OFvH9LsxqK/WYiIjDclOBlh73A2V0ym 3wftWIsrgV5soRINg7QTRMs4eonJrNfxMg0nEQlsbWQjndKD3E8t2h/OWui2eMeSDacp WjW3u3Bw+whP5Z+jkMEDa7ezWnH1V4hP9vUumqIcacmiv7ww9q8ZsL4iW1C0oHjQXfuI oRdmzEJMJnt6ZR0azMkKW0wsHMfQNdIdCxn3dMBYN+C0+sC+ido+8bWuAWwwIDIBmKFv cMs1xy0BszG7Qg7SfuyoXV1OhuWfpY3B45nWaOQkhdj852BE15GRETygGgYSqGXGovJ/ yMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=y9PC/lz2gazm/eoM4jnWpn9ty5on66NXjsucmFStHYM=; b=L9XybfI8sL5FTNqzluBDldDi8Nqta6f0DvdVvKNStisc9SwX1YTSwJgbyg/eenb/gy yTIkX98vYJ/9x7rzNB7iPlwcXxykVBq5pumnTyeUvfLGFzT5i47+/jDl54hBK2bupbcL l8VoRQI8pQ+wlhskjPOGHfrRByesQI9CQeTfbKLA3YoBdhP6FSvRbgK+xETtW7eNOfjE QxvoxDPqp780qTsIuVd1kmNEO8QV5HGGtQRPQcFQnylZnJbN/pV/SbHCiL6JnqY4bQA2 I/0YJn9iu6w+BIJag5C5CEM+dgyuDLbNluu/XdiqkSeqQK/HpC+JdCeS368A0yqyNYnl ivPA== X-Gm-Message-State: ALyK8tL7M9A3heOdH63Zr0gdRQy06JjBz5LihqtoAJ49mU7ZQ2NrhbbKjhd3VUYItJF8Zg== X-Received: by 10.98.23.146 with SMTP id 140mr27555028pfx.122.1465244746195; Mon, 06 Jun 2016 13:25:46 -0700 (PDT) Received: from ?IPv6:2406:e007:77b7:1:7973:6585:6164:dd17? ([2406:e007:77b7:1:7973:6585:6164:dd17]) by smtp.gmail.com with ESMTPSA id x187sm25439347pfx.87.2016.06.06.13.25.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 13:25:44 -0700 (PDT) Subject: ULA-C [was: Testing ULAness] To: =?UTF-8?Q?Roger_J=c3=b8rgensen?= , Michael Richardson References: <22582.1465221680@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Jun 2016 08:25:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:25:48 -0000 Changing to the subject to what you are talking about... On 07/06/2016 05:41, Roger J=C3=B8rgensen wrote: > On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson > wrote: > >> That's why you don't get reverse DNS or whois. >> It's why I'd really like to revisit ULA-C, but I'm mostly alone in thi= s view. >=20 > no you're not alone there, I'm in on it to. Sixxs showed us how easy > it could be done. The framework don't have to be that complicated to > describe either but we'll see. It still baffles me why anyone would think this is useful. For any of the= use cases for ULAs, what do I gain by registering the prefix? Brian From nobody Mon Jun 6 13:31:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1763912D50D for ; Mon, 6 Jun 2016 13:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 YjWFz1BfWF6a for ; Mon, 6 Jun 2016 13:31:50 -0700 (PDT) Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C784912D57B for ; Mon, 6 Jun 2016 13:31:49 -0700 (PDT) X-MDAV-Processed: mail.consulintel.com, Mon, 06 Jun 2016 22:31:47 +0200 Received: from [10.10.10.99] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000586596.msg for ; Mon, 06 Jun 2016 22:31:46 +0200 X-Spam-Processed: mail.consulintel.com, Mon, 06 Jun 2016 22:31:46 +0200 (not processed: spam filter heuristic analysis disabled) X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Return-Path: prvs=196586e86e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Mon, 06 Jun 2016 22:31:43 +0200 Subject: Re: ULA-C [was: Testing ULAness] From: JORDI PALET MARTINEZ To: IETF IPv6 Mailing List Message-ID: <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> Thread-Topic: ULA-C [was: Testing ULAness] References: <22582.1465221680@obiwan.sandelman.ca> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:31:53 -0000 Making sure is not =E2=80=9Cjust=E2=80=9D probabilistically unique? The question may be should be =E2=80=9Care there use cases for ULA?=E2=80=9D. If there = are use cases (for example) which really make sense to use ULA inside organi= zations and those organizations one day are involved in a merge process, ULA= -C will make sure there is not a clash. I don=E2=80=99t recall if there is any good document about those possible use cas= es, may be we need to figure that before agreeing in the need for ULA-C (or = even ULA at all ;-) ! ). Regards, Jordi -----Mensaje original----- De: ipv6 en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: lunes, 6 de junio de 2016, 22:25 Para: Roger J=C3=B8rgensen , Michael Richardson CC: IETF IPv6 Mailing List Asunto: ULA-C [was: Testing ULAness] >Changing to the subject to what you are talking about... > >On 07/06/2016 05:41, Roger J=C3=B8rgensen wrote: >> On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson >> wrote: >> >>> That's why you don't get reverse DNS or whois. >>> It's why I'd really like to revisit ULA-C, but I'm mostly alone in this= view. >>=20 >> no you're not alone there, I'm in on it to. Sixxs showed us how easy >> it could be done. The framework don't have to be that complicated to >> describe either but we'll see. > >It still baffles me why anyone would think this is useful. For any of the >use cases for ULAs, what do I gain by registering the prefix? > > Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From nobody Mon Jun 6 13:35:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB4F12B03F for ; Mon, 6 Jun 2016 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bRdXcmbsQZKr for ; Mon, 6 Jun 2016 13:35:40 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B55F12D18F for ; Mon, 6 Jun 2016 13:35:40 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id y124so10510367pfy.0 for ; Mon, 06 Jun 2016 13:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+8/bfOiYRMHeRciSA5FsljQfhF8qszSk7RGSR84quuE=; b=DSy5s3/EfRhblw3kGn0cdZ9ASX7uPIlJTVZ4turDgny1x4ZEflMiAcklphPJkVz/L+ WPGNKQB9Im6U+LDVC9TD+2LhKDYvm1sYO9y4Wr/pxuXzrXT2/FU0odAXHeJA208qXhA1 1pQQdmoOBRaFufMx+knzgtpdV/s3lXWsMt9ScX0RRzRB8Nd0PK+ODcfPR4j9fnzYwNvt gJpNZuVU4rpLjpWoRIh/Ye3dYxk83yMwBle7MA7FYGiAx84ZQbQv4cwHS6py+LS4/41n M7PHF+SGTfrJGedsf22HBGr9FOSHVsPlmrNa3oV5/P9lA5sJIpn8Mp14HgeGRPnBQYO2 SndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+8/bfOiYRMHeRciSA5FsljQfhF8qszSk7RGSR84quuE=; b=KATQ4oRBXyoh4/N2xIGDvGXTS7/EKUnfUZfiaQPYOx1uBt2N2kth1hGywQbuWV9DQH SkZ6BuS7Fxr3r2ysMVUFYG6o01ZjLoI+CFULCUIRrpxdQxizhhkl2xFIj8AHph8wZIkB 1Jdznl2jfTXsyyGh9511rTIyqE3T4pewzm/K9hkCKZm4/jL2AK+fP7aiMoLk7uwV3Xjc npj6jEEgL3Mud9byfy3bE62WJDdFS6nuizRwQuFRz0XMfRVOuW+nd9j4c2Rsr3G3V1Ws T9AuzuoDmo5sUqZdPKx7xF9eMf1Q3Up5FsGJWIo2k0yo7gNvU9wt/tYLUT11+lbuBpxu zyGQ== X-Gm-Message-State: ALyK8tKIHRzl2BnnBGMBc4I7G+aRLfNUmXA2tyRUI9HyEf+M2SWWssgE0haHnzB8RX38Tw== X-Received: by 10.98.13.154 with SMTP id 26mr1313726pfn.35.1465245339488; Mon, 06 Jun 2016 13:35:39 -0700 (PDT) Received: from ?IPv6:2406:e007:77b7:1:7973:6585:6164:dd17? ([2406:e007:77b7:1:7973:6585:6164:dd17]) by smtp.gmail.com with ESMTPSA id f191sm29737422pfa.26.2016.06.06.13.35.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 13:35:38 -0700 (PDT) Subject: Re: Testing ULAness To: Kerry Lynn , Lemon Ted References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <301d0828-14d8-48a7-ccbc-28d965cb340f@gmail.com> Date: Tue, 7 Jun 2016 08:35:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:35:42 -0000 On 07/06/2016 03:28, Kerry Lynn wrote: > On Sun, Jun 5, 2016 at 4:50 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> >> >> RFC4773: >>> 7. The registry will also note, for each designation, the intended >>> routing scope of the address, indicating whether the address is >>> intended to be routable only in scoped, local, or private >>> contexts, or whether the address prefix is intended to be routed >>> globally. >> >> Note that RFC4773 was obsoleted by RFC6890, so that's already a bug in the >> registry. >> This paragraph has been blown away. RFC6890 defines 'Global' in the same >> words used >> in the registry, and I believe those words are inconsistent with the IPv6 >> RFCs. >> >> It appears the idea of making "global" N/A for ULAs was suggested by Errata > ID 3879 but rejected: https://www.rfc-editor.org/errata_search.php?rfc=6890 > I haven't found a discussion thread on the topic; perhaps Ted can provide > additional insight. The problem is deeper, I think: we are using "global" to mean two different things. There probably isn't a binary fix to that problem. It was correct to reject the erratum for the meaning of 'global' used in RFC6890, but that is different from the meaning in RFC4193. I wouldn't care if it didn't have practical implications. Brian From nobody Mon Jun 6 13:38:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09112B03F for ; Mon, 6 Jun 2016 13:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2k_wNY3N1-q3 for ; Mon, 6 Jun 2016 13:37:56 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B5B12D54F for ; Mon, 6 Jun 2016 13:37:56 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-3e-5755d5f54478 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 79.4D.09012.5F5D5575; Mon, 6 Jun 2016 21:58:46 +0200 (CEST) Received: from EUSAAMB108.ericsson.se ([147.117.188.125]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Mon, 6 Jun 2016 16:37:55 -0400 From: Suresh Krishnan To: Brian E Carpenter , Lorenzo Colitti Subject: Re: Testing ULAness Thread-Topic: Testing ULAness Thread-Index: AQHRvuP3tmwEQYSikE2mJWJY0O0ddg== Date: Mon, 6 Jun 2016 20:37:53 +0000 Message-ID: References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPrO63q6HhBr1beCzaLu5jsnh59j2T xfrT7xgdmD12zrrL7rFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyZq3ezVKwkatiW8cBtgbG 7RxdjJwcEgImEhNeXmCDsMUkLtxbD2RzcQgJHGWU+Ph3MROEs4xRYsn3XawgVWxAHRt2fmYC sUUEoiU2fbjJCGIzC2hJrH79H6xGWEBGovfdMVaIGlmJj9PusEPYehInbt5nAbFZBFQkds84 CFbDK+Arce7xUbArhAS+M0lcnSgKYjMCXfT91BomiPniEreezGeCuFRAYsme88wQtqjEy8f/ WCFsJYmPv+ezQ9TrSCzY/YkNwtaWWLbwNTPELkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFl FSNHaXFBTm66kcEmRmCEHJNg093BeH+65yFGAQ5GJR7eBRkh4UKsiWXFlbmHGCU4mJVEeJ/e DA0X4k1JrKxKLcqPLyrNSS0+xCjNwaIkziv2SDFcSCA9sSQ1OzW1ILUIJsvEwSnVwLjN90uS rbwSq5J99uGj5psPVdr0LOKQ+7tNQOpynMgCyytHjXdnhootm8Ic97Xj6gLeS4mKt3/P/Vr2 YPrUvtKothd9ThPUKz5deNB0VDrzbdIijel6qxz+/r52M7DudHbWRyPezOTzX01PNNh1z11V Uea9/EfeFAFLEX4Xmb9vLv8LDapNEVdiKc5INNRiLipOBAAtmxOtjAIAAA== Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:37:58 -0000 Hi Brian,=0A= =0A= On 06/05/2016 03:50 PM, Brian E Carpenter wrote:=0A= > On 05/06/2016 17:44, Lorenzo Colitti wrote:=0A= >> On 5 Jun 2016 2:34 pm, "Brian E Carpenter" = =0A= >> wrote:=0A= >>>>> o Global - A boolean value indicating whether an IP datagram whose=0A= >>>>> destination address is drawn from the allocated special-purpose addre= ss=0A= >>>>> block is forwardable beyond a specified administrative domain.=0A= >>>>> =3D=3D=3D=3D=3D=0A= >>>>>=0A= >>>>> Doesn't seem that obvious to me that ULAs are forwardable on the=0A= >> internet.=0A= >>>=0A= >>> Doesn't seem to me that this is the agreed definition of global scope f= or=0A= >> IPv6.=0A= >>=0A= >> But it *is* the definition of global used by the registry. I think if yo= u=0A= >> want the registry to say that ULA is global, the definition needs to cha= nge=0A= >> first.=0A= >=0A= > I agree. And of course the appropriate definition may be different for IP= v4.=0A= >=0A= > Maybe I should bring this up in Intarea.=0A= =0A= Yes. That would be a good venue for this discussion (as are 6man and v6ops)= . =0A= I am also a bit uncomfortable with this inconsistency between the registry = =0A= and the protocol. It would be worthwhile getting this resolved.=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Mon Jun 6 13:41:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD5012B03F for ; Mon, 6 Jun 2016 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WJlcy4X9xSQq for ; Mon, 6 Jun 2016 13:41:35 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950E912D5B4 for ; Mon, 6 Jun 2016 13:41:35 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id g64so70203563pfb.2 for ; Mon, 06 Jun 2016 13:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+MGcVZH+7xPY/eDNtjv8Mo4oI/g8pPypcytJcto6l3o=; b=ys7kglG6EUGA6R12cXtiZDHIfJlmr8HYLIFDNM0dypq2nVJL55qOc/JhRwnhSfxzWu FdqeWhrykjXt4QMZLsuyAN9yoPDUe5v0OVAAnFc1dnxcIJsTVRJi0WpMw/B80WiBzecv mLt3d8QPJGLtYLLgLAg5+ZckfLjGb1QGtDOaMJHEDUC6dc3bXZGVL6WgHvuXQkHGe5Cs yue0Dunt+IVUFBeuMNf9kVDAftiJ3wveOS6t7Zm/V7b1R7eWrdMek/mssWOzVw+UDkXY 8D+AVMXrLZjFLpcXtPgYEmp4pEUGiSSH9s7fZ4Wcv1uLyRk72ygFlkgZQfFMRB/PCQoJ ZZkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+MGcVZH+7xPY/eDNtjv8Mo4oI/g8pPypcytJcto6l3o=; b=Zf0yxTTP9H9LYVDjxYTPsiQXUrRUYO+N8omEqODDjfUn5M33H+n0e7PHhe1gF5xZAD H8JG3alIKNyyEJx8U0kok69SFqwicd4qs1vtPMys//InbhjHM8CUiHfKeJF/eQ9tFGsi E0FbY+u3nJLxEE5l0q2iL89550clRwQOj3+nsBvFkZ1EA1tVqaMt3GBguMYgietTVxTW Npnkz7w7Hn1rwtSQ9QxTMLlySvnYAq/MfeLtjIOIwAwKG5WwuH5Yz/CoJxV92M2HlqQX EjgMerKiL5/jzTGrO7W8vmCuvcFEuOtb469bQIOpvl7b3JbpvwzFdSfntTlf58MVXBKH CUyA== X-Gm-Message-State: ALyK8tJMKfVhyy/N58N2V5KaK6nYCumiQpjmGQ2SHenNV5IJ+AafKuLyeW6Nb/bZSd0oAg== X-Received: by 10.98.14.155 with SMTP id 27mr11875328pfo.160.1465245695146; Mon, 06 Jun 2016 13:41:35 -0700 (PDT) Received: from ?IPv6:2406:e007:77b7:1:7973:6585:6164:dd17? ([2406:e007:77b7:1:7973:6585:6164:dd17]) by smtp.gmail.com with ESMTPSA id g82sm29756066pfj.22.2016.06.06.13.41.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 13:41:34 -0700 (PDT) Subject: Re: ULA-C [was: Testing ULAness] To: jordi.palet@consulintel.es, IETF IPv6 Mailing List References: <22582.1465221680@obiwan.sandelman.ca> <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0ac9e231-d25a-b503-8a3c-41ba6086eb2f@gmail.com> Date: Tue, 7 Jun 2016 08:41:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:41:37 -0000 On 07/06/2016 08:31, JORDI PALET MARTINEZ wrote: > Making sure is not =E2=80=9Cjust=E2=80=9D probabilistically unique? Right. I don't see the point. In the case that two networks merge, checki= ng for clashing prefixes would be a tiny part of the overall problem. > The question may be should be =E2=80=9Care there use cases for ULA?=E2=80= =9D.=20 draft-ietf-v6ops-ula-usage-considerations We're strongly recommending ULAs in Anima, for example. Brian > If there are use cases (for example) which really make sense to use ULA= inside organizations and those organizations one day are involved in a merge process, ULA-C will make sure there is not a clash. >=20 > I don=E2=80=99t recall if there is any good document about those possib= le use cases, may be we need to figure that before agreeing in the need f= or ULA-C (or even ULA at all ;-) ! ). >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: ipv6 en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: lunes, 6 de junio de 2016, 22:25 > Para: Roger J=C3=B8rgensen , Michael Richardson > CC: IETF IPv6 Mailing List > Asunto: ULA-C [was: Testing ULAness] >=20 >> Changing to the subject to what you are talking about... >> >> On 07/06/2016 05:41, Roger J=C3=B8rgensen wrote: >>> On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson >>> wrote: >>> >>>> That's why you don't get reverse DNS or whois. >>>> It's why I'd really like to revisit ULA-C, but I'm mostly alone in t= his view. >>> >>> no you're not alone there, I'm in on it to. Sixxs showed us how easy >>> it could be done. The framework don't have to be that complicated to >>> describe either but we'll see. >> >> It still baffles me why anyone would think this is useful. For any of = the >> use cases for ULAs, what do I gain by registering the prefix? >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Jun 6 14:26:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997EB12B00D for ; Mon, 6 Jun 2016 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2GHWKgXqdxG6 for ; Mon, 6 Jun 2016 14:26:40 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 3194212D536 for ; Mon, 6 Jun 2016 14:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u56LQdah060438; Mon, 6 Jun 2016 14:26:39 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u56LQZ3C060411 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 6 Jun 2016 14:26:35 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Jun 2016 14:26:34 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Mon, 6 Jun 2016 14:26:34 -0700 From: "Manfredi, Albert E" To: "jordi.palet@consulintel.es" , "IETF IPv6 Mailing List" Subject: RE: ULA-C [was: Testing ULAness] Thread-Topic: ULA-C [was: Testing ULAness] Thread-Index: AQHRwDGnd8oS3NkuiEuVdX5/1nuzxZ/dWdWA//+WbUA= Date: Mon, 6 Jun 2016 21:26:34 +0000 Message-ID: <579d0624813946638a162003ec38e010@XCH15-06-11.nw.nos.boeing.com> References: <22582.1465221680@obiwan.sandelman.ca> <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> In-Reply-To: <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:26:41 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpP UkRJIFBBTEVUIE1BUlRJTkVaDQoNCj4gVGhlIHF1ZXN0aW9uIG1heSBiZSBzaG91bGQgYmUg4oCc YXJlIHRoZXJlIHVzZSBjYXNlcyBmb3IgVUxBP+KAnS4gSWYgdGhlcmUNCj4gYXJlIHVzZSBjYXNl cyAoZm9yIGV4YW1wbGUpIHdoaWNoIHJlYWxseSBtYWtlIHNlbnNlIHRvIHVzZSBVTEEgaW5zaWRl DQo+IG9yZ2FuaXphdGlvbnMgYW5kIHRob3NlIG9yZ2FuaXphdGlvbnMgb25lIGRheSBhcmUgaW52 b2x2ZWQgaW4gYSBtZXJnZQ0KPiBwcm9jZXNzLCBVTEEtQyB3aWxsIG1ha2Ugc3VyZSB0aGVyZSBp cyBub3QgYSBjbGFzaC4NCg0KWWVzLCB0aGVyZSBhcmUgdXNlIGNhc2VzIGZvciBVTEFzLCBJTU8u IEFuZCBteSBpZGVhIG9uIGludHJhLW9yZ2FuaXphdGlvbmFsIHVuaXF1ZW5lc3Mgd291bGQgYmUs IGJ5IGFsbCBtZWFucywgbGV0IGVhY2ggb3JnYW5pemF0aW9uIHRha2UgY2FyZSBvZiB0aGF0IGFz cGVjdCBvbiB0aGVpciBvd24uDQoNClRoZSBuaWNlIHRoaW5nIGFib3V0IFVMQXMsIGFuZCBlcXVh bGx5IGFib3V0IElQdjQgcHJpdmF0ZSBhZGRyZXNzIGJsb2NrcywgaXMgdGhhdCBhbiBvcmdhbml6 YXRpb24gY2FuIGFyY2hpdGVjdCB0aGVpciBuZXR3b3JrIHRvIGJlc3Qgc3VpdCB0aGVpciBzcGVj aWZpYyBuZWVkcywgd2l0aG91dCBpbnZvbHZpbmcgYW55IElQIGFkZHJlc3MgcmVnaXN0cnksIHdo ZW4gdGhlIHNlcnZpY2VzIG9mIGEgcmVnaXN0cnkgYXJlIG5vdCBuZWNlc3NhcnkuIElmIHdlIGFs bG93IFVMQSBwcmVmaXhlcyB0byBiZSByZWdpc3RlcmVkLCB3ZSdkIGJlIGNyZWF0aW5nIGEgcmVx dWlyZW1lbnQgdG8gY2hlY2sgd2hldGhlciBteSBVTEEgcHJlZml4IHNjaGVtZSBjb25mbGljdHMg d2l0aCBzb21lb25lIGVsc2UncyBpbnRlcm5hbCBuZXR3b3JrIFVMQSBwcmVmaXggc2NoZW1lLiBX aGljaCBpcyBqdXN0IGFib3V0IHRoZSBzYW1lIGFzIHVzaW5nIGdsb2JhbCBhZGRyZXNzZXMuDQoN CkJlcnQNCg0K From nobody Mon Jun 6 14:43:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637E912D944 for ; Mon, 6 Jun 2016 14:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 mOwC7W6IUTXC for ; Mon, 6 Jun 2016 14:43:17 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5046F12D943 for ; Mon, 6 Jun 2016 14:43:17 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id z189so55007718itg.0 for ; Mon, 06 Jun 2016 14:43:17 -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; bh=dqv/ZtmvKLpI3gV0ixgPIZXpFSpqKWOCNlbJPiV1Kx0=; b=JoT4UsIyloSDGLp9xz6HUZAEvA8SLdutWttzalvtr/6GGVh8ERpCLMDsJmelkV5wcr 4nSKBCLL5DVl1SkuJdDFpt1HepQDosJh79FbMxqJ0/BcDH7/jV+wFC7/NZ/nUg2hRal7 NT4A34nP/3s1ckkqWTnGkCp2wzdNIddmHY3+W7uv6G6FX9BVGYfoxzNd2FmawJ2Flzxq CN+jXd+j5oMGmQEUByzYQGBpscjbhHddcyteRvKz/lA9dLh+yP7AhwPLVqBYT12aN9D5 jp8ZTjQMALgSMag6amj6w+Er+cIg5bayjfVYuV5SYV3tpIqJZDSxAO8gphKHkpGhu3dQ r9lg== 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; bh=dqv/ZtmvKLpI3gV0ixgPIZXpFSpqKWOCNlbJPiV1Kx0=; b=ErP3WPFJBhJcpKT/hS1V/G9ZT5eJrGdOqk/Qfvij83byRBZyYggRWsfkQNHv6FmDyi 6eprJ6Aun+1rgzafncmfNEZl2Xihk4rIkIjp2f4OHEvqjI1WLDzdfzoOASRn+oKL8kWS ecHwhPEsiNQE9vsu2HcvLU7oGr7hC6eUsK2auaqUuAnZ85kFGu021FiscvWGaUP7mgln ciONNpgl0ZneypucS383dlUn19IwhZY6A8/xkzWzbapb3ULPpM8JEctJwTX3suHxtN50 yfRHuVFyE5GM14ATfgj+8BZYK5WA5RegBl4sahIWvgBjctbRf563XGQbvp10CWr+WMX1 jgTQ== X-Gm-Message-State: ALyK8tKdd3ZUYWrfYbilh7aXCNiVAlMIdgShIhGBlF4F10EPkThdx3ihgfCwOkoi8+7q5j5faT+EuvoW8xXn6zNg X-Received: by 10.36.184.130 with SMTP id m124mr1144464ite.95.1465249396529; Mon, 06 Jun 2016 14:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.68.169 with HTTP; Mon, 6 Jun 2016 14:42:56 -0700 (PDT) In-Reply-To: References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> From: Erik Kline Date: Tue, 7 Jun 2016 06:42:56 +0900 Message-ID: Subject: Re: Testing ULAness To: Suresh Krishnan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:43:19 -0000 On 7 June 2016 at 05:37, Suresh Krishnan wrote: > Hi Brian, > > On 06/05/2016 03:50 PM, Brian E Carpenter wrote: >> On 05/06/2016 17:44, Lorenzo Colitti wrote: >>> On 5 Jun 2016 2:34 pm, "Brian E Carpenter" >>> wrote: >>>>>> o Global - A boolean value indicating whether an IP datagram whose >>>>>> destination address is drawn from the allocated special-purpose address >>>>>> block is forwardable beyond a specified administrative domain. >>>>>> ===== >>>>>> >>>>>> Doesn't seem that obvious to me that ULAs are forwardable on the >>> internet. >>>> >>>> Doesn't seem to me that this is the agreed definition of global scope for >>> IPv6. >>> >>> But it *is* the definition of global used by the registry. I think if you >>> want the registry to say that ULA is global, the definition needs to change >>> first. >> >> I agree. And of course the appropriate definition may be different for IPv4. >> >> Maybe I should bring this up in Intarea. > > Yes. That would be a good venue for this discussion (as are 6man and v6ops). > I am also a bit uncomfortable with this inconsistency between the registry > and the protocol. It would be worthwhile getting this resolved. In some ways this seems like he ongoing difference between "addressing" and "routing". A "global scope address" is not the same as a "globally routable address". Still, I agree it would be best to be maximally precise wherever the word "global" is used. From nobody Mon Jun 6 14:51:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B6C12D18D for ; Mon, 6 Jun 2016 14:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu 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 A2wjPzjnYs4G for ; Mon, 6 Jun 2016 14:51:53 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 2BC7112D0AF for ; Mon, 6 Jun 2016 14:51:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 6B7D6946 for ; Mon, 6 Jun 2016 21:51:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfVt4xPLy7-M for ; Mon, 6 Jun 2016 16:51:52 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 3A59578D for ; Mon, 6 Jun 2016 16:51:52 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id w185so432983788vkf.3 for ; Mon, 06 Jun 2016 14:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=y//i6v6VwWRhvUQq0Lh/Qz5Z7EPY5URYyNlMfr2llVQ=; b=dErLt7s0ZY3PKj18o0Ymg5kc1mUuIA5a+FGfs9f5X4uP+Ybbm9OJCrtug8caeY9FIS MJhciIfmk5de/WHhaWbiq7pDbOa53qdG2EeO87Ohx5v9moLOA131ZpeLrm4OKq1LZHZr hzFQjBDjDCerT4a5SPNBLzz4xGuKqenHTe/T0= 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=y//i6v6VwWRhvUQq0Lh/Qz5Z7EPY5URYyNlMfr2llVQ=; b=Sn4TP4nn31pqii9Qeq/C625XY9n071R7t7jxgRi1+5GCAJrTnLx1hhCcFYeA0Zlebb GPG4653laypBr7s6Dru6E+fHA96UFlYvqhscH1wcwNPZjXdla7cE5hv+aqrJHNoVN/Bm 2CE7QAeuV5YXckfUhAYQMi4Dqa5Q8K9//s2X0BhHm/mX0/hOfcC4w4A175q054mRlL/R zmFh5oP0glNsFEx4AQrh3zCyi/FWBjpdqR3LMuAX9njZAk9PqIaaTxgX2CrDGvZBkHM+ p+2g0q8pBJKtKpjCDZ/nYPeUsBaRHQYtms4+y+mCsi7Lk5Jbt8MeFoZyuJ5ROw6+LpQ0 4pFQ== X-Gm-Message-State: ALyK8tJb9EFf+qksV0ojfEo6VLUhPQPqLc0DpTb+KfuiZl8cvOc56uDZor8o1jGqQbTtwO3lSLjGtHBi2JYK2k+I+d2OD5aPQjnyqCAbNgHm+TuaQyoHgkwl8WA5CulNeDv6NmUNuW7BGCpCNsk= X-Received: by 10.140.34.133 with SMTP id l5mr17237997qgl.28.1465249911391; Mon, 06 Jun 2016 14:51:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.34.133 with SMTP id l5mr17237986qgl.28.1465249911191; Mon, 06 Jun 2016 14:51:51 -0700 (PDT) Received: by 10.237.36.213 with HTTP; Mon, 6 Jun 2016 14:51:51 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> Date: Mon, 6 Jun 2016 16:51:51 -0500 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] From: David Farmer To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:51:55 -0000 On Mon, Jun 6, 2016 at 3:25 PM, Brian E Carpenter wrote: > Changing to the subject to what you are talking about... > > On 07/06/2016 05:41, Roger J=C3=B8rgensen wrote: >> On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson >> wrote: >> >>> That's why you don't get reverse DNS or whois. >>> It's why I'd really like to revisit ULA-C, but I'm mostly alone in this= view. >> >> no you're not alone there, I'm in on it to. Sixxs showed us how easy >> it could be done. The framework don't have to be that complicated to >> describe either but we'll see. > > It still baffles me why anyone would think this is useful. For any of the > use cases for ULAs, what do I gain by registering the prefix? > > Brian Just having a registered prefix like Sixxs does, I don't find useful either. However, registered uniqueness, with functioning reverse-DNS and default policy of non-routed of ULA-Central could provide, I would find interesting. That said, the need for reverse-DNS can be part of a justification for PI (an end user assignment in ARIN parlance), at least within the ARIN region. So, I don't see a desperate need for ULA-C, but I'm certainly not opposed to ULA-C and would support work on it. I'll note when dealing with people with security hats on, the default non-routed policy of ULA-C (or ULA-Random for that matter) has it's advantages over PI. It seems to give them an extra-warm fuzzy, that if we leak packets people at the other end, or along the way, "might" discard them. :) --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Mon Jun 6 15:06:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF312D94E for ; Mon, 6 Jun 2016 15:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu 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 Hu8mFRWwUDsA for ; Mon, 6 Jun 2016 15:06:00 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 704AF12D51D for ; Mon, 6 Jun 2016 15:06:00 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id C41E27CB for ; Mon, 6 Jun 2016 22:05:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Bmq13rEMoJ for ; Mon, 6 Jun 2016 17:05:59 -0500 (CDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.161.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 9B4953F9 for ; Mon, 6 Jun 2016 17:05:59 -0500 (CDT) Received: by mail-yw0-f200.google.com with SMTP id y6so433394836ywe.0 for ; Mon, 06 Jun 2016 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qrFoI4whmcB7Lwd3HJFV9LvdWLokqboHCq17nYoqStY=; b=KoDhQMMnXBTBD1tAwKp4C09P0tiq+EFfbjXYvyEY/NPMNlV4VtfH+eYWHHkDVxT2II CfpWqn4Hfmg/17XChcXPv7kxxc+nM+++uP9sHy7YxYO0e/hG3Fp/8ZuA1k+WouceAjqX k01pJG0encCXGI+JtX17TuiZJF/QebzQr6b24= 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:date :message-id:subject:from:to:cc; bh=qrFoI4whmcB7Lwd3HJFV9LvdWLokqboHCq17nYoqStY=; b=YC+RIMjb7zWDvrKDk1wumRZmk1589aWHXxSsl+S1Hb4fCg802hUuucvXBa2j+YtWFr XKEtszIEWYt1gk7xyWfF8XzeFKTiXN1l0nnNVy19zYAf13xLepyRaONU89TxcnbIKX4E oMR6ls3Lk/YbneCWvr4K6/pdfDk7mt5v0STVoXynCh+n5PS8alGnlJLlFNVY/UYydJ5W 5gBPwc4Wql2GVvMrOa30QmTpPj7ooesVPVRGgqFaZ3K9AERlqj91h3PVLXCvmGmPBMy5 mrc/WBu22m0APP0L60guc3XtGjD69IPqeb6m0Tnvke7ontlDL+KxFteltTL6f/7Vodrf j4aA== X-Gm-Message-State: ALyK8tKD2sHXun3goQP5TF0sexAIqRtbnO4qh2CSTvZFwBgubXuGizvE7afVr/h/S0T8EsK4FXOBOfbTWghBy6Zy/9cgrE0bYLyJc49dggLwhamfstYB9D/XkzhOs1A29n197hiyTQG9AqMlmDY= X-Received: by 10.140.168.2 with SMTP id o2mr7221846qho.13.1465250759119; Mon, 06 Jun 2016 15:05:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.168.2 with SMTP id o2mr7221823qho.13.1465250758894; Mon, 06 Jun 2016 15:05:58 -0700 (PDT) Received: by 10.237.36.213 with HTTP; Mon, 6 Jun 2016 15:05:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jun 2016 17:05:58 -0500 Message-ID: Subject: Re: Testing ULAness From: David Farmer To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:06:02 -0000 On Sat, Jun 4, 2016 at 11:42 PM, Lorenzo Colitti wrote: > On 5 Jun 2016 1:37 pm, "Brian E Carpenter" > wrote: >> The IANA IPv6 Special-Purpose Address Registry* has a column marked >> "Global". >> For fc00::/7 (ULA) this is set to "False". >> >> That is surely wrong. > > Is it? > > ===== > o Global - A boolean value indicating whether an IP datagram whose > destination address is drawn from the allocated special-purpose address > block is forwardable beyond a specified administrative domain. > ===== > > Doesn't seem that obvious to me that ULAs are forwardable on the internet. But there is nothing explicitly prohibiting them being forwarded (routed) out of an administrative domain either. That might be the default expectation most people have, but that's all it is a default expectation, it's not an actual requirement. So, I can argue both sides of this one. Which tells me which ever way it ends up there should be a footnote pointing to more details. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From nobody Mon Jun 6 17:51:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D6D12B037 for ; Mon, 6 Jun 2016 17:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 4NOwr_NIsOh6 for ; Mon, 6 Jun 2016 17:51:37 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D836512B014 for ; Mon, 6 Jun 2016 17:51:36 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id c127so156129024ywb.1 for ; Mon, 06 Jun 2016 17:51:36 -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; bh=f2wPQcqEceejoLCzwu5PFUXMFUmL4bEM8/0fGAIxlSU=; b=jjWTWW262/LiXf/98IAk+zG+8ivi9EQfGsbFW3OByEhv1zuT+ZLNmnMB96s8M80YMb 9O6XENX+/6m1+a/WlqjWBNpK3CmtXSJCZTVaFUBhn9Td8CtRvHoHUo3KM2i0qY3WRT5S tlgxyX+hQKdEbeU9jOzRBCmVm+MpGwOTH7nEDSHobT152NO9+lkI7pZFLhUpMSB6gUrK 8RUKzTfNHmfz8XuwNbVdM0y8gIXzmQNd+MnD7tKcOgXLRq7QbWgeDyLc2kHNo2Wae+Qf HTfWyC5aMxuM5ob1e//hMnhbjUsJTT27hjBb/vwL3bVt1yvA7xhxtDVqk7zXJQRBztIZ H2WQ== 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; bh=f2wPQcqEceejoLCzwu5PFUXMFUmL4bEM8/0fGAIxlSU=; b=Vk75lKEyrUpNAHCLkBc3BXjWN9WMU74Kz9I5th/Q5ixnBIEVucc+YRDk6j42AGInTt nmPiprnOHZujvphupHxESHTWK7zxj+hwcc8gFBASfE5GR1cXG45FO+tzSuNvelYmt6jW I6Etx6GMViXtZQ9RMpvl+KQrdQobn9cEELDZl3eBIlSKq0XMVW8j+y6PZtuAqONbKV8U FrYWHhuehkCaUCsyFquK6sgkvvUtYquTDBC36/kSavvbLQA9D84i1DtelngwhwfBRmtE aAWfV+o1DWYQKKvXDlt/gWZp8kjSPqmweQcL3tU/BYi2KHHya4RrgXmElLWHatM3KNJg uE6w== X-Gm-Message-State: ALyK8tIreRQH1Nv3lCKwZC9H2bTxTretrNJpzLCyrb87F8U0Uoc0L/y9CPyP7YK+oarAfB7B0Uj1faNORwITj63D X-Received: by 10.37.76.133 with SMTP id z127mr12732734yba.152.1465260695988; Mon, 06 Jun 2016 17:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Mon, 6 Jun 2016 17:51:16 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Jun 2016 09:51:16 +0900 Message-ID: Subject: Re: Testing ULAness To: David Farmer Content-Type: multipart/alternative; boundary=001a113e55264a68f50534a5976d Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 00:51:39 -0000 --001a113e55264a68f50534a5976d Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 7:05 AM, David Farmer wrote: > But there is nothing explicitly prohibiting them being forwarded > (routed) out of an administrative domain either. RFC 4193 says that they should not be forwarded out of a site: Site border routers and firewalls should be configured to not forward any packets with Local IPv6 source or destination addresses outside of the site, unless they have been explicitly configured with routing information about specific /48 or longer Local IPv6 prefixes. ... Routers that maintain peering arrangements between Autonomous Systems throughout the Internet should obey the recommendations for site border routers, unless configured otherwise. and this text in RFC 7084 says that home routers MUST NOT forward ULAs out, either: ULA-4: By default, the IPv6 CE router MUST act as a site border router according to Section 4.3 of [RFC4193] and filter packets with local IPv6 source or destination addresses accordingly. I think the registry is correct in saying that these addresses are not global according to its definition of global. --001a113e55264a68f50534a5976d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 7, 2016 at 7:05 AM, David Farmer <farmer@umn.edu> wrote:
But there is nothing expl= icitly prohibiting them being forwarded
(routed) out of an administrative domain either.

RFC 4193 says that they should not be forwarded out of a site:

=C2=A0 =C2=A0Site border routers and firew= alls should be configured to not forward
=C2=A0 =C2=A0any packets= with Local IPv6 source or destination addresses outside
=C2=A0 = =C2=A0of the site, unless they have been explicitly configured with routing=
=C2=A0 =C2=A0information about specific /48 or longer Local IPv6= prefixes.=C2=A0
...
=C2=A0 =C2=A0Rout= ers that maintain peering arrangements between Autonomous Systems
=C2=A0 =C2=A0throughout the Internet should obey the recommendations for s= ite
=C2=A0 =C2=A0border routers, unless configured otherwise.

and this text in RFC 7084 says that home router= s MUST NOT forward ULAs out, either:

=C2=A0 = =C2=A0ULA-4: =C2=A0By default, the IPv6 CE router MUST act as a site border=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0router according to Sec= tion 4.3 of [RFC4193] and filter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0packets with local IPv6 source or destination addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accordingly.=C2=A0

=
I think the registry is correct in saying that these addresses a= re not global according to its definition of global.
--001a113e55264a68f50534a5976d-- From nobody Mon Jun 6 18:01:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7612D966 for ; Mon, 6 Jun 2016 18:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 bXjIOMsr1Q0z for ; Mon, 6 Jun 2016 18:01:48 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C9A12B014 for ; Mon, 6 Jun 2016 18:01:47 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h19so156516979ywc.0 for ; Mon, 06 Jun 2016 18:01:47 -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; bh=y63VgkXC/I+bZx0ZlCOsTwwZnSMFVpKOI9px8MYWP2Y=; b=W9zHnAGZP/UzjEWnog+jjlncrGuxRbdcz8QKt9dsXGdV33I7sQGIDc3fWupFOGGeJs l5vzad/edg6A2rOBlXaWymD1oidel1jd0qq1PtxxwzbHvEldciQHECoHmCYVgX+AogsI F4i/9d1YklgBBkO5fYQq+/DRt0h+O+ByKG6OgHveoWVPh0t7pxVZPMiFh9TXTyrv00za 8uDxoARk8FqVxwNMdPEk9uj8/VcOeRTpg4OERDItIfjBb8Jk5s0a7PHyu7SeMQcwwcPG qCUNRe2Us3fqVCEYcJKO8AwfQuvBmujrXOUBHZv/t1Xaz604TiKYZkmYC2BoiSTKfOTt aHiQ== 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; bh=y63VgkXC/I+bZx0ZlCOsTwwZnSMFVpKOI9px8MYWP2Y=; b=fueehQ7dSL2q5y4S/Z5MWQT7oPc6uwpllMo1wErP10aueSK49Sjt1fVBrz6xWckCO7 nknSfrEAHVAhI9LoOR7irTGGIfkbAsFtbPP4G/mzzUAYyzXPPjPxkaZ+4MYuX0TREMec KTRoRVOmxYtSsAZ9ah4QCIQsJLkwnyJsb8VhzXCF2pixHhqIwoZv+WHzpdnOAetZI3tR W31mRgYG8+ngn+0t7MMj0IUv8xGEz6SrUdGuQbXyKNuI74EkimAX3F1EtUlE58ZiIdvP N1AjYdtE535W7BO9Si4T34IdR1Kn7de1OETRzbnhHkFEeWi53n8qYNEfq7pdvtLLojPm vCVQ== X-Gm-Message-State: ALyK8tIag2NC86C9TFG4aPKtSJV22toS9gvOI9+9DUe8/OWSaQZWedMAfcwdn1X0Xe2MqsLsswo8dX0ad4lYdS7C X-Received: by 10.129.82.214 with SMTP id g205mr14221272ywb.66.1465261306938; Mon, 06 Jun 2016 18:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Mon, 6 Jun 2016 18:01:27 -0700 (PDT) In-Reply-To: <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> From: Lorenzo Colitti Date: Tue, 7 Jun 2016 10:01:27 +0900 Message-ID: Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114dc694b47d930534a5bbdb Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 01:01:51 -0000 --001a114dc694b47d930534a5bbdb Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Taking the last question first, no, because when you bind a listening > socket to ::, > it appears to latch onto the stable address if there is one, Binding a listening socket to :: shouldn't attach to any address. The socket should accept connections that arrive at any address on the system. The address that is used for the connection is the one that the other side of the connection decides to connect to. --001a114dc694b47d930534a5bbdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
Taking t= he last question first, no, because when you bind a listening socket to ::,=
it appears to latch onto the stable address if there is one,

Binding a listening socket to :: shouldn't attach to = any address. The socket should accept connections that arrive at any addres= s on the system. The address that is used for the connection is the one tha= t the other side of the connection decides to connect to.
=
--001a114dc694b47d930534a5bbdb-- From nobody Mon Jun 6 18:28:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA612D746 for ; Mon, 6 Jun 2016 18:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dopk51FssHAk for ; Mon, 6 Jun 2016 18:27:58 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4CA12D151 for ; Mon, 6 Jun 2016 18:27:58 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c66so69567323vkb.3 for ; Mon, 06 Jun 2016 18:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7YoP5QwZSrkQT2LaoS0kjffpigMOTAHhlHfy/3janR8=; b=hdaVPBQpKFNjn8EwQ2bdgxoGloOqESuPvcBdEI+fV16N6dBQa+NqCqjtA13UH+P5P2 BIEIQHn40XSfc/3UnH84KYbbLjlIzzdbe0nZUMrrRndnWMcpqkfcs7Iap9diF1AGhOIA a6nj8gGv8wJoGvON6SvXtDnismqu2S0XbzUxhHZbbTA7+JiNzGdzJgbGri3wbOLsDfFv SD6NJhGQ9kpjChU+6z0kqjM/vmBFns7oWiRPymTu8c3UpJnf7UP6XlaazXhT+9yTKc8F wyT2GGI3a8+FRBBizcOACQzbDi8csOKFNbDon4bNj2rOpJi6ISyJgTyNNzBNOUAQp2ZQ xPRA== 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:date :message-id:subject:from:to:cc; bh=7YoP5QwZSrkQT2LaoS0kjffpigMOTAHhlHfy/3janR8=; b=T7Ln49j/0HKq86iKbxSLqVjIMmTrPASS7A31gnp8aaOc6vP3x/3XveYEW/Zxgocsk7 KkffPI4dGojdYbDHW3sH7ukWDEW3CIpySp1G+x/mDsYTtDDSY6dVUxZP6SbjYCeLt6uB zO3EbiPZy0x44ylhZMLX2Gj6xiM2/vt4zq9HS7Nc9lD+eFQFkUBSMVEJ6Ai1iLuZI29B HP5sIngtYet5vht04maSYsLyDooASxM79HZ2fVPI5y3KlpKvyCqtPDLHg2A7/bXdubaJ wEft0r3HL1Sg3IOd0t/1CoprKWQnlNKenyiPoCwRqSwqScNmpEhloHE6oOt0QmEzrAhQ HHlQ== X-Gm-Message-State: ALyK8tIdBtmWRmVh1RUfqzdy+WW01VwWCIi9slG8syTQR2OGgf10cxNSr6lP2v6JUgguAgTwE0nOz5fgQsLPjg== MIME-Version: 1.0 X-Received: by 10.31.197.132 with SMTP id v126mr9531694vkf.134.1465262877228; Mon, 06 Jun 2016 18:27:57 -0700 (PDT) Received: by 10.176.4.54 with HTTP; Mon, 6 Jun 2016 18:27:57 -0700 (PDT) Received: by 10.176.4.54 with HTTP; Mon, 6 Jun 2016 18:27:57 -0700 (PDT) In-Reply-To: References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> Date: Tue, 7 Jun 2016 11:27:57 +1000 Message-ID: Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt From: Mark Smith To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a114bcfc84cc6b40534a61958 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 01:28:00 -0000 --001a114bcfc84cc6b40534a61958 Content-Type: text/plain; charset=UTF-8 On 7 Jun 2016 10:32 AM, "Lorenzo Colitti" wrote: > > On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: >> >> Taking the last question first, no, because when you bind a listening socket to ::, >> it appears to latch onto the stable address if there is one, > > > Binding a listening socket to :: shouldn't attach to any address. The socket should accept connections that arrive at any address on the system. The address that is used for the connection is the one that the other side of the connection decides to connect to. > That's been my understanding (and experience I think, although it has been a while). Is it possible that the sockets interface in the language Brian is using (Python?) isn't quite providing the true sockets API? Regards, Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a114bcfc84cc6b40534a61958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 Jun 2016 10:32 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >>
>> Taking the last question first, no, because when you bind a listen= ing socket to ::,
>> it appears to latch onto the stable address if there is one,
>
>
> Binding a listening socket to :: shouldn't attach to any address. = The socket should accept connections that arrive at any address on the syst= em. The address that is used for the connection is the one that the other s= ide of the connection decides to connect to.
>

That's been my understanding (and experience I think, al= though it has been a while).

Is it possible that the sockets interface in the language Br= ian is using (Python?) isn't quite providing the true sockets API?

Regards,
Mark.

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

--001a114bcfc84cc6b40534a61958-- From nobody Mon Jun 6 18:36:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334D212D0A4 for ; Mon, 6 Jun 2016 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KBuVMaO9DyoC for ; Mon, 6 Jun 2016 18:36:37 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3C41200A0 for ; Mon, 6 Jun 2016 18:36:36 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id g64so72276323pfb.2 for ; Mon, 06 Jun 2016 18:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=i3UIL2czVyL0vUsqvsQnlYD0MXGhUKtqu520A63K5FA=; b=EH1YZuFQ5iwj+wz7PKxL721q5b+NMhr0y2+7yZSFPbO18w5fqqGs57UaZre8fM4V5x 2gyakFf+Vm9xDJ6lRHNTlxJXdGOGBW8euXpwqM5AXKzqV476GaVn8gR/YO6TuiFkh413 WyThAMdqJP3KsKFGZgJfsCYrkJZknfb54k1ZyVVCxF9fHWgj6ZOwMobg1/PM75GE9io7 WUAs8XC99fan5Nl1H4Epx7bJ1zqwjd5UHQHrbTvxjZ/9iaVe0XEkD61fYMLxYNTPWdvk S5a6RJP/6G+2tOJnco/hDVzxRDbn8czimM+A6eA6oVNBCq8dc6Hv6I8qYzJVwDiO1J3U qWEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=i3UIL2czVyL0vUsqvsQnlYD0MXGhUKtqu520A63K5FA=; b=Bud6ElgebBytZ2AcrqmIuRrw9u7o6X0wPnattMTp1OlYA5BkxmqAROw9tJWhkP+zvs CveRw9wF3HBoeEUbgTSJbTI3H4XejjUDEWfAPJbSkGhxUyANjSH+eZU35aBG/d9ljdzv wpgeezUqIUMDH5lxnq4gMK8LvUDgM3h292SDcV6y/ysltqQNqhP3QoTkt1aNvI+F251g hsuRWCMXYPU8GVKEYCA4rttrZY20anlqYVJ2/QzbEUALFvHL5pl9SgjeYnR8WyhmCHVY ZYtGhGHjYP9vPDOTR0lgGhC27+oEL5daeA9RgNtQWaM4PGXUzzvHt8U0JscITPed6heS 6OhQ== X-Gm-Message-State: ALyK8tKMGlurSTKdf/wHNHd40ovAxC9MsARfYqRKt2FcRcxHBO7h+Ql4xoj6QAG5EiIxFg== X-Received: by 10.98.74.19 with SMTP id x19mr28585985pfa.79.1465263396455; Mon, 06 Jun 2016 18:36:36 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:3ce3:335b:d320:e026? ([2001:df0:0:2006:3ce3:335b:d320:e026]) by smtp.gmail.com with ESMTPSA id i65sm30380092pfk.84.2016.06.06.18.36.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 18:36:35 -0700 (PDT) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Lorenzo Colitti References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Jun 2016 13:36:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 01:36:39 -0000 On 07/06/2016 13:01, Lorenzo Colitti wrote: > On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Taking the last question first, no, because when you bind a listening >> socket to ::, >> it appears to latch onto the stable address if there is one, > > > Binding a listening socket to :: shouldn't attach to any address. The > socket should accept connections that arrive at any address on the system. > The address that is used for the connection is the one that the other side > of the connection decides to connect to. Duh, of course, but only if that address is still valid when the SYN arrives. Thanks for the correction. Bian From nobody Mon Jun 6 18:38:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE76F12D7D3 for ; Mon, 6 Jun 2016 18:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 phRtKnWT8Fjp for ; Mon, 6 Jun 2016 18:38:24 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE3C12D97D for ; Mon, 6 Jun 2016 18:38:18 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id bz2so40622210pad.1 for ; Mon, 06 Jun 2016 18:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Zxqb0teOInSZ6/qJ5ajhEGCtQjEzBlNtfgVItgQnjYA=; b=mZvp+I+a/1nsbqQSEVo/RSvFX9yWv/BjCxcls3SWVjZXVG305EwDkX7Yb/H7EPmEcz f0QnPFA4VRWcn8wj+dxthceqtpG67xuKqeE3aedf7eN5IBAHr3Mb4BKugidD+jOs2x/I 78vCum93OiXjgP4DaXK62HzbVfLTXDU+SRx0+cytscoZB7lxMOIaLea6RDfb74Rs62cp Lv2PCLdyxEdk2x4Asowob+jl94NdN3RfGAaK/dxorAoypf2Jw5kIsJ2t2WiTCc/pQD+x xGTTBPYnTew6xjm+X6ms3tFjObmZjrFVUJ3nRxOpLsJsBPgmDQ9mIHToX6spSl41kY8g Tfmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Zxqb0teOInSZ6/qJ5ajhEGCtQjEzBlNtfgVItgQnjYA=; b=S/PnCchKnqtn7R4M4Sio7dfxXudRPbVnsYqf9o6SKMuoOWtp9QZXRsncXp8pAqYvNc 3jX/CxiVaQP0p/u8f32nsM0A9ah0bf38ktHsPm02gmRLMVxdD9j8OAtX5VyTLkwZhbB9 FauLwZpNs+gRvgNH6UIFXjpF50YfiTtAzd2+YL6m379ErJORzi7547fXiIXWRDJhPVXm 9IG9b4BDbf6ODThCobWBnu1gEyhU5WV6+W0dkSovUe9GbW39iLHB8M4PmHvG0Y6Ca7vw eyKVOrkBNpVDaUAnF6b6pozqhvSgEeT4Lsx4blmxNooC4VOokRBUUG1oY1qT6pE5Xb2n 36xA== X-Gm-Message-State: ALyK8tKQJN2ndLuy+orV9XqJDFQDclTbiH5hlq12V0/Zh71ON3EUEmyJahFh4t7V4XD/AQ== X-Received: by 10.66.81.70 with SMTP id y6mr27884393pax.121.1465263498151; Mon, 06 Jun 2016 18:38:18 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:3ce3:335b:d320:e026? ([2001:df0:0:2006:3ce3:335b:d320:e026]) by smtp.gmail.com with ESMTPSA id j65sm30430378pfj.44.2016.06.06.18.38.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 18:38:17 -0700 (PDT) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Mark Smith , Lorenzo Colitti References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <5743864F.2080705@si6networks.com> <19CAC11E-E7FC-46D1-82C6-169E6391E330@jisc.ac.uk> <60ef689a-5c9a-8f1d-c35c-3cf9f0821edd@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <07d675f6-58f3-ac25-20df-574fc8dcb988@gmail.com> Date: Tue, 7 Jun 2016 13:38:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 01:38:26 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 07/06/2016 13:27, Mark Smith wrote: > On 7 Jun 2016 10:32 AM, "Lorenzo Colitti" wrote: >> >> On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >>> >>> Taking the last question first, no, because when you bind a listening > socket to ::, >>> it appears to latch onto the stable address if there is one, >> >> >> Binding a listening socket to :: shouldn't attach to any address. The > socket should accept connections that arrive at any address on the system. > The address that is used for the connection is the one that the other side > of the connection decides to connect to. >> > > That's been my understanding (and experience I think, although it has been > a while). > > Is it possible that the sockets interface in the language Brian is using > (Python?) isn't quite providing the true sockets API? No. I was just confused. (In my brain, not in my code, which was doing exactly the right thing.) Brian From nobody Mon Jun 6 19:22:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41B12D984 for ; Mon, 6 Jun 2016 19:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu 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 qtbbPB41UYoZ for ; Mon, 6 Jun 2016 19:22:06 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 60EC712D539 for ; Mon, 6 Jun 2016 19:22:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id C78007C0 for ; Tue, 7 Jun 2016 02:22:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkSxLXRkPIfI for ; Mon, 6 Jun 2016 21:22:05 -0500 (CDT) Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 9B1EB7B9 for ; Mon, 6 Jun 2016 21:22:05 -0500 (CDT) Received: by mail-it0-f71.google.com with SMTP id u203so127879196itc.0 for ; Mon, 06 Jun 2016 19:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CLcCCZ/tI4vSTZ5D+4R6oSaYEFOFH6/gHG+VmCEg7Sg=; b=W08IRvC848SRh0buXhhUXY0z71Pz64N7KhedmIyFIosptt2btHgZ/MkyemYpUpkrqd liAzMaaBWfDOa7mOiGSryX30nJ+0hTkpMwg2BO3SzhthstFH4Vz8Xrivgm6IZsVi6mO0 rEhb2wQxgGNg0uqquvhlsS+n3Y3ng57freycE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CLcCCZ/tI4vSTZ5D+4R6oSaYEFOFH6/gHG+VmCEg7Sg=; b=WS/s3+4ULi8ie6P2n3ZG1FXD3KWYuP5VN3Po0MZqxqiXl2VnPn+gkwPSu1Ij4KM2cG DdPhBzklq2CxZxw2BSjtAJ/9WJt8R125shLmqj1RA68i+Zjb/Es8JIVa6qcBlDw3t4cJ 7s79l+daVUqKVZu0ct5t8QrJVgMuD6ta9MTtVOZRocqlQu0TDXrK9KhNk88BwQfpAMNq K9k9495IeFL5LaSJZL0jJ7qjt1c/pudbIvjbCkDdfA7apmntNbmwlh6HKK5zrX8D/fkC YpoqOPhL6QQXokfEp+Sob5VxXAn1a8gtF3c8LAIJfI3RK+wFXn+5rLDOFab7hpPkiDKo 3AYA== X-Gm-Message-State: ALyK8tK3Eqi4P+qSqHvAuKw991JOQPxwuYJjgdzscKf3Xrbk3iVW4J/yVBi+gV5w0DA3DaQZt1MxeXNEQaZA3uu3v2uOfPg6wHe0kt7ab4agiM4rqIzpG5ageSXuZ3MoaSQ= X-Received: by 10.36.227.12 with SMTP id d12mr45092ith.49.1465266125272; Mon, 06 Jun 2016 19:22:05 -0700 (PDT) X-Received: by 10.36.227.12 with SMTP id d12mr45078ith.49.1465266125116; Mon, 06 Jun 2016 19:22:05 -0700 (PDT) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id u66sm7587613itc.21.2016.06.06.19.22.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 19:22:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5601E73A-6E97-4EF5-8ACC-F7470F07B3C4 Mime-Version: 1.0 (1.0) Subject: Re: Testing ULAness From: David Farmer X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Mon, 6 Jun 2016 21:22:02 -0500 Content-Transfer-Encoding: 7bit Message-Id: <096A5A6F-9173-4A09-A65B-D18A5869E479@umn.edu> References: To: Lorenzo Colitti Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 02:22:21 -0000 --Apple-Mail-5601E73A-6E97-4EF5-8ACC-F7470F07B3C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Jun 6, 2016, at 19:51, Lorenzo Colitti wrote: >=20 >> On Tue, Jun 7, 2016 at 7:05 AM, David Farmer wrote: >> But there is nothing explicitly prohibiting them being forwarded >> (routed) out of an administrative domain either. >=20 > RFC 4193 says that they should not be forwarded out of a site: >=20 > Site border routers and firewalls should be configured to not forward > any packets with Local IPv6 source or destination addresses outside > of the site, unless they have been explicitly configured with routing > information about specific /48 or longer Local IPv6 prefixes.=20 > ... > Routers that maintain peering arrangements between Autonomous Systems > throughout the Internet should obey the recommendations for site > border routers, unless configured otherwise. >=20 > and this text in RFC 7084 says that home routers MUST NOT forward ULAs out= , either: >=20 > ULA-4: By default, the IPv6 CE router MUST act as a site border > router according to Section 4.3 of [RFC4193] and filter > packets with local IPv6 source or destination addresses > accordingly.=20 >=20 > I think the registry is correct in saying that these addresses are not glo= bal according to its definition of global. ... unless explicitly configured ... To me that means; not prohibited, just not allowed by default, does it mean s= omething else to you?=20 Even with the definition of "global" use by the registry, a footnote would h= ave seemed appropriate to me, because a strait "false" seems misleading or a= t least a serious oversimplification. That said, a strait "true" would have= been even more wrong with that definition.=20 David Farmer --Apple-Mail-5601E73A-6E97-4EF5-8ACC-F7470F07B3C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhon= e
On Jun 6, 2016, at 19:51, Lorenzo Colitti <lorenzo@google.com> wrote:

On Tue, Jun 7, 2016 at 7:05 AM, David Farmer &= lt;farmer@umn.edu> wrote:
But there is n= othing explicitly prohibiting them being forwarded
(routed) out of an administrative domain either.

=
RFC 4193 says that they should not be forwarded out of a site:

   Site border routers and firewall= s should be configured to not forward
   any packets wit= h Local IPv6 source or destination addresses outside
   = of the site, unless they have been explicitly configured with routing
<= div>   information about specific /48 or longer Local IPv6 prefixe= s. 
...
   Routers that m= aintain peering arrangements between Autonomous Systems
  &nb= sp;throughout the Internet should obey the recommendations for site
   border routers, unless configured otherwise.
=
and this text in RFC 7084 says that home routers MUST NOT for= ward ULAs out, either:

   ULA-4: &nbs= p;By default, the IPv6 CE router MUST act as a site border
  &= nbsp;        router according to Section 4.3 of [RFC4193= ] and filter
           packets with= local IPv6 source or destination addresses
      &= nbsp;    accordingly. 

I think the r= egistry is correct in saying that these addresses are not global according t= o its definition of global.

... unless explicitly configured ...
<= br>
To me that means; not prohibited, just not allowed by default,= does it mean something else to you? 

Even wit= h the definition of "global" use by the registry, a footnote would have seem= ed appropriate to me, because a strait "false" seems misleading or at least a= serious oversimplification.  That said, a strait "true" would have bee= n even more wrong with that definition. 

David= Farmer

= --Apple-Mail-5601E73A-6E97-4EF5-8ACC-F7470F07B3C4-- From nobody Mon Jun 6 20:55:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8C012D1A3 for ; Mon, 6 Jun 2016 20:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CqUM9rVvcJuv for ; Mon, 6 Jun 2016 20:55:09 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD3D12D807 for ; Mon, 6 Jun 2016 20:55:09 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id xk1so41630124pac.2 for ; Mon, 06 Jun 2016 20:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pV0w0eULzPzzgAlB3lGPqBXFwtwSMRwqHB1SOEZFfpI=; b=WxFGfq643h/crAssen6CdZccG/GL8I5qCXwdRAIp59KdTZa67h0RhpF0GTQgCx3N+e OnYbn35aZiQuoDT4K+q6qKCxaJr5NJ/1k+FxOlXhssDcXD5TnTCOREeiqJB7tkuy4XDv hU2wXDRM2/9atzuGMF7MGli5s1J62Ja7y9nJ2eziBdcT1DfJum/ZxqcWWDb9H6+2fdzD tU6jzDO9YxnT2Jt/uQxaflP0fZrxSMtLDLrom7V+ZXW0v1foZOxa1PnLhq7rE7vNky/E urx9P1OEaGaiS9zGfnQvGDSZl/1PqD+hoVyUcTC+xVMzyG37mK/pLBqja0CtpmPNtFMt Vljw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=pV0w0eULzPzzgAlB3lGPqBXFwtwSMRwqHB1SOEZFfpI=; b=JXXItmbwY8ZHueLCmANd202pCgqTGtkXoqDT28Pma41+Ne78PKGxlxP1Q8anFFF1/K ZA4Z0436/+jTAcLzbtMKm2DSRHfarEXn/+mM/BcB//T7/UYw6YvdDRADxqFmOwgFRyHi 3+/LzciBuC9iZIfehp9otW+QT0zGiCwoWQkp0ojmWTc7HnAt205Of9HgoRt3fJile3OW CWkb5viQonZLvONvJ0K8O25LYP6PZpKUIGca+FC8R+GCyhR/sJ3wsM3tykBFo9VUh0iI BC91iGsnRlM1zN8OT1mrtQgQPFwynxnyy+RWQh2uHX/37n6HHBAsf6J54KIyT3plq07a U3kw== X-Gm-Message-State: ALyK8tLZpi2FlaSjj6lnfIH8IhDOEgww60igRQ9duGRD41fMxZckr5v8DbOWTfWTfMozOA== X-Received: by 10.66.191.226 with SMTP id hb2mr14691629pac.72.1465271708436; Mon, 06 Jun 2016 20:55:08 -0700 (PDT) Received: from ?IPv6:2406:e007:77b7:1:ad35:c6c2:16b6:2e9b? ([2406:e007:77b7:1:ad35:c6c2:16b6:2e9b]) by smtp.gmail.com with ESMTPSA id d4sm31022695pfa.23.2016.06.06.20.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 20:55:07 -0700 (PDT) Subject: Re: Testing ULAness To: David Farmer , Lorenzo Colitti References: <096A5A6F-9173-4A09-A65B-D18A5869E479@umn.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Jun 2016 15:55:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <096A5A6F-9173-4A09-A65B-D18A5869E479@umn.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 03:55:11 -0000 On 07/06/2016 14:22, David Farmer wrote: > > Sent from my iPhone >> On Jun 6, 2016, at 19:51, Lorenzo Colitti wrote: >> >>> On Tue, Jun 7, 2016 at 7:05 AM, David Farmer wrote: >>> But there is nothing explicitly prohibiting them being forwarded >>> (routed) out of an administrative domain either. >> >> RFC 4193 says that they should not be forwarded out of a site: >> >> Site border routers and firewalls should be configured to not forward >> any packets with Local IPv6 source or destination addresses outside >> of the site, unless they have been explicitly configured with routing >> information about specific /48 or longer Local IPv6 prefixes. >> ... >> Routers that maintain peering arrangements between Autonomous Systems >> throughout the Internet should obey the recommendations for site >> border routers, unless configured otherwise. >> >> and this text in RFC 7084 says that home routers MUST NOT forward ULAs out, either: >> >> ULA-4: By default, the IPv6 CE router MUST act as a site border >> router according to Section 4.3 of [RFC4193] and filter >> packets with local IPv6 source or destination addresses >> accordingly. >> >> I think the registry is correct in saying that these addresses are not global according to its definition of global. > > ... unless explicitly configured ... > > To me that means; not prohibited, just not allowed by default, does it mean something else to you? > > Even with the definition of "global" use by the registry, a footnote would have seemed appropriate to me, because a strait "false" seems misleading or at least a serious oversimplification. That said, a strait "true" would have been even more wrong with that definition. All true. However, the addressing architecture says this (quoting 4291bis): The type of an IPv6 address is identified by the high-order bits of the address, as follows: Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast 11111111 ff00::/8 2.7 Link-Local unicast 1111111010 fe80::/10 2.5.6 Global Unicast (everything else) ... Future specifications may redefine one or more sub-ranges of the Global Unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses. (and the ULA spec is consistent with that). So, there are two properties that are getting confused here: "1. Global scope (and routeable off-link)" - what the addressing architecture says. "2. Globally routed (if you're lucky)" - what the IANA text and RFC6890 say. ULAs match #1 but not #2. Just saying "Global" does not distinguish #1 from #2. I find this unsatisfactory. I wish we'd picked it up when reviewing RFC6890. Brian From nobody Tue Jun 7 01:18:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2375512B036 for ; Tue, 7 Jun 2016 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Z9D8kWLRTF0A for ; Tue, 7 Jun 2016 01:17:58 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12F312B02F for ; Tue, 7 Jun 2016 01:17:58 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z189so73173285itg.0 for ; Tue, 07 Jun 2016 01:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JOEST30owuzLBFZ7hMQFvoKw9XwEL8sB1isRB0U8fNI=; b=XFw6KYlHJHxkgX9C0Fpkt8IfUC7NS/MHrQCOaMNypf/PAsdOTtQzJ/ont7fZBhrMnA G/HjoQCwbqssjPiXxpRgGV/m7jQJFwrQfKKmyJ0pZmRskvRQYWWUazjgICI/ZZioZ/Ic N+bNTrJ1WCUOM/JwYBUhaTJ476IARZwIG356G4MXvCin70f2tDhrFsC5V1/wJXTGo31g R8rNKYfYiMaqtT5WRWppNlOarNwezqPjInxFyvkLc+XMk3MHSFyxP2VLzyOK2iJgOZD4 fZ47FhsEmnUAQRXjKEacCKn5ZuJmQzwnOU2sRLS3vr2UdgK47kxG997vC255EEKEl8wc CcTw== 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; bh=JOEST30owuzLBFZ7hMQFvoKw9XwEL8sB1isRB0U8fNI=; b=SI4wQgUSb/6GO+vTkaK4lnHcokw3ZElGcx7/t5/nefZ9z8bwzIVfAyfl7++xq8mDF4 XW6XNGyjlS2Frwy3FUKPGMT0+8SxzM1sZ8f4ROz6ikdqCQw+Ncs1CorEpqWfPGGZOYTf DCYPDTDndlWjv08SB0NZPH2Decf3gdHVtXsiiCsSn1wWgd15Xz3xkbzgrSM1e7Jn7G/X Y/uIkipxWvcMxHoeNKXX2EGlA70QjVdfDwtJBmlWfTkTk+/5qibbAPT4hpHLWbH299as Y7oBzRuJtUqLuetGjz29gKkPKCLyPmnhj+0ykhorwZ7Qrvz+/QYIosfPh6T9ZaAfO2+I f8+g== X-Gm-Message-State: ALyK8tLolA1a5PWI+5/I948OM3MOTAl5B+8oF7wyUVBvPPfdofiJcwhksUpgZK99ctpC53xvPD1xRf7EXg9szg== X-Received: by 10.107.53.5 with SMTP id c5mr11200151ioa.2.1465287478161; Tue, 07 Jun 2016 01:17:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Tue, 7 Jun 2016 01:17:38 -0700 (PDT) In-Reply-To: <301d0828-14d8-48a7-ccbc-28d965cb340f@gmail.com> References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> <301d0828-14d8-48a7-ccbc-28d965cb340f@gmail.com> From: Jen Linkova Date: Tue, 7 Jun 2016 10:17:38 +0200 Message-ID: Subject: Re: Testing ULAness To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG , Lemon Ted X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:18:04 -0000 On Mon, Jun 6, 2016 at 10:35 PM, Brian E Carpenter wrote: > The problem is deeper, I think: we are using "global" to mean two different > things. There probably isn't a binary fix to that problem. It was correct > to reject the erratum for the meaning of 'global' used in RFC6890, but > that is different from the meaning in RFC4193. You are right. We say 'global' but mean either 'global scope' or 'globally routable'. The former is related to semantic: ULA is meaningful globally. The latter is more about policy: those addresses are not supposed to be seen outside of an administrative domain (and the borders of such domain are quite flexible). This thread itself is quite good illustration of the confusion... > I wouldn't care if it didn't have practical implications. I think it would be nice to get it fixed. Not sure if updating rfc6890 would solve the issue however... -- SY, Jen Linkova aka Furry From nobody Tue Jun 7 03:09:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9618E12D11C for ; Tue, 7 Jun 2016 03:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 4EMc3XSRAP6V for ; Tue, 7 Jun 2016 03:09:48 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C9812D5A4 for ; Tue, 7 Jun 2016 03:09:48 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h19so165171590ywc.0 for ; Tue, 07 Jun 2016 03:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=W9k+h/Pn3jBq0EkN5yKqFyjMogYFkmDCK4tiXbb5xdg=; b=pgxf3kXlBxQKByigIwYrtYBK7f4+05VyQAfYDz/HaSjTfGwp1iZDPnO2HFR1DIqdkr hu8mQScYrlUTzqMMU09guHXq3eZF6nso3yd7dBduu56ZarjiBNk13aAL+3SltqN7Kb/+ jrFcw0IJkBU+uyZAGkIsSKt3JrY4A/TsNnRR0DbbiKy85AUxcXAAk77zmk6FNLGRqSOq oetYMXJ8vRZqcRoNzx/RW8427dxWKxpo6TlvqwB5izBN6mStqXCZHJNwOIDvZTvRlctR ht75h/C3spmuiDvxXpXfVlcD7kRjloOTfHDQpnz+ZXAJV0BE9SMaNFmDtdzoeehg9U/L zGBQ== 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:date :message-id:subject:from:to:cc; bh=W9k+h/Pn3jBq0EkN5yKqFyjMogYFkmDCK4tiXbb5xdg=; b=aE+3L5iiwj05AN+V92vDFvJ1/HpB0fpu73D1Cv4Vz3unUtRc02pbfBekCmwjCAbx8D 2nuEIkGtRtygymvF+UNBzCgcFDbRZrUE/iAH2KSqra/JJR0tjlnjYZdBZJwGAaotFY6N uf6qCzNQ7YjCi1Mh4hGz2hETR5s6Sh4RIFXKDYMElUaF28KYdnMncNpG/2/ybD5D8r7i H5F1QW/jQJ5BmweBRL2kgt/L6o73f8NJyQ2PxJuAfe6gDpNqsiyEj6z9m5VEcc0jK0/5 Jhqgn70exdB9Xf9zMpT7wQlkxag1mVBWrZqNX+60lMIxLlCUsVrZ8mvUREQHsrK/DCWF R/5A== X-Gm-Message-State: ALyK8tKNZhfeLTwF+GkM5u94g4lW+r683xZI4RJDyTVVo+/sRr1Zfoj9/Uu9bWD/sToRIbWWIfJYNyLVO6SEGuCK MIME-Version: 1.0 X-Received: by 10.37.70.9 with SMTP id t9mr13487234yba.44.1465294187083; Tue, 07 Jun 2016 03:09:47 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Tue, 7 Jun 2016 03:09:46 -0700 (PDT) Received: by 10.37.198.210 with HTTP; Tue, 7 Jun 2016 03:09:46 -0700 (PDT) In-Reply-To: References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> <301d0828-14d8-48a7-ccbc-28d965cb340f@gmail.com> Date: Tue, 7 Jun 2016 19:09:46 +0900 Message-ID: Subject: Re: Testing ULAness From: Lorenzo Colitti To: Jen Linkova Content-Type: multipart/alternative; boundary=001a113c516483c4f10534ad63a0 Archived-At: Cc: IETF IPv6 Mailing List , Lemon Ted X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 10:09:49 -0000 --001a113c516483c4f10534ad63a0 Content-Type: text/plain; charset=UTF-8 On 7 Jun 2016 5:18 pm, "Jen Linkova" wrote: > > The former is related to semantic: ULA is meaningful globally. Realistically, I don't think it's feasible to have global meaning without global reachability. People just configure fd00::/64 all over the place, grab /16 blocks out of fd00::/8 without regard for collisions, etc. --001a113c516483c4f10534ad63a0 Content-Type: text/html; charset=UTF-8

On 7 Jun 2016 5:18 pm, "Jen Linkova" <furry13@gmail.com> wrote:
>
> The former is related to semantic: ULA is meaningful globally.

Realistically, I don't think it's feasible to have global meaning without global reachability. People just configure fd00::/64 all over the place, grab /16 blocks out of fd00::/8 without regard for collisions, etc.

--001a113c516483c4f10534ad63a0-- From nobody Tue Jun 7 04:17:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10A312B068 for ; Tue, 7 Jun 2016 04:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CoI-9r5mfnHm for ; Tue, 7 Jun 2016 04:17:34 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECAB12B022 for ; Tue, 7 Jun 2016 04:17:34 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id h190so4461492ith.1 for ; Tue, 07 Jun 2016 04:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oDPyclOWXbrllqEN9CydcZMuzgtuCQDydeKxBzxdeKs=; b=Mw6DxFuA4jCxKXitRprSkIGOpyFbmZZ6g6I7DEbFNLDEaqJiB1cCvQ1ME8E6L8Q0eL BrhrdLLEnYPT9xrnR0HdufAv8C3kqLdacCKa3oDoThwBIgESnRKnT/wv7p+qco4xHNlE K02taT3FUnG/RJzMN9jqJMXmvW5GJ9SdNai+KsmF+T1PPb6BjRPP5Z3V0313EEPw2gkg a9ypecsLPMphheQerJI9PbRy1PZXulA8F1Mdyc8WD/foNc7l/Rhoih0WRbdJSZfcSjkK afNqgoR1ihARubAarKxj2Ni0AkQ+TKb16Uk6w7AX09IRiFfA29ZMbweBWwQwzAEEET5E D+iw== 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; bh=oDPyclOWXbrllqEN9CydcZMuzgtuCQDydeKxBzxdeKs=; b=CKVS3V8OmXxhHoNCPgSLM4BaG4W4f2+2s+fJBd7jvYkouCudj06NUc7+mUADFiNF7Z lXTGENA/Z/8v6TPpJQDM557Ez+aKE/Pd6RyYp2OV+IS9/RpPZsq4i7emuPP9/rvxU7oo tiEIR8rwui1l50Fs95ktbB0KgYB9d4V3mfYzChigkDdO1CHBeTHPM4OmLXI96YjieGVd VJmah4b32IwJPJ5F+3sjaUPostWqsAyctdiKgnyl5+JifD3BNu4OmCbk+Dj+PPuqIcid L18i5kv81WvRUFqV+QhoF1dGdtafY2pv5XqJuHZazzOiNzdjr0HWpYqyDY3xDXKxoDvU il4w== X-Gm-Message-State: ALyK8tIFleFXlTFqgLnkSpTJlbmRLdpiVrwU+a3A8CCq2wZ2uAr37kNYzh5qcTVky55VJ12D/E5Fl0bdPOMp5A== X-Received: by 10.107.175.227 with SMTP id p96mr13009398ioo.78.1465298253598; Tue, 07 Jun 2016 04:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Tue, 7 Jun 2016 04:17:14 -0700 (PDT) In-Reply-To: References: <27cc84ef-338b-964d-7117-58443f74ec84@gmail.com> <6F629715-4D2E-445F-987E-41DEE186FC40@employees.org> <301d0828-14d8-48a7-ccbc-28d965cb340f@gmail.com> From: Jen Linkova Date: Tue, 7 Jun 2016 13:17:14 +0200 Message-ID: Subject: Re: Testing ULAness To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IPv6 Mailing List , Lemon Ted X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 11:17:35 -0000 On Tue, Jun 7, 2016 at 12:09 PM, Lorenzo Colitti wrote: > On 7 Jun 2016 5:18 pm, "Jen Linkova" wrote: >> >> The former is related to semantic: ULA is meaningful globally. > > Realistically, I don't think it's feasible to have global meaning without > global reachability. Imagine I bought an island somewhere near Australia, called it Brittia and founded a micronation there, Rainbow Kingdom with a city called Asgard being its capital. Now I'm sending you a birthday postcard with sender's address: "Southern Hemisphere, Brittia, Rainbow Kingdom, Asgard, Aardvark lane, bld.5". That address has a global meaning (let's assume I've been following RFCs..ensured that name is unique) but you probably would not be able to reply (until Japan recognizes my Rainbow Kingdom) . So if I build a network and use fd38:5e40:c5d8::/48 prefix (all my ISPs told me that they do not support IPv6 as nobody is asking for it...) - that prefix is most likely unique across Internet, has global meaning (global scope by definition) and I can use it to talk to my friend's network (fd43:d49:72a1::/48) over the GRE tunnel we built. But it is not globally reachable. Or I can get an address space from RIPE but use for some internal isolated network and never ever advertize it. It would have global meaning but no reachability whatsoever. >People just configure fd00::/64 all over the place, > grab /16 blocks out of fd00::/8 without regard for collisions, etc. To be honest I'd rather avoid mixing discussions about standards and semantics and discussions about stupid things people do. I've seen people grabbing random /22 from RIPE address space and advertising it in other region saying 'or, I checked our RIR, does not look like they have it assigned to anyone so I assume it is free and I can use it...' ;) Or shall I mention 1.1.1.0/24 stories? :) -- SY, Jen Linkova aka Furry From nobody Tue Jun 7 04:57:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80D12D0FD for ; Tue, 7 Jun 2016 04:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 S2cV5vLiEtSN for ; Tue, 7 Jun 2016 04:57:18 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 634EB12B020 for ; Tue, 7 Jun 2016 04:57:15 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1bAFdB-0006QN-ID; Tue, 07 Jun 2016 13:57:13 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 786FEB0029E; Tue, 7 Jun 2016 13:57:13 +0200 (CEST) Subject: Re: ULA-C [was: Testing ULAness] To: jordi.palet@consulintel.es, IETF IPv6 Mailing List References: <22582.1465221680@obiwan.sandelman.ca> <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> From: "Bless, Roland (TM)" X-Enigmail-Draft-Status: N1110 Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <5756B699.3050005@kit.edu> Date: Tue, 7 Jun 2016 13:57:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <4E510308-318B-422F-AC29-F692E26384FF@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1465300633. Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 11:57:24 -0000 Hi Jordi and all, Am 06.06.2016 um 22:31 schrieb JORDI PALET MARTINEZ: > Making sure is not “just†probabilistically unique? Yep. > The question may be should be “are there use cases for ULA?â€. If > there are use cases (for example) which really make sense to use ULA > inside organizations and those organizations one day are involved in > a merge process, ULA-C will make sure there is not a clash. There was a discussion in 2011 about ULA-Cs here: https://mailarchive.ietf.org/arch/msg/ipv6/Wm8un5ax2nq1SHCURMJGNJbPeUs and use cases where on-board networks of automotives (cars, planes, etc.). One suggestion was, however, to use ordinary global addresses from RIRs instead of ULA-Cs. I'm not sure what happens if the company goes bankrupt and the registration is void - presumably there are enough addresses so that those prefixes will never be reassigned. However, vehicles need to have a rigorous filter for their on-board network anyway and need to cope with colliding prefixes at the outside. Regards, Roland From nobody Tue Jun 7 05:05:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBAF12B020 for ; Tue, 7 Jun 2016 05:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 fV8R4nhZfqkp for ; Tue, 7 Jun 2016 05:05:10 -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 5352912B04A for ; Tue, 7 Jun 2016 05:05:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u57C58mT021016 for ; Tue, 7 Jun 2016 14:05:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BCFDB204ADE for ; Tue, 7 Jun 2016 14:05:37 +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 B3AFF204D94 for ; Tue, 7 Jun 2016 14:05:37 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u57C57iB002091 for ; Tue, 7 Jun 2016 14:05:08 +0200 Subject: Re: possibility of a MAC randomization algorithm To: ipv6@ietf.org References: <5704F1C8.8010508@gont.com.ar> <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 7 Jun 2016 14:05:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 12:05:15 -0000 Hi, Private discussion clarified a few points to me. The referred to 'local' bit is the one in the MAC address, not the one in the Interface ID. So yes, I think that 'locally-administered' bit of the MAC address should be set. In IEEE speak, this means it's not globally-unique. 1. in my oppinion, it is good that the Windows 10 sets that bit 'locally-administered' while generating randomly the other 47bits. 2. However, I have seen recently a freely-available packet capture in which the source MAC address has the bit 'locally-administered' reset (so it's 'globally-unique'), and the OUI in that MAC address is absent from the oui.txt file. Oui.txt is centralized and freely available on the web at IEEE. I think the capture was on a computer that is not Windows, because of other reasons. Should all MAC randomization algorithm implementations take the Windows 10 implementation as an example? Other questions are: - should one (re)set the unicast/multicast bit when generating a locally-administered (random) MAC address? Or there is no relationship between the two? - should one use something else than the ESSID in the generation algorithm? ESSID is found only on wifi, not on cellular and some cellular interfaces do have IEEE-assigned MAC addresses. - should the MAC randomization algorithm check its output against the globally-unique OUIs in oui.txt to make sure there is no clash? Yours, Alex Le 06/06/2016 à 15:44, Alexandre Petrescu a écrit : > Le 03/06/2016 à 20:55, Christian Huitema a écrit : >> On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote: >>> >>> About the possibility of a MAC randomization algorithm, >>> regardless of being used in an IP address: >>> >>>> we do not control whether MAC addr randomization algorithm is >>>> appropriate or if it is actually possible. >> >> It is certainly possible, since it is shipping in Windows 10. >> >>> The algorithm output should be checked against the authoritative >>> oui.txt, and not generate an existing OUI (organizationally >>> unique id). >> >> There is a potential debate about that. What we are doing in >> Windows 10 is set the "local" bit to true, which means that the OUI >> does not apply. > > But, I understand the use of the u/l bit is no more desirable - it > is part of an IID and the IID is opaque: RFC 7136 "Significance of > IPv6 IIDs". > >>> Is such an algorithm documented somewhere? >> >> Mathy Vanhoef, PhD Student Computer Security at KU Leuven, wrote a >> nice blog containing such a description: >> http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html >> > >> > Thanks for the pointer, that's useful indeed. > > Whereas it does present an analysis on the algorithm, it could > further be improved with the following aspects: > > - it should work not only on WiFi but also on other links which dont > have SSID but do have 48bit MAC addresses (e.g. cellular, USB, > 802.11p, others). The described algorithm uses SSID in the SHA > calculation. - it should check a generated random MAC address does > not clash with existing oui.txt assignments, otherwise it may > involuntarily attack others (pretent to be someone else). > > Alex > >> >> -- Christian Huitema >> >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 7 07:45:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E4612D6B8 for ; Tue, 7 Jun 2016 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1J_VD5no1IB4 for ; Tue, 7 Jun 2016 07:45:28 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD1F12D750 for ; Tue, 7 Jun 2016 07:45:27 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id h62so28349856itb.1 for ; Tue, 07 Jun 2016 07:45:27 -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:from:date:message-id :subject:to:cc; bh=0U0tA5Bzl4p67ZTM5SyZ+8lgL/QvfJsJ/3LlPbjy6qI=; b=Nezk332SJYsGk3+cQthKET35ZrKx5BtgakYddJBrUsgyFP2DhRyNO1G5/cI55KW+ke LvN/feFG9Xm2pXlP8WlPxLsOdCt0Io4JZvshFMa2TDUfkdYurvA2v762Zhr4BVeRt53V jH6vE9CBYAiiY8NHqN2ntOxlB7uXCbD0UrXpBPvicuR2RbORgeiBwi5DtiJQ3Drnzxd6 t7o1Kv1+007VzWBoHmwzwxveW2rzgPPXUSv+R4Te13sN/W041rTkQzVqqdTgfLWBEtWv HRGHRrk9ww9x0Z9afc5gbDZpIbKSi7GhmdM+uTf1zHdAgWzQJtG7PWaq9gkBs3TN/Yy0 SjNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0U0tA5Bzl4p67ZTM5SyZ+8lgL/QvfJsJ/3LlPbjy6qI=; b=Ecfy2GjIoETq6a2Oxfyh683TAYQqb4vO6U9fgDm2rmpCT88A6rCnHjiFWiTwgOkExf p3vRJ7mNRHFUTHyjCZUws9XzsfmZnW07I/YUUfNeBENkHjqy9MROj11FKET2/jJmHDJ8 mJ0SebVcfVARku5uh9nu/HOa9+pLjcRNw82l/3bkHhfivdGnaFUre+WJXEWNrqnHcuJ1 9HWoeGDJE1QgfAas8rEzwXJKgUlHJocPMFtVGxQEKu3Xp0Ea+uwTOdKwORytaMYOobnh yRf2s4ZzVpD468YvIW/i21B4JXEMT0bS+nNhmK6KN8nClSQUPLcJ9yBpXEsBPlb1dUtG LTQA== X-Gm-Message-State: ALyK8tJ2f18CCVkHN1QwJUw5G6Rh5pelLOxyc9XZc+IGz9fWu2JamS+rbwa5XvvwqXRO7K7njNyFzee4wf0lJA== X-Received: by 10.36.80.4 with SMTP id m4mr4720853itb.37.1465310725958; Tue, 07 Jun 2016 07:45:25 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.79.129.2 with HTTP; Tue, 7 Jun 2016 07:45:25 -0700 (PDT) In-Reply-To: References: <096A5A6F-9173-4A09-A65B-D18A5869E479@umn.edu> From: Kerry Lynn Date: Tue, 7 Jun 2016 10:45:25 -0400 X-Google-Sender-Auth: Vvg545g5LPQuxyw6TxtEInak9c8 Message-ID: Subject: Re: Testing ULAness To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1143f4ee4e716e0534b13df7 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:45:31 -0000 --001a1143f4ee4e716e0534b13df7 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2016 at 11:55 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 07/06/2016 14:22, David Farmer wrote: > > > > Sent from my iPhone > >> On Jun 6, 2016, at 19:51, Lorenzo Colitti wrote: > >> > >>> On Tue, Jun 7, 2016 at 7:05 AM, David Farmer wrote: > >>> But there is nothing explicitly prohibiting them being forwarded > >>> (routed) out of an administrative domain either. > >> > >> RFC 4193 says that they should not be forwarded out of a site: > >> > >> Site border routers and firewalls should be configured to not forward > >> any packets with Local IPv6 source or destination addresses outside > >> of the site, unless they have been explicitly configured with routing > >> information about specific /48 or longer Local IPv6 prefixes. > >> ... > >> Routers that maintain peering arrangements between Autonomous Systems > >> throughout the Internet should obey the recommendations for site > >> border routers, unless configured otherwise. > >> > >> and this text in RFC 7084 says that home routers MUST NOT forward ULAs > out, either: > >> > >> ULA-4: By default, the IPv6 CE router MUST act as a site border > >> router according to Section 4.3 of [RFC4193] and filter > >> packets with local IPv6 source or destination addresses > >> accordingly. > >> > >> I think the registry is correct in saying that these addresses are not > global according to its definition of global. > > > > ... unless explicitly configured ... > > > > To me that means; not prohibited, just not allowed by default, does it > mean something else to you? > > > > Even with the definition of "global" use by the registry, a footnote > would have seemed appropriate to me, because a strait "false" seems > misleading or at least a serious oversimplification. That said, a strait > "true" would have been even more wrong with that definition. > > This is precisely what Errata ID 3879 proposed: that ULAs did not conform to the RFC6890 definition of "Global" and therefore this field in the IANA IPv6 Special-Purpose Registry should have the value "N/A" along with a pointer to RFC4193. My larger point is that this has been litigated previously and it might be helpful to have that context (but I haven't found it). > All true. However, the addressing architecture says this (quoting 4291bis): > > The type of an IPv6 address is identified by the high-order bits of > the address, as follows: > > Address type Binary prefix IPv6 notation Section > ------------ ------------- ------------- ------- > Unspecified 00...0 (128 bits) ::/128 2.5.2 > Loopback 00...1 (128 bits) ::1/128 2.5.3 > Multicast 11111111 ff00::/8 2.7 > Link-Local unicast 1111111010 fe80::/10 2.5.6 > Global Unicast (everything else) > ... > Future specifications may redefine one or more sub-ranges of the > Global Unicast space for other purposes, but unless and until that > happens, implementations must treat all addresses that do not start > with any of the above-listed prefixes as Global Unicast addresses. > > (and the ULA spec is consistent with that). > > So, there are two properties that are getting confused here: > > "1. Global scope (and routeable off-link)" - what the addressing > architecture says. > > Surely this is reflected by the RFC6890 definition of "Forwardable"? "2. Globally routed (if you're lucky)" - what the IANA text and RFC6890 > say. > > It seems RFC6890 is using "Global" in this context, to mean "Forwardable across a public network". > ULAs match #1 but not #2. > > Just saying "Global" does not distinguish #1 from #2. > > Right, which is probably why RFC6890 and the special-purpose registries use two bits (actually three if you include "Destination") to specify behavior. The current settings for ULAs are the same as for Private-Use ranges in the IANA IPv4 Special-Purpose Address Registry. I find this unsatisfactory. I wish we'd picked it up when reviewing RFC6890. > > What would be your suggested mitigation? Kerry > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1143f4ee4e716e0534b13df7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 6, 2016 at 11:55 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 07/06/2016 14:22, David Farmer wrote:
>
> Sent from my iPhone
>> On Jun 6, 2016, at 19:51, Lorenzo Colitti <lorenzo@google.com> wrote:
>>
>>> On Tue, Jun 7, 2016 at 7:05 AM, David Farmer <farmer@umn.edu> wrote:
>>> But there is nothing explicitly prohibiting them being forward= ed
>>> (routed) out of an administrative domain either.
>>
>> RFC 4193 says that they should not be forwarded out of a site:
>>
>>=C2=A0 =C2=A0 Site border routers and firewalls should be configure= d to not forward
>>=C2=A0 =C2=A0 any packets with Local IPv6 source or destination add= resses outside
>>=C2=A0 =C2=A0 of the site, unless they have been explicitly configu= red with routing
>>=C2=A0 =C2=A0 information about specific /48 or longer Local IPv6 p= refixes.
>> ...
>>=C2=A0 =C2=A0 Routers that maintain peering arrangements between Au= tonomous Systems
>>=C2=A0 =C2=A0 throughout the Internet should obey the recommendatio= ns for site
>>=C2=A0 =C2=A0 border routers, unless configured otherwise.
>>
>> and this text in RFC 7084 says that home routers MUST NOT forward = ULAs out, either:
>>
>>=C2=A0 =C2=A0 ULA-4:=C2=A0 By default, the IPv6 CE router MUST act = as a site border
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 router according to Secti= on 4.3 of [RFC4193] and filter
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packets with local IPv6 s= ource or destination addresses
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 accordingly.
>>
>> I think the registry is correct in saying that these addresses are= not global according to its definition of global.
>
> ... unless explicitly configured ...
>
> To me that means; not prohibited, just not allowed by default, does it= mean something else to you?
>
> Even with the definition of "global" use by the registry, a = footnote would have seemed appropriate to me, because a strait "false&= quot; seems misleading or at least a serious oversimplification.=C2=A0 That= said, a strait "true" would have been even more wrong with that = definition.

This is precisely what Errata ID 3879 proposed= : that ULAs did not conform to
the RFC6890 definition of "Gl= obal" and therefore this field in the IANA IPv6
Special-Purp= ose Registry should have the value "N/A" along with a pointer to<= /div>
RFC4193.=C2=A0 My larger point is that this has been litigated pr= eviously and it might
be helpful to have that context (but I have= n't found it).
=C2=A0
All true. However, the addressing architecture says this (quoting 42= 91bis):

=C2=A0 =C2=A0The type of an IPv6 address is identified by the high-order bi= ts of
=C2=A0 =C2=A0the address, as follows:

=C2=A0 =C2=A0 =C2=A0 Address type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Binary p= refix=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 notation=C2=A0 =C2=A0Section
=C2=A0 =C2=A0 =C2=A0 ------------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------= -----=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------------=C2=A0 =C2=A0-------
=C2=A0 =C2=A0 =C2=A0 Unspecified=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00...0= =C2=A0 (128 bits)=C2=A0 =C2=A0::/128=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2.5.= 2
=C2=A0 =C2=A0 =C2=A0 Loopback=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A000...1=C2=A0 (128 bits)=C2=A0 =C2=A0::1/128=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02.5.3
=C2=A0 =C2=A0 =C2=A0 Multicast=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 111= 11111=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ff00::/8=C2=A0 =C2=A0 = =C2=A0 =C2=A0 2.7
=C2=A0 =C2=A0 =C2=A0 Link-Local unicast=C2=A0 =C2=A01111111010=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::/10=C2=A0 =C2=A0 =C2=A0 =C2=A02.5.6
=C2=A0 =C2=A0 =C2=A0 Global Unicast=C2=A0 =C2=A0 =C2=A0 =C2=A0(everything e= lse)
...
=C2=A0 =C2=A0Future specifications may redefine one or more sub-ranges of t= he
=C2=A0 =C2=A0Global Unicast space for other purposes, but unless and until = that
=C2=A0 =C2=A0happens, implementations must treat all addresses that do not = start
=C2=A0 =C2=A0with any of the above-listed prefixes as Global Unicast addres= ses.

(and the ULA spec is consistent with that).

So, there are two properties that are getting confused here:

=C2=A0 "1. Global scope (and routeable off-link)" - what the addr= essing architecture says.

Surely this is reflected by the RFC6890 definition of= "Forwardable"?

ULAs match #1 but not #2.

Just saying "Global" does not distinguish #1 from #2.

Right, which is probably why RFC6890 and the special-= purpose registries
use two bits (actually three if you include &q= uot;Destination") to specify behavior.
The current settings = for ULAs are the same as for Private-Use ranges in the
IANA IPv4 = Special-Purpose Address Registry.

I find this unsatisfactory. I wish we'd picked it up when reviewing RFC= 6890.

What would be your suggested mitigation?

K= erry
=C2=A0
=C2=A0 =C2=A0 Brian

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

--001a1143f4ee4e716e0534b13df7-- From nobody Tue Jun 7 09:04:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1D12D095 for ; Tue, 7 Jun 2016 09:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 X-iMHj_GiLkT for ; Tue, 7 Jun 2016 09:04:11 -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 560F8126BF7 for ; Tue, 7 Jun 2016 09:04:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C18662009E for ; Tue, 7 Jun 2016 12:11:15 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CAD78638BF for ; Tue, 7 Jun 2016 12:04:09 -0400 (EDT) From: Michael Richardson To: IETF IPv6 Mailing List Subject: Re: ULA-C [was: Testing ULAness] In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:04:12 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> That's why you don't get reverse DNS or whois. >>> It's why I'd really like to revisit ULA-C, but I'm mostly alone in >>> this view. >> no you're not alone there, I'm in on it to. Sixxs showed us how easy >> it could be done. The framework don't have to be that complicated to >> describe either but we'll see. > It still baffles me why anyone would think this is useful. For any of the > use cases for ULAs, what do I gain by registering the prefix? 1) reverse DNS. 2) whois. 3) and the above gives you trackability when the traffic escapes into a place where it is not wanted. (For those who think split-horizon DNS can handle reverse DNS for non-convex networks, I suggest that you go back to your 1992-era Sun3, with the application-layer gateway. Turn off all your VPNs, and never think about using a computer or smartphone. And, even in the convex-ness of the early days, it never even worked then properly then, and I was there, and I tried hard) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1bwdoCLcPvd0N1lAQJsIQf/bHWVBTw3jNfYYbGH9Nd30DSkwkppKqzd 78XRk44taz3iyw/+sbknIKWdXroVCAVbNRWAOP1MIp89mydzlK8WHm1QsMSoWRhf RNHZgAzAWZYjNpbdXLWGYlO2P+L7l3yXlSnVGY0UFisUiZhECbQ023P7sblK52Vj if99jxDKxoG0EZFGx5ty6HGW00DIcekLIadqbcR4seI7fR+kQcfxwlcuZBqIkDvG sGFus81CQMJMKhUeYqQiFYGTu5ELxURNYCvVoKT143fBW7VNrBUAHMAXE90aY76f jgleScA1zwA3RRQBjXMsRP0udpGZiM0flvfdGKzU4cedJSpmbkfAhA== =hwo9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 7 09:15:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9AC127078 for ; Tue, 7 Jun 2016 09: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 autolearn_force=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 fv4n8NiJUx40 for ; Tue, 7 Jun 2016 09:15:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 034E512D79A for ; Tue, 7 Jun 2016 09:15:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bAJei-0000ERC; Tue, 7 Jun 2016 18:15:04 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: ULA-C [was: Testing ULAness] From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> In-reply-to: Your message of "Tue, 07 Jun 2016 12:04:09 -0400 ." <26441.1465315449@obiwan.sandelman.ca> Date: Tue, 07 Jun 2016 18:15:03 +0200 Archived-At: Cc: Michael Richardson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:15:09 -0000 In your letter dated Tue, 07 Jun 2016 12:04:09 -0400 you wrote: > > It still baffles me why anyone would think this is useful. For any of the > > use cases for ULAs, what do I gain by registering the prefix? > >1) reverse DNS. >2) whois. >3) and the above gives you trackability when the traffic escapes into a place > where it is not wanted. Assuming that the difference between ULA-C and PI space is that ULA-C is not routable, are there really that many parties that want to get unroutable space? It could be that I'm only thinking of the RIPE region where PI space is 50 euro per month. But for that money I'd rather get PI just in case I do want to announce it at a later time. From nobody Tue Jun 7 09:21:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3012D7B3 for ; Tue, 7 Jun 2016 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5HupMD7t3SCA for ; Tue, 7 Jun 2016 09:21:29 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6063712D7AD for ; Tue, 7 Jun 2016 09:21:24 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m124so121697348wme.1 for ; Tue, 07 Jun 2016 09:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:mime-version:in-reply-to :content-transfer-encoding; bh=UCQPj9tzu5DoqO0MuVv3so/SBDwAL8ruOPlsxH3DaYQ=; b=YedIbPbZWMfsiGL2hSJDN3Gz+tOquUur/cSz8h1MzdY0d+Si+vKfafQwTRtFuXA2Pu q03NG145LHMJSa6r7QeTGHgWKwmfVzXbJYD7yS+3NEGDYcU92sqTn5HQHSosnpJInym0 CYScx9TLdoJjD5/M5T9RdHyaQ6uiIBM4GsguB2bhbAxbeuqXrBjEOzjTG2wJBM4ioJCj WY8MmE+yqtXhulmLSFfI2/n1PWEZMOeyz/5cPNfxo05jWDFBe+24OBnmGEFP0wHwpNTd hOw/jdkOvf9NI6sn4IxRvw3Zi6iIxRdnJ3MgJMdX2Y4Lt2dmxBDErUlHqgqgP01PrD/L OHIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=UCQPj9tzu5DoqO0MuVv3so/SBDwAL8ruOPlsxH3DaYQ=; b=eH22cR9MlpaUAGtGVIW2rNPIRxuWwmg9UYyEsyiBDYsdWoybqvvyLIUnOufvtcVRSO OrbEXXnbjoCGioYLzMoBmrW9u0/4pM8qKki0rpdIZT8sYNZ4LTrpcXk4BmWxHVpby/fA ZR7lIkzTnx5lRAyNtZzMlNZUODSR8flnfosuoD0dXh0g8OB2Y1kAuW2oU9rYj+F77D5U cHVHKFOI9qcisoCM2oibLD8OLacfEQfhukEdBVHdstOV0UUYHwoMJioFgQPgXJbT/6id Hhup4sImH7pDJ9991VVyMi3pZePzF3p1EQkN5MuDXXX3UKjkUxe8stwTguF19t+cvjrp E5Rw== X-Gm-Message-State: ALyK8tLk6PoEYEprLnh6aUv49/lvzUmTssXvAioSoMZWGabcpFXCB+J910ME22XV2UiTDw== X-Received: by 10.28.103.2 with SMTP id b2mr561473wmc.28.1465316482943; Tue, 07 Jun 2016 09:21:22 -0700 (PDT) Received: from PRDMBP.as59715.net ([2a02:cdc5:9715:22:39cf:c4e4:5aa:46b3]) by smtp.googlemail.com with ESMTPSA id zg2sm11285067wjb.1.2016.06.07.09.21.21 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 09:21:21 -0700 (PDT) Subject: Re: ULA-C [was: Testing ULAness] To: ipv6@ietf.org References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> From: Antonio Prado Message-ID: Date: Tue, 7 Jun 2016 18:21:20 +0200 MIME-Version: 1.0 In-Reply-To: <26441.1465315449@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:21:31 -0000 On 6/7/16 6:04 PM, Michael Richardson wrote: > 1) reverse DNS. > 2) whois. > 3) and the above gives you trackability when the traffic escapes into a place > where it is not wanted. when one needs all of those, why use ULA? so, rather than a special-purpose address block, one should actually get a global unicast address assignment -- antonio From nobody Tue Jun 7 10:26:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E473812D5D1 for ; Tue, 7 Jun 2016 10:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 woXWsOuLEs96 for ; Tue, 7 Jun 2016 10:26:20 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4818712D587 for ; Tue, 7 Jun 2016 10:26:19 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 17:26:18 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 204239CC4E for ; Tue, 7 Jun 2016 10:26:17 -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 :message-id:references:to; s=selector1; bh=krgnJq0MR0a2z2AV7THiS k9K3tk=; b=otrwHP54dIYAiPXgyhSHHcg800cvG0oEtBZlap0BtfbIZFl4nTdry Z91rAWHXGu/MSol9e2D8tFrqBZf3ATIsOhzisuJMWfaU7o/j1ucmDv6G9az7XlX1 Ep46FOsTrz35zUSt0ira1NzqY5etarDxK0gNaafpfCnLiIo9ywnUPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date :message-id:references:to; q=dns; s=selector1; b=LZmpXbwTkcwK8Wt Od2LeW9m485hbuscdJ1dGejmmfOrffNXjpJIfvwZJAfKeFoUSNkKgZTTFKQ+eiuT lv1i7/gzG67iB+2SfLrLMOsuXvaGdTF655KRbhRuJ2559vMW0H+nVwocyfDkdsyP H91POlxGUNtjJCh2P6Z1EhZ7+Gt8= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id D55AB9CC51 for ; Tue, 7 Jun 2016 10:26:16 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 98F1B196D026 for ; Tue, 7 Jun 2016 19:26:14 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_720B67A6-472A-4D2C-A2B5-8B40CD4CB97D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 6MAN IETF96 Call for agenda items X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> Date: Tue, 7 Jun 2016 19:26:11 +0200 Message-Id: References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:26:22 -0000 --Apple-Mail=_720B67A6-472A-4D2C-A2B5-8B40CD4CB97D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A reminder. So far there has only been one item requested. Best regards, Ole > On 23 May 2016, at 10:56, otroan@employees.org wrote: >=20 > The 6MAN chairs are planning the meeting in Berlin at IETF96. >=20 > If you have a draft you would like to discuss, please send your = request for agenda time to the 6man chairs. Please include in the = request, the title of the presentation, file name of the draft, the = speaker's name (and email), and how much time you would like. >=20 > We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. >=20 > We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, > please plan your presentation accordingly. >=20 > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group = are unlikely to get time at the meeting. >=20 > Please have agenda items to us by 15 June 2016. >=20 > Note: Bob has chosen to prioritise sailing to Hawaii over being with = us in Berlin this time. >=20 > Regards, >=20 > Bob & Ole >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_720B67A6-472A-4D2C-A2B5-8B40CD4CB97D 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 iQEcBAEBCgAGBQJXVwO2AAoJED4aXnjSQuKWiw4H/2Wm5tT/KNvFiKhLimqruQ/V CJBzjDur5he5GW6FMFbFRlw5TZ1hHBYn96AUvo20gGj6fc50kxTuu+yVBAOPBfva tQ2PMbIU/xIhiw5upTqK0yOr05oAd4iSL8QHF/d2gdb4bK7qzvG0zdX0BxMNSsXI xav0xenvIOiFbVSLwr//yB1t44I4ZcYtAkduL6D5XIX9r8tHqkmKn37vGBl35cw8 g1/rMdDQ9VGnBr565B7IvBqPw4VoGlwvt2RikDH34zY067IFxqAQBdaNzrBPB/7n eSqmSDnLYjKNebuzAvn36AxrjstSTa1vAo0P6cMhgyHAi+NYX6rMY3PNFg+iQG0= =Ibrp -----END PGP SIGNATURE----- --Apple-Mail=_720B67A6-472A-4D2C-A2B5-8B40CD4CB97D-- From nobody Tue Jun 7 11:19:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393D512D834 for ; Tue, 7 Jun 2016 11:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rUQiIf8IiUtI for ; Tue, 7 Jun 2016 11:19:10 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937E412D833 for ; Tue, 7 Jun 2016 11:19:09 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id s186so55731524lfs.1 for ; Tue, 07 Jun 2016 11:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/EGJMN79VmCx6FT5cuIjW2lM/egUyTFYT3jvR6nM+tM=; b=WBWZUzgy7w4Be3s6f0PlJ/198HaOmO0kOjNPgKaPgtWOi3drkvW+edg2X/7zbMVxRP zaWDrudAO9rzYMIjmfPmj7+KdmXhJ0Im9PnYeouX0KETNVT37gGv6+yoNtHuAuNDCUzI y1ZJZCuHChVibIaAAzS6h7c3meHQ4hKSO0obqCFjI5XdWoUHC+QDlkpwI7/2dsBG1Zqf NEai9s6njHLZ0UjnH/QRhQqPYZBz8mhEyM4Ac2VOo1f7any6y+v8PyBTlJrskHlzl2Ak y8R8RWlusm5hORxFhOhFfiapdS07Z+O6iUdDtMNc9RCL2SNoC85UZSVnblPXnc1Gq7Bu 1ijQ== 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; bh=/EGJMN79VmCx6FT5cuIjW2lM/egUyTFYT3jvR6nM+tM=; b=Dcw0KtNp3RJM7UWbXnsn717PX6POdkbWklDBWb3Gq5GtlqM7qIkNBhhY0G5O/D+FIC YaeTksAOeY2xp73+kR5OajASyLFHOTvMGIDrNLWn4XcGt6JoRHguG7tZdlCRwgBjylKz IZfRTu2/VRAAOLC1yvAW9xHCmf85Ul0OCGrwUWZTkNqxNHLaz4GIyqbOFXLca0OmbFiE Qs1W86bT70ybMjIoMZ58b/eJn42KAw+lb8bLcTiMMerh2PuTzWxHMyQ8a3g25ggXIk8s Nq2XCMjg4wlRBm0Qk8blO+GlK8JEZbLJGIj+WvWdGxsgYU3Hutww/5NPO+yx2e4e1lSB +usg== X-Gm-Message-State: ALyK8tLfQwswRbrGpc2FNtQXvxD3gTjw6iWDDPDv8TYvd11yTAmAqJLrxyeydrfOTj6pSW+pw9thOOREXXgVsA== X-Received: by 10.25.138.11 with SMTP id m11mr2367807lfd.46.1465323547610; Tue, 07 Jun 2016 11:19:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.39.1 with HTTP; Tue, 7 Jun 2016 11:19:06 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Tue, 7 Jun 2016 20:19:06 +0200 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Antonio Prado , 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 18:19:11 -0000 On Tue, Jun 7, 2016 at 6:21 PM, Antonio Prado wrote: > On 6/7/16 6:04 PM, Michael Richardson wrote: >> 1) reverse DNS. >> 2) whois. >> 3) and the above gives you trackability when the traffic escapes into a place >> where it is not wanted. > > when one needs all of those, why use ULA? > so, rather than a special-purpose address block, one should actually get > a global unicast address assignment There are two different, very different views on this, the purely technical and the more realistic view. Why should I go to an RIR and all that when I just need something unique for whatever I'm building? Actual - what RIR should I contact? RIPE NCC where I have my HQ, ARIN where I have my chip and internal system being build or APNIC where it's all put together? I would rather go to a "reseller"/whatever along the line of how domain names are done, and use those addresses. It's unique and due to the nature of the space it will (really should never) show up in the global routing table, it's unique global but only reachable local where I want it to be. ULA also have one other nice property, if I remember (and understand) RFC6724 section 2.1 policy table correct, given a computer have two IPv6 addresses, global and one ULA, it will use ULA for internal communication and global for global, right? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Tue Jun 7 12:03:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9929612D4FB for ; Tue, 7 Jun 2016 12:03: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 fE1ytzVpX6eY for ; Tue, 7 Jun 2016 12:03:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F04312D859 for ; Tue, 7 Jun 2016 12:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z0eulLsggX93WXXcDl7HMJaqGwJ8T4vcMN12bHcWESI=; b=aiujyhWH3rdOw+sOBUCi2+HjtMSMm3G70TAtRekYvHluryRnbTbd/P2GeZojxVUXzvKyyWp+cpmIOlXae51Yew/XcRDGKjAe8TYzMzNmCSCSe+wzlbSdyYBh/EKGfH5eeefR/njFs6PI6s9SkDSduTGs/G0aVKUOxAJop9Lau14= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 7 Jun 2016 19:03:12 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0501.018; Tue, 7 Jun 2016 19:03:12 +0000 From: Christian Huitema To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: possibility of a MAC randomization algorithm Thread-Topic: possibility of a MAC randomization algorithm Thread-Index: AQHRv/miKaFIbwqMfky2HSspoVhIGJ/eWk0g Date: Tue, 7 Jun 2016 19:03:12 +0000 Message-ID: References: <5704F1C8.8010508@gont.com.ar> <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:7::14d] x-ms-office365-filtering-correlation-id: cb0c5a02-575c-4999-24c8-08d38f065f7d x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:iCgXlQUIfB6fATzpUPsCooaSLzBc3/R2TqCNYKo9BLtAxZR1kIV7a0zAGN50S8mH33re0sRqcF680HpzzfbUqMOpevSoTPqZV5AgXMyxPSr30vkc+1DykciKA5832nLujBkmPJSmSldytaMGHvbtlg==; 24:kLWJAosDZL2XSlAswdEQyq0UtCU80SXsVpCifJ5BISE7h7dt9ArzwZgNU7SRKlPOYl1oCDBE8pWUK3JoGXHiuoq+vspwIivgxY/lfyrRQvg=; 7:ddCyhgEhIzHmpR1lWOWqbjrlNfoqafUr5pBQGeVNlNfBuBpAufs9BbImXpx/iKAOS3JvN6Iqcz7WMSqH4WLjoi0CO7cmzdrhGJ2M9VDmC0zSHGmlcsSR14aA9ziHjRr9ntNrdm6jDCF0yICIT+hndrG70/6NQEWWy0AYHazH17ZS+rIKZCOXX5XX71DDj29rT8ziJObfpXKp/yt3elpf/FnNpCr5AYbHuck9Axd81tqZ7BBLfvyB5N+TysMi6pBl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(5008740100001)(189998001)(77096005)(5002640100001)(97736004)(106116001)(10400500002)(81166006)(81156014)(107886002)(5001770100001)(2950100001)(5004730100002)(2900100001)(33656002)(87936001)(105586002)(106356001)(86362001)(54356999)(8676002)(8936002)(76176999)(74316001)(50986999)(2906002)(5003600100002)(19580395003)(122556002)(6116002)(8990500004)(68736007)(9686002)(86612001)(10290500002)(11100500001)(3660700001)(92566002)(99286002)(101416001)(2501003)(93886004)(76576001)(586003)(102836003)(5005710100001)(3280700002)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 19:03:12.2890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:03:31 -0000 On Monday, June 6, 2016 6:45 AM, Alexandre Petrescu wrote: >=20 > Le 03/06/2016 =E0 20:55, Christian Huitema a =E9crit : > > On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote: > >> > >> About the possibility of a MAC randomization algorithm, regardless of > >> being used in an IP address: > >> > >>> we do not control whether MAC addr randomization algorithm is > >>> appropriate or if it is actually possible. > > > > It is certainly possible, since it is shipping in Windows 10. > > > >> The algorithm output should be checked against the authoritative > >> oui.txt, and not generate an existing OUI (organizationally unique > >> id). > > > > There is a potential debate about that. What we are doing in Windows > > 10 is set the "local" bit to true, which means that the OUI does not > > apply. >=20 > But, I understand the use of the u/l bit is no more desirable - it is par= t of an IID > and the IID is opaque: RFC 7136 "Significance of IPv6 IIDs". RFC 7136 relates to IPv6 IIDs. We are looking at the MAC level addresses, a= nd RFC 7136 does not really apply there -- IEEE 802 standards do. As of now= , these IEEE 802 standards do not imply that the OUI is valid for locally a= dministered addresses. > ...=20 > Whereas it does present an analysis on the algorithm, it could further be > improved with the following aspects: >=20 > - it should work not only on WiFi but also on other links which dont > have SSID but do have 48bit MAC addresses (e.g. cellular, USB, > 802.11p, others). The described algorithm uses SSID in the SHA > calculation. Clearly, we started with Wi-Fi because it was the low hanging fruit. The al= gorithm is specific to Wi-Fi, in good parts because there are specific Wi-F= i requirements, such as not forcing your customers to buy a new hotel Wi-Fi= connection every other day. Other media would have different requirements. Cellular is a special case. Cellular connections are tied to cellular ident= ities, e.g. IMEI. If you want randomization there, you have to do the equiv= alent of "replacing a SIM card". That's possible if you have a stack of val= id SIM cards and pick one of them at random, but it is clearly not the same= algorithm as slapping 48 random bits in a MAC address. I do not know the constraints about 802.11p. There can very well be some se= vere constraints there, such as not changing the MAC Address when driving. = That would require a separate study. > - it should check a generated random MAC address does not clash with > existing oui.txt assignments, otherwise it may involuntarily attack > others (pretent to be someone else). No. The local bit prevents that. -- Christian Huitema From nobody Tue Jun 7 12:52:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D468512D195 for ; Tue, 7 Jun 2016 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 frvr1gr0wTaN for ; Tue, 7 Jun 2016 12:52:00 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBF412D504 for ; Tue, 7 Jun 2016 12:51:55 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id z123so105331895itg.0 for ; Tue, 07 Jun 2016 12:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bTGqx5ADeNIlE83Lab3eu4vN8xMIwXqNafhINodwX+c=; b=DeiDomF4XnFPs00t7/mI7MNdizFndckRlyuvQLbxUAAScexpCXhiOKU9yKwv22dhwm BnjpjVZhlGBQhXZ80y2KbYfKRTFm5ba5eUFZIDLsu8EQvktAkMpCuapXOmwCDycwR4bW nK9L7URNSTjmFbyV2pobxt8eAbMOyd514vIRct3Nw/yif4Ayj/2Hvn6vpBfBnWx6ixHP LY0gMeZh1+mwiyxGA66pp4+W+TVbA9yhEwLJl/jtZPQA8hAba8A91dh98Arj8P77z1J5 1MuL1tcSNNnI+0NLzxu5f+AJG1ZZx0/FGdgK6qfI5UKbzZkhKadnvObdnY+ObnWHBMEQ 4UPg== 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-transfer-encoding; bh=bTGqx5ADeNIlE83Lab3eu4vN8xMIwXqNafhINodwX+c=; b=d8TpPCkkaqFdozP4cfQBdXioH9xJJEYAxFJ86KJJIt9HKPfo2j05mxf15ABOVOIb75 N1iJM6mF0/J/uD8qZmL3BvjeHHV5znGATXJH5dVfXnzCRLpWMlhzlyLM/ug/Wf//NdIY ddgnGp6PSR1XrAl81l1ND9zpUlB2fLJvmBgJVHP8Qe7SBuDc4HT6frs2Tu+CIgR6z8YT dVaGbCi+v1EkvQbG0/fUNumzibjy+lIN1J+gyFpiuzgg8K05y2031pVHPqwVHVF6B8lX qdVZKIi88a+eEGnW0LQUqerSJHVaZbqZB7ay+tERgMIisEY2Rp7vsNJawqE2AA4FZw45 +CnQ== X-Gm-Message-State: ALyK8tLTS+uKJliOU5MRcCGhUhsA4D9LxORQ0a3O85mxNDvPcYv7Qi9HsbwjVDJeddgovqySu0DJDVD5tsmVzQ== X-Received: by 10.36.76.148 with SMTP id a142mr2577494itb.54.1465329114872; Tue, 07 Jun 2016 12:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Tue, 7 Jun 2016 12:51:35 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> From: Jen Linkova Date: Tue, 7 Jun 2016 21:51:35 +0200 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:52:01 -0000 On Tue, Jun 7, 2016 at 8:19 PM, Roger J=C3=B8rgensen wro= te: > ULA also have one other nice property, if I remember (and understand) > RFC6724 section 2.1 policy table correct, given a computer have two > IPv6 addresses, global and one ULA, it will use ULA for internal > communication and global for global, right? Yes, and it could be quite handy in some scenarios, such as keeping your network working internally even if your ISP uplink is down. If you use ULA together with GUA (assigned by your ISP(s)), ULAs can be used for intranet communication. --=20 SY, Jen Linkova aka Furry From nobody Tue Jun 7 13:24:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFB12D1C2 for ; Tue, 7 Jun 2016 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 R7YGMukBffRS for ; Tue, 7 Jun 2016 13:24:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3244912D0A8 for ; Tue, 7 Jun 2016 13:24:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bANYL-0000CUC; Tue, 7 Jun 2016 22:24:45 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: ULA-C [was: Testing ULAness] From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> In-reply-to: Your message of "Tue, 7 Jun 2016 20:19:06 +0200 ." Date: Tue, 07 Jun 2016 22:24:44 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:24:50 -0000 >I would rather go to a "reseller"/whatever along the line of how >domain names are done, and use those addresses. It's unique and due to >the nature of the space it will (really should never) show up in the >global routing table, it's unique global but only reachable local >where I want it to be. In the RIPE region you would go to a reseller. It is called 'sponsoring LIR' but there is no practical difference. >ULA also have one other nice property, if I remember (and understand) >RFC6724 section 2.1 policy table correct, given a computer have two >IPv6 addresses, global and one ULA, it will use ULA for internal >communication and global for global, right? Yes, two global prefixes with one of which not announced, would cause a lot of confusion. From nobody Tue Jun 7 16:29:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1E312D812 for ; Tue, 7 Jun 2016 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RvkNZ2CZc21M for ; Tue, 7 Jun 2016 16:29:21 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76A112D658 for ; Tue, 7 Jun 2016 16:29:20 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id c72so4271026ywb.1 for ; Tue, 07 Jun 2016 16:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=zdcXjG1oYtafSK5Hfk96wC9sqHlI2ataIJI68QJTeAk=; b=nD6prQUdnMPlW7KnO3pAOxz7jsVzMrMSuG3qWldcEllIUj1i9etUJihNVD5Qmiv+ov VIxxTY7Vr4l0VUaceQVKX5jIPX203UAExI7tpZHT3pJYS/Qe7TL/gOekP3BWAQaKe7BT vb2LpXGTZTdPJuPieWphk/dIlh3dcqKEXJyzbaJH+z2G8YY+cLkO89pZ9gbHuCLB5M0r RxsFduxLVW6mXTGZ5TK97sxhhfm8wV7jiRHvh00CvNxiivr5W4ghpw/IXvGpX9nn4hZh QWrwekYtI1xlNtihfNtAzAEklpKO5PM0PnzIYtXMx/CVZD8IjFtSuDEzqPCqvDGQbK3H p5fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=zdcXjG1oYtafSK5Hfk96wC9sqHlI2ataIJI68QJTeAk=; b=Zztua1k3+iucVd3VmbuTv5FW6xdo1Sj/ytusbY2Kdpzk0/1K23ekDYxQCNEcPxYW7s +xl4ApaNTc64BAwclOo23xwHzgR6Bv1rNdh1vvtAs9NV0W/RBViEMWNkc1+XayTEjQWG ZV4ReVgW8Syxn6GRoQ9CFbG1y+dXqhx+nuyRr3Xm77BE0TikJujDtYP4z9OVysjIfPi3 FrxDiqXvLlQj7NkIvjdi0d5iY7YxS0eo8nD7LKCEkU/B1SGSYZlSJfXpbprtwl9RG7L8 FrI7I2pm/TGFTTIzYGWfAfTlgO6Nw4POWIBFxlHUL2onujHOtuyuLIdHRgwbFsQKZ2+3 iO/w== X-Gm-Message-State: ALyK8tJspY550ZpJomR99e1qUw6vdxKhvzkt4GT460NwcM7VFhjxsbCiWgRUvskuuJvZJg== X-Received: by 10.13.207.129 with SMTP id r123mr1237761ywd.274.1465340464047; Tue, 07 Jun 2016 16:01:04 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y131sm15715538ywg.18.2016.06.07.16.01.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 16:01:02 -0700 (PDT) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DE7F59AB-78B7-4FFA-9B14-8436072E473B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Tue, 7 Jun 2016 16:00:58 -0700 Message-Id: <0C907356-0163-4B23-8673-A005BC2DF457@gmail.com> References: To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:29:24 -0000 --Apple-Mail=_DE7F59AB-78B7-4FFA-9B14-8436072E473B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it would be worthwhile to file an errata on RFC6890 that = clarifies this issue. Then the IANA registry can be updated. The text = in RFC3890 that defines Global is far from clear to me: o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain. For example, I don=E2=80=99t read that as meaning it has to be in the = global routing table, just that two administrative domains would need to = accept it. I also note that RFC4193 that defines ULAs has a section on operational = guidelines that would be helpful in this discussion. That is, please = read the RFC before responding to the email thread :-) Thanks, Bob --Apple-Mail=_DE7F59AB-78B7-4FFA-9B14-8436072E473B 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 iQEcBAEBCgAGBQJXV1IrAAoJEK7rdBF357uossoH/0zzRihmM32wjDOtSrkhPc+I +a2/DMtxqlbPGNAspDaoTRdiiWJwtVxUDAOn+0tUbZd7YHESb6r5G8D82oFaP2Eh O3tXtuk+Qa4jB/0p/XAY8woIWWspWwoNDkzfq699s0T1WqvatA/9Yei37bHIfWlv OVOl2pB0ATOnXPn+WsR/y0AEuxhsHOV5WSDEpEA1NHTErIO5nezTMDgu0udDDyCt V+YnlI7t8VqGfyJoI1e6eb3lRmGEcdg6I6YOGHHS5LnUxflyYz96HcmHwFazIi9d 7BwKFadXLgJWbJHijroTFjJV6b+z9AdfIqp3q+AHeyXj2/7uPsQfTnyyBqwxEFw= =3pjA -----END PGP SIGNATURE----- --Apple-Mail=_DE7F59AB-78B7-4FFA-9B14-8436072E473B-- From nobody Tue Jun 7 18:10:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D046C12D929 for ; Tue, 7 Jun 2016 18:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p3ow6fCvvsCB for ; Tue, 7 Jun 2016 18:10:26 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0BB12D925 for ; Tue, 7 Jun 2016 18:10:26 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id t190so9260666pfb.3 for ; Tue, 07 Jun 2016 18:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Y0JHLPWWP1dowMf5dTUwMvwFeof4rsuKyECxB6kOdN8=; b=fOBvrJ/JKmqEfjhRfoaZsIYGfLsdQreODESQBDfw1Jrtyyvj25lmx1P47+CbLgmNjc /XK0ePKbetbU2GWNznaFBET/raLRzs4FnQsxqDxxplLK/fVqPDTjv6ILR7yF4SW5VWYL Nt/VoCTM0g/1wvKziOUeqlYQP4MuFJ3f/pSPXCSrVsuD7RKBmZQ4qu+sxlHA5cynjyhS S+CVO/9sydrCQeJL1qN9NNKufSlnkmZ+uJ7hsZ30oBgiOikowjsDG6x9ukC+572orZiw JhX+h/rnHOrXnGZM5hHMSf3JXx8Q1KR55KeFJI53PJ08DcRWA3b8qDvV8Ts/IpKWEn6N e+Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Y0JHLPWWP1dowMf5dTUwMvwFeof4rsuKyECxB6kOdN8=; b=MoUWPNPx6zXFMzNdX/O0zZKa9oErMFTNbZuSUYdvvDoBqiQWc1/INhRQIMKqR7pfvG S2qrllHV8+xo+4bywSupZkj2ecDXdYB6aWy0vGoyx7qqvLDjKnK5Gtt/auxmtqqJK+lD arVp35drTJ1S/2SRdv34Zgs7Z6jkhmPdjALQi6y30tJYCDDFcE8PvJICGUZ08eiQ5FVY YkPamhY5CKDcAOM5rJ3euyn6Q6YS4w1BaEWSNDKRutvHvAW60habIRQnQctAkN+gcjxB RhbLg1b8uSXLpOb/pYHmmOMjCwobsYT/dpIq0JX6S7Wx75/eiY1+BtnOSzziiAyHqTCJ mX6w== X-Gm-Message-State: ALyK8tIIX0VGfXvFfRuZxgV6eqmkWS6ZOW2Tto2efYKieeOaBRl0V+6UXYr04q04TqQn7Q== X-Received: by 10.98.1.6 with SMTP id 6mr2583339pfb.155.1465348225937; Tue, 07 Jun 2016 18:10:25 -0700 (PDT) Received: from ?IPv6:2406:e007:4237:1:6c58:b191:2903:daea? ([2406:e007:4237:1:6c58:b191:2903:daea]) by smtp.gmail.com with ESMTPSA id f187sm37982574pfb.60.2016.06.07.18.10.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 18:10:24 -0700 (PDT) Subject: Re: Testing ULAness To: Bob Hinden References: <0C907356-0163-4B23-8673-A005BC2DF457@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0350a81e-2a9a-d77f-48ad-b90bab819f2a@gmail.com> Date: Wed, 8 Jun 2016 13:10:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0C907356-0163-4B23-8673-A005BC2DF457@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:10:28 -0000 I'm writing a quick draft and I think I'll ask for an agenda slot to talk this through in Berlin. Brian On 08/06/2016 11:00, Bob Hinden wrote: >=20 > I think it would be worthwhile to file an errata on RFC6890 that clarif= ies this issue. Then the IANA registry can be updated. The text in RFC3= 890 that defines Global is far from clear to me: >=20 > o Global - A boolean value indicating whether an IP datagram whose > destination address is drawn from the allocated special-purpose > address block is forwardable beyond a specified administrative > domain. >=20 > For example, I don=E2=80=99t read that as meaning it has to be in the g= lobal routing table, just that two administrative domains would need to a= ccept it. >=20 > I also note that RFC4193 that defines ULAs has a section on operational= guidelines that would be helpful in this discussion. That is, please re= ad the RFC before responding to the email thread :-) >=20 > Thanks, > Bob >=20 >=20 From nobody Tue Jun 7 18:58:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4626912D1BB for ; Tue, 7 Jun 2016 18:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jm5l6BwYPHzI for ; Tue, 7 Jun 2016 18:58:10 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F67F12B00F for ; Tue, 7 Jun 2016 18:58:10 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id y124so23848374pfy.0 for ; Tue, 07 Jun 2016 18:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uqDX7mnNDNCy+Iwx25CZrFIIffd1XGX+y0fDyuoY5KU=; b=JP2jCDRiaUo1olxX2AIdNZMWx8FOxkwmCcDAxOB5XaxF646rn9ukb8NZTYj+ZjWpNc uwUrLjpMyxAFxiJsJIv8TYos75o3w+3QBiYe6gWNLVJCj3dnEQjBkrAgpXCNiRXXfx2B XiSJoQaFJrsVd3lVzkfmnSo2WjOeBDE3yPWIcAVg5u7xmUxou3I6dzRG0Q0PfbClXUW3 yf6BJIXyy/MFgFgPRJ8gjvkQSLVDv0BqAgC+gypxYuKzi3GRuo0Jwz/xucI06KPE/nkv HKB7llS7OK4nG0/e/fLGIK9kUgAjsRrxwjSEzIkb74PKBQNXYr0XAwWXXgtQyEcn0n3L L2Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=uqDX7mnNDNCy+Iwx25CZrFIIffd1XGX+y0fDyuoY5KU=; b=PfgJXTEv45oQTByhXUI1wlNO482x0V9oi4f9+X3iIFtCTXY4q32mwCC9H6qduqQaCr niU5hmPZnIzytgA9j9dvB/nRvAWneuaxXWU3Cirbh9NRoIM+1rIgPp6KXkN8d++ScU/s kpcaMZnh44mFTcwcfuQs2RuyVS0qRc0ZSBbX09EYC5Cd9b1exyPeI062Qd9nHtit1ecw JOXjJ5PfrhMYX/QgpN9Snablbbk+xzsilT2gJnfBqpBWG6ZmQ8UHHNQli4HBJ3kL8pBt gWb0V+tEc4OcjsH3rpW9Dr7zMWgu25+nc2BYr+UjYs9E4Wzk/+SJplMz0otLG0WMG5bE 5jqg== X-Gm-Message-State: ALyK8tJ8ZcK/YOLZeisSOOCcWlXi6ZLslrrdqlOoqkvqwGp8anRY0bOPtrHrLoZ0nqabpA== X-Received: by 10.98.42.206 with SMTP id q197mr2811317pfq.108.1465351089804; Tue, 07 Jun 2016 18:58:09 -0700 (PDT) Received: from ?IPv6:2406:e007:4237:1:6c58:b191:2903:daea? ([2406:e007:4237:1:6c58:b191:2903:daea]) by smtp.gmail.com with ESMTPSA id f24sm38107839pfd.62.2016.06.07.18.58.07 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 18:58:08 -0700 (PDT) Subject: Fwd: I-D Action: draft-carpenter-6man-whats-global-00.txt References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> To: 6man From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> Message-ID: <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> Date: Wed, 8 Jun 2016 13:58:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:58:12 -0000 Comments and suggestions welcome, and if there is enough interest we could perhaps discuss this in Berlin. Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-6man-whats-global-00.txt Date: Tue, 07 Jun 2016 18:53:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : What does 'global' mean in IPv6? Author : Brian Carpenter Filename : draft-carpenter-6man-whats-global-00.txt Pages : 4 Date : 2016-06-07 Abstract: The word 'global' is used in two different ways in various IPv6-related RFCs and an IANA registry. This document describes the resulting problem. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-whats-global/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-carpenter-6man-whats-global-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 8 00:31:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2202A12D84B for ; Wed, 8 Jun 2016 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 lNC_1XxIYlx4 for ; Wed, 8 Jun 2016 00:31:36 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBB912D11A for ; Wed, 8 Jun 2016 00:31:33 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 07:31:31 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 70FA59CC51; Wed, 8 Jun 2016 00:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=Y6idKhIayPAUUAqiHAIPwULNq2M=; b= X74ptQN172iuCxRFNwYZF61Fys8hwjt2Shb/fXCd6qqRBVmLEVg5ungA5wpORDbD +P/hehSopd5beAh/spphFvkf7p6b041fqVyUwugjYN9sCFyn0LtizXDqeNw9yKXQ 2b5e5o+vxhtS/yFdaS3saArHayUtFtlwl0I5RVzaL2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=IkCErRRHCrrG0h99+qOIvwyXa+ fjVGndkI2C96bPDYqwU6PtqQmlkv12hyajJwoeP8ZxVU4pMlOXfDPoU0agMbJYet 74QMJWaQWSuVFb6sq3pQ34VKaHO2gqhqo2rcSn8jBWTzaSCsbmIk6V7G+wlrHp1k l/NdMEo/4ptX58o3o= Received: from h.hanazo.no (unknown [173.38.220.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id F124C9CC4F; Wed, 8 Jun 2016 00:31:29 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B762D19D8033; Wed, 8 Jun 2016 09:31:26 +0200 (CEST) Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_85232E9B-3E0D-4730-BE1F-CA578B5259F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> Date: Wed, 8 Jun 2016 09:31:23 +0200 Message-Id: <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:31:38 -0000 --Apple-Mail=_85232E9B-3E0D-4730-BE1F-CA578B5259F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, > Comments and suggestions welcome, and if there is enough interest > we could perhaps discuss this in Berlin. Thanks for writing this up! I believe if we go back and look at what we tried to achieve it might = become easier. ULAs are globally scoped addresses to ensure that NAT is not needed. If ULAs were not globally scoped, then connecting to networks together = using ULAs could require the use of NAT. We have "defined" ourselves out = of that by declaring them to be globally scoped. Reality might be = different, but that's the political direction we wanted. We did not want ULAs to be globally reachable. Which is why there is the = by default boundary checks on routing advertisements for example. Using = ULAs it would be extremely unlikely that one could engineer global = reachability, although among a set of consenting administrative domains = they can be routed. Global scope =3D We don't need NAT Not global reachability =3D Affects SAS/DAS selection, use in DNS and so = on. 5. Rename the registry column from 'Global' to 'Globally reachable' = (and update text and RFC 6890 accordingly). Seems to clarify the meaning of "Global". Wonder if that could be done just with an Errata. Cheers, Ole > -------- Forwarded Message -------- > Subject: I-D Action: draft-carpenter-6man-whats-global-00.txt > Date: Tue, 07 Jun 2016 18:53:59 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : What does 'global' mean in IPv6? > Author : Brian Carpenter > Filename : draft-carpenter-6man-whats-global-00.txt > Pages : 4 > Date : 2016-06-07 >=20 > Abstract: > The word 'global' is used in two different ways in various > IPv6-related RFCs and an IANA registry. This document describes the > resulting problem. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-whats-global/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-carpenter-6man-whats-global-00 >=20 >=20 > 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. >=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 > -------------------------------------------------------------------- --Apple-Mail=_85232E9B-3E0D-4730-BE1F-CA578B5259F0 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 iQEcBAEBCgAGBQJXV8nOAAoJED4aXnjSQuKWhJcIAJ/4/rcE/hmZvQsPNHH/xn/r f9f10E7anuAWzYVNeqZ/Fz73QiiV6SUHPc35Hhgth16P8VCg1gu9IodL9/VDpXnm qCiqIRKLmWjbicYj1oDmOw//2BCqfzv69v5NGi9EzElRHyf/8le4zRPyCAyarsuV 5OjIi2eDq4iHNgpKgWAU4dvMgS2eEfxBgzPYbHTnj2RqaUUMrQMmPDYynp9QN4eR RYLDS1Pfygt1KEE3Si9xavvkuAci3sDI2snNP2isgMwvTne5q3+GWxs92x0FZ7F4 bsONk+T1GDx8XcWkQ069j6KyL3z2EfKI1JZwaz01HA+v3WOHVQFTdtCJXpJaVt4= =39i4 -----END PGP SIGNATURE----- --Apple-Mail=_85232E9B-3E0D-4730-BE1F-CA578B5259F0-- From nobody Wed Jun 8 01:59:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7512D112 for ; Wed, 8 Jun 2016 01:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 8x_tpe7FJibO for ; Wed, 8 Jun 2016 01:58:59 -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 7F23812D0F0 for ; Wed, 8 Jun 2016 01:58:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u588wvQ5016695; Wed, 8 Jun 2016 10:58:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E305F200F07; Wed, 8 Jun 2016 10:59:27 +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 D5D41209353; Wed, 8 Jun 2016 10:59:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u588wudW011730; Wed, 8 Jun 2016 10:58:57 +0200 Subject: Re: possibility of a MAC randomization algorithm To: Christian Huitema , "ipv6@ietf.org" References: <5704F1C8.8010508@gont.com.ar> <8c64eb44-bdd9-84de-b9fc-6d7281a8ebdf@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 8 Jun 2016 10:58:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:59:01 -0000 Le 07/06/2016 à 21:03, Christian Huitema a écrit : > On Monday, June 6, 2016 6:45 AM, Alexandre Petrescu wrote: >> >> Le 03/06/2016 à 20:55, Christian Huitema a écrit : >>> On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote: >>>> >>>> About the possibility of a MAC randomization algorithm, >>>> regardless of being used in an IP address: >>>> >>>>> we do not control whether MAC addr randomization algorithm >>>>> is appropriate or if it is actually possible. >>> >>> It is certainly possible, since it is shipping in Windows 10. >>> >>>> The algorithm output should be checked against the >>>> authoritative oui.txt, and not generate an existing OUI >>>> (organizationally unique id). >>> >>> There is a potential debate about that. What we are doing in >>> Windows 10 is set the "local" bit to true, which means that the >>> OUI does not apply. >> >> But, I understand the use of the u/l bit is no more desirable - it >> is part of an IID and the IID is opaque: RFC 7136 "Significance of >> IPv6 IIDs". > > RFC 7136 relates to IPv6 IIDs. We are looking at the MAC level > addresses, and RFC 7136 does not really apply there -- IEEE 802 > standards do. As of now, these IEEE 802 standards do not imply that > the OUI is valid for locally administered addresses. Yes, I agree. If the bit locally-administered bit is set then the output may not necessarily need to be checked against oui.txt. The question is for MAC randomization algorithms which dont set that bit. The MAC randomization algorithm in Windows 10 algorithm does set it. There are MAC randomization algorithms (non Windows) which dont set the local bit. >> ... Whereas it does present an analysis on the algorithm, it could >> further be improved with the following aspects: >> >> - it should work not only on WiFi but also on other links which >> dont have SSID but do have 48bit MAC addresses (e.g. cellular, >> USB, 802.11p, others). The described algorithm uses SSID in the >> SHA calculation. > > Clearly, we started with Wi-Fi because it was the low hanging fruit. > The algorithm is specific to Wi-Fi, in good parts because there are > specific Wi-Fi requirements, such as not forcing your customers to > buy a new hotel Wi-Fi connection every other day. Other media would > have different requirements. It makes sense. > Cellular is a special case. Cellular connections are tied to cellular > identities, e.g. IMEI. YEs, but some cellular connections make use a MAC address assigned by IEEE. For example a USB LTE dongle from a particular manufacturer does use a MAC address assigned by IEEE, in addition to the IMEI. > If you want randomization there, you have to do the equivalent of > "replacing a SIM card". That's possible if you have a stack of valid > SIM cards and pick one of them at random, Hmm, right. But I am not proposing to randomize the IMEI and use a stack of SIM cards - too expensive :-) > but it is clearly not the same algorithm as slapping 48 random bits > in a MAC address. I think the same MAC randomization algorithm can be used for the MAC address on the cellular link (on cellular links which work with MAC addresses). But it should use something else than SSID in the parameters of the function to generate the random number. Maybe some parameter specific to the cellular link, similar to SSID. > I do not know the constraints about 802.11p. There can very well be > some severe constraints there, such as not changing the MAC Address > when driving. That would require a separate study. Hm, yes there are some specific requirements there. Not changing the MAC address while driving could be a good requirement too. But here I am thinking about the privacy requirement. For example, the freely-available "Status of the DSRC Technology and Applications: Report to Congress", year 2015, says on its page 26 that "the BSM [a vehicle-specific message on top of 802.11p beaconed by every vehicle] contains no personally identifying information or information that could link a message directly to a driver, motor vehicle owner or the motor vehicle itself (such as VIN or license plate)". The OUI in a globally-administered MAC address could be such information, because it reveals the manufacturer of the 802.11p card. And, this could help identify the brand of the motor vehicle, by means of various associations common in the car industry: e.g. because all Fords use Huawei cards (as they all use Bridgestone tyres) this BSM message means there is a Ford at this coordinate at this time. So the requirement would be to use a random (although stable) MAC address in these BSM messages. The other peculiarity in 802.11p is that there _is_ an SSID but it's always "ff:ff:ff:ff:ff:ff" - it's called the 'wildcard' SSID. So, in this sense, the SSID would always be the same in the SHA-256 function parameter of your MAC randomization function. This may be ok, or irrelevant, or superfluos, I dont know. >> - it should check a generated random MAC address does not clash >> with existing oui.txt assignments, otherwise it may involuntarily >> attack others (pretent to be someone else). > > No. The local bit prevents that. I agree. So the algorithm should set the local bit. Algorithms who dont could check oui.txt. Alex > > -- Christian Huitema > > > From nobody Wed Jun 8 03:17:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0D212D1B3 for ; Wed, 8 Jun 2016 03:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OerC-xsQai6s for ; Wed, 8 Jun 2016 03:17:05 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1C912D096 for ; Wed, 8 Jun 2016 03:17:05 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v199so56539462wmv.0 for ; Wed, 08 Jun 2016 03:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=SwDPMTq3KDQN49sPpL6CMyz1zqdbUrue3L+no4DDuIo=; b=ryalAfBBqsbJe/6KelxzOq4il3tWsfpWvM+RhhiVinOz7V/oFKjubPjV8kXAW8+22B 1YBhSamvV9gxom8TndVIGvsj7OEJI1CxuMN2u/VEwQuxtcbBz6Wy4cCUanx9EqlXVX7Z yWyUAM9F9TFB9siPuC7RCG7oqZpMPFddXOmaCjZeHin+6AJQspn/JC8A70fGCcec2zd/ SwuC1Pwi6gWOJYyNoHOaXdsRn/vqTTpvEtcAcedN2pL9wYs2jYEwlULaCfbkohHDei2E AlpL3el+/5S4Wd8hixtn/EoDcPjOpFbJmYXTZcTucSayAYo8Ma9kJekfCgIo13vFs4VH UgEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=SwDPMTq3KDQN49sPpL6CMyz1zqdbUrue3L+no4DDuIo=; b=WBNrMVbAIeuOLqCOL7qVyNtHy+BrO1Uxat22nB5ENnd8Pl47GVt+G5/KKd5ux6jAJk 3zoH1Belg97fK6x7eL6V5nSr2L5fzPbxfc09pMD8VGX4Rfqym0qNn9vbrmR9lzszjElK ShfGNW5FCm+LKucaZc8dHkabQTFNm1hWAa0YYtwnJh97gtoT5fcVXprF+HTji37Q9CoX pg9lf5kJ10ZcoTE+/nVZNIEtKmSokkDR4d/NufcIflMWbHcTkAIMd9QtgMTJ5K5ILrX/ PIJJ86R0zlmh6FRDRdsiJsgOVczRPZT1mqZUL0DLD28nohwGUtT6ZtI3h1pKGRZDf//d MFPw== X-Gm-Message-State: ALyK8tIvYoHWNCWwYVEfBELV/HvBF6Ul0tBJ6UaHkRkPtOAn/424sQlMAgu9H4qDiZuUPw== X-Received: by 10.194.116.195 with SMTP id jy3mr3642244wjb.137.1465381023895; Wed, 08 Jun 2016 03:17:03 -0700 (PDT) Received: from PRDMBP.as59715.net ([2a02:cdc5:9715:22:c0d6:5e8e:6443:6b73]) by smtp.googlemail.com with ESMTPSA id r76sm1258595wme.14.2016.06.08.03.17.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 03:17:02 -0700 (PDT) Subject: Re: ULA-C [was: Testing ULAness] To: =?UTF-8?Q?Roger_J=c3=b8rgensen?= References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> From: Antonio Prado Message-ID: <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> Date: Wed, 8 Jun 2016 12:17:02 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:17:07 -0000 On 6/7/16 8:19 PM, Roger Jørgensen wrote: >> when one needs all of those, why use ULA? >> so, rather than a special-purpose address block, one should actually get >> a global unicast address assignment > > There are two different, very different views on this, the purely > technical and the more realistic view. of course it depends on your use case. btw, if I had a use case where rDNS, whois, 'trackability' (whatever you mean by that), I would go for GUA and I would not use ULA for internal communication, as second addressing scheme either (according to kiss rule) but I understand that some scenarios would benefit from ULA deployment -- antonio From nobody Wed Jun 8 04:43:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4B212D5F2 for ; Wed, 8 Jun 2016 04:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Du461bzSNU37 for ; Wed, 8 Jun 2016 04:43:21 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FE312B024 for ; Wed, 8 Jun 2016 04:43:19 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 11:43:18 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1F7FA9CC4F; Wed, 8 Jun 2016 04:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=FYuTG9Ro8uZ9ioPh7e53h2NpfvA=; b= egFso6H27tKqaDshw/6tDKzG82GvzZzb5/61iJHHsckfGwumbyYkuGbJ3Bbhybgi DOIs6y6ErLYBHKlgNAys+6Le4DKz2cLoGXA/JGp3anIkkcZ3jfXKeb/wJmkLdXgH vfxtxEQY8Bp7XjcABPvF/9lKCk/0bHtbGPnC7NZDOwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=cwXriAXiE35qqsnF/rkOv+RqDT bO2S1eHZBjTMUI3tHijbbGm9QEpV3AH0L51olp2sVzuAfMY32QYCvc8ujATP07RY Uj9VdeMQy65Bv2LJ+0h5zRjM1lUSW/iFuF83mC9liz5EXPo+SyKATQS0TvAbZC1s HsIQYx1eolNJAxbKk= Received: from h.hanazo.no (unknown [173.38.220.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9A5449CC4E; Wed, 8 Jun 2016 04:43:16 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 43FF51A455D2; Wed, 8 Jun 2016 13:43:14 +0200 (CEST) Subject: RFC2460bis WGLC comments Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7299B0F7-36D2-46FB-8A4F-31D39E194D4A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Wed, 8 Jun 2016 13:43:10 +0200 Message-Id: <3900E424-C491-45FD-BD10-4F8E3943A352@employees.org> References: To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:43:23 -0000 --Apple-Mail=_7299B0F7-36D2-46FB-8A4F-31D39E194D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read through the change set and have the following comments: 1. Update reference to working group document: [I-D.hinden-6man-rfc4291bis]. 2. HBH header handling. 2460bis relaxes the must to a should. And incorporates a paragraph from = 7045 giving performance considerations. The use of a _should_ process combined with a _may_ drop is not elegant. The second paragraph can also be read as a licence to drop. After having thought about the text in = draft-ietf-6man-hbh-header-handling, I propose the following instead: OLD: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that should be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. It should be noted that due to performance restrictions nodes may ignore the Hop-by-Hop Option header, drop packets containing a hop- by-hop option header, or assign packets containing a hop-by-hop option header to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. NEW: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by nodes along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While RFC2460 required that all nodes must process the Hop-by- Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. In short replace the should we a may, making HBH options header purely = optional. Note that section 4.8 in 2460bis already uses a may. I also suggest we remove the 7045 paragraph on performance = considerations, that's highly subjective. 3. Section 4.3 HBH OLD: The Hop-by-Hop Options header is used to carry optional information that should be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, and has the following format: NEW: The Hop-by-Hop Options header is used to carry optional information that may be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, and has the following format: Same change as above. 4. Fragmentation. We need more people to review the rewritten fragmentation section. Are people comfortable with these new names on the parts? +------------------+-------------------------+---//----------------+ | Per-Fragment | Extension & Upper-Layer | Fragmentable | | Headers | Headers | Part | ------------------+-------------------------+---//----------------+ I kind of think the old terms where clearer, but it might just be what = I'm used to. Ole --Apple-Mail=_7299B0F7-36D2-46FB-8A4F-31D39E194D4A 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 iQEcBAEBCgAGBQJXWATSAAoJED4aXnjSQuKWKp8H/3bmrAU6NpjDx69Ldw2AksWF FCiFpk4ZsLw477x18hIBox6BgRW2bjSf6k1tofUpuepZKsdRl0qoTZYvbtM0/bas CPS1LNGBel3yP/aLlnUhhuuQUYym76rtXEQHGsGaJQPBAB7HiG79j9KSljS44RVR 7q0Xpu732KoJGzO4aw0+dSpGf1GpsQGh7yOrU9pfOVcHEgxzwzzlEoDo3DNw00Wj skOvY+yQuXKqXbiGWPvw6a4y2Yta0ueS43S2pjRSMWT0o0Bv2bU+AM1KgluyJnTB MoF/O9/L7ftEyBHpvFFs+TNa5C08/uHxZ9OvPQ8wqflJ0hEmeTw08W/pzG9VVF4= =LJ43 -----END PGP SIGNATURE----- --Apple-Mail=_7299B0F7-36D2-46FB-8A4F-31D39E194D4A-- From nobody Wed Jun 8 05:01:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EA12D8BC for ; Wed, 8 Jun 2016 05:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 pijgYy1ZMg2k for ; Wed, 8 Jun 2016 05:01:28 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851F512D8B7 for ; Wed, 8 Jun 2016 05:01:27 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 12:01:26 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 707749CC7C; Wed, 8 Jun 2016 05:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=YkeckzdZZli8ilt3qTj+cDKbam4=; b= E5OePptQiUqWu4r9xDjt4fDuMhlxEfnPYm5vY8kNHFIkip4vc7taofuo7d90AysZ +DUgrpig5M8O/5DrDza7X4B/6SOeRC4pr6DkwiR7x3fcEoBnbXEVQySaPnAK84D4 nn8v4qUuWdUsoz56Yrq2zy8WKGsBMOZen7vdP/sCNUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=parjQSleGyP7T0878xx5cLdoHS 8pfKK8EcJSDBD8zQDqFGvcHFr9N3MELzmjAfB+ajzNwfuxI+2qBIaMFA8pVirl6M KpPAOor/yIaUMY6IJ4Ilt62+uoS/rt9M6neWmj+c9Hyl4yzkO/wc/QDTNFiw61Rd 4WAUrz4ocWbW4YL80= Received: from h.hanazo.no (unknown [173.38.220.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 3AE0D9CC4E; Wed, 8 Jun 2016 05:01:25 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6FE541A4D1EF; Wed, 8 Jun 2016 14:01:22 +0200 (CEST) Subject: RFC1981bis WCLC comments Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_75ACD6BA-0C34-4502-8E43-E0C68273B3FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Wed, 8 Jun 2016 14:01:19 +0200 Message-Id: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> References: To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:01:30 -0000 --Apple-Mail=_75ACD6BA-0C34-4502-8E43-E0C68273B3FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read through the change set and have the following comments: 1. s/proper MTU/path MTU In the following paragraph: An extension to Path MTU Discovery defined in this document = can be found in [RFC4821]. It defines a method for Packetization = Layer Path MTU Discovery (PLPMTUD) designed for use over paths where = delivery of ICMP messages to a host is not assured. In this algorithm, = the proper MTU is determined by starting with small packets and = probing with successively larger packets. The bulk of the algorithm = is implemented above IP, in the transport layer (e.g., TCP) or = other "Packetization Protocol" that is responsible for determining = packet boundaries. 2. ... forwarded by some node (regardless of whether it decrements the = Hop Limit) along the path How can "regardless of whether it decrements the Hop Limit" be = misunderstood? Should a bridge do PMTUD? ;-) If this is for RFC4389, it is already described there. I do wonder if we = should drop this "clarification" from 1981bis as it seems a little = 'disclarifying' to me. Albeit correct in the ND proxy case. How did that = experiment go btw? ;-) Ole --Apple-Mail=_75ACD6BA-0C34-4502-8E43-E0C68273B3FC 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 iQEcBAEBCgAGBQJXWAkSAAoJED4aXnjSQuKWSmMH/jc2D5fmPmKElB9Ce4BRqsAC zqBT00Pe5VCzvjm1wP7lo716gwzhwWhRba57atQ6kj3phVNKS3T6ix6rt5VdMdn9 uWshrBwAzObbT5+wfSuz+n57XqNgwj9XE6dJ9SJaT/1Ik4MXM8qXaQtTfYEtwSk1 iHNe+iFSFZ90YyvMoLGSAy0yXwhokalZk24j0dDt7SWTWxW7AuBIf6uSQJqv6brE SvO6d1Obyt7QOmTiBH/0gjKrbjorUG/vuU8OUwUWDJmzvLQWLGHjTZWI2xZzQ6dv IBA0pft/Q7GX1RGA0d0RC6WrImcxqRlheyT3NW6d85bBactUeqFKzKJH8zlhPv0= =B1J5 -----END PGP SIGNATURE----- --Apple-Mail=_75ACD6BA-0C34-4502-8E43-E0C68273B3FC-- From nobody Wed Jun 8 05:40:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948E712D53D for ; Wed, 8 Jun 2016 05:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xL91f6tXm-D1 for ; Wed, 8 Jun 2016 05:40:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B1C12D1EA for ; Wed, 8 Jun 2016 05:40:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B412009E; Wed, 8 Jun 2016 08:48:02 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 19448638BF; Wed, 8 Jun 2016 08:40:53 -0400 (EDT) From: Michael Richardson To: Antonio Prado Subject: Re: ULA-C [was: Testing ULAness] In-Reply-To: <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Date: Wed, 08 Jun 2016 08:40:53 -0400 Message-ID: <28524.1465389653@obiwan.sandelman.ca> Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:40:56 -0000 Antonio Prado wrote: > of course it depends on your use case. > btw, if I had a use case where rDNS, whois, 'trackability' (whatever you > mean by that), I would go for GUA It's very confusing for users, administrators and applications. Source address selection rules don't really accomodate two GUAs with different reachability. We've had verious proposals to deal with this (including shim6, which I still lament), and HappyEyeBalls helps, but we need better rules in the host stack. Source address selection rules would seem to be easier to apply when you have ULA reachability for internal communication. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Jun 8 05:41:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9412812D8BC for ; Wed, 8 Jun 2016 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oM3EI_dnt4Bq for ; Wed, 8 Jun 2016 05:41:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC2012D865 for ; Wed, 8 Jun 2016 05:41:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A297A2009E; Wed, 8 Jun 2016 08:48:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B22BC638BF; Wed, 8 Jun 2016 08:41:15 -0400 (EDT) From: Michael Richardson To: Antonio Prado Subject: Re: ULA-C [was: Testing ULAness] In-Reply-To: <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 08 Jun 2016 08:41:15 -0400 Message-ID: <28635.1465389675@obiwan.sandelman.ca> Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:41:17 -0000 --=-=-= Content-Type: text/plain Antonio Prado wrote: > of course it depends on your use case. > btw, if I had a use case where rDNS, whois, 'trackability' (whatever you > mean by that), I would go for GUA It's very confusing for users, administrators and applications. Source address selection rules don't really accomodate two GUAs with different reachability. We've had verious proposals to deal with this (including shim6, which I still lament), and HappyEyeBalls helps, but we need better rules in the host stack. Source address selection rules would seem to be easier to apply when you have ULA reachability for internal communication. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1gSaYCLcPvd0N1lAQJkyAf/dqj1bfJjrnI0+zlLe0r7leiYUkxQBYCm 0e9Zj6hoRTUAvhfUqCxKmCL7kP0cq4S1kC/uAxxiT0hcAZ3dfPyKB3cC9KXXS1j1 /fizscgoROiGiDyt/JigepDoPMXHpidYZct35HRTY+qlG8MaoJw6c2UWYNaZckTh 15OaMd5PkrirSV+hSoUfyE0rmDRadKmDESz9eV7jNWn8eBfahG93qVGzRMtLwB0M ySdG3mDLiXi5OOPnrjHFYVRZZgDs6njD90FgEUqNVBuvkqBhOQA4p/EHFI6mlw5m dHSQNmKzqH34t5EyArAUX0kcuWZFVzo8ypOt8dy1iJdu7YAErI4p6A== =P2TM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 8 05:45:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F73B12D8C2 for ; Wed, 8 Jun 2016 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 UbdaN4hX5bET for ; Wed, 8 Jun 2016 05:45:15 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A2612D8C0 for ; Wed, 8 Jun 2016 05:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2355; q=dns/txt; s=iport; t=1465389915; x=1466599515; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=6KWMk/K874hWduuPNbS4QaO+ooKY3CntroqgbScNX0E=; b=Owx2GdCwQ/dlyQiTNOIB5umTeZaXNvqDktuuLy7Rs/L8jPtVo+qQAowt mPzFb2FsEFyIToUNqVnKr2QSyn4gSUhqEGH9XZv643ZwqpzKyNrdhetYA SuuFBX1NJsffnkwCYLEmwDNucwnn2ajjSGjuGri/nFKh0V7E2Py6Bwihm o=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnBADhElhX/xbLJq1dgxG9CoF5hhMCg?= =?us-ascii?q?XkSAQEBAQEBAWUnhEYBAQMBeRALDjhXBog6CAG9MAEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQ4OhieBdwiCTodsgi4BBJhPgy2KeY8fj2ElAS6CAoFuinsBAQE?= X-IronPort-AV: E=Sophos;i="5.26,439,1459814400"; d="asc'?scan'208";a="635057375" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 12:45:13 +0000 Received: from h.hanazo.no ([10.61.144.194]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u58CjDru028042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2016 12:45:13 GMT Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 180EB1A5FE08; Wed, 8 Jun 2016 14:45:13 +0200 (CEST) Subject: Re: ULA-C [was: Testing ULAness] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_311A7B07-9F53-4A22-BB0C-0ABBA7D288CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Ole Troan In-Reply-To: <28524.1465389653@obiwan.sandelman.ca> Date: Wed, 8 Jun 2016 14:45:12 +0200 Message-Id: <37C11182-CAE8-42C5-9252-BE648EB05932@cisco.com> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <6ebf6f69-4fe8-e760-ba7c-c4ab285bb185@gmail.com> <28524.1465389653@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:45:17 -0000 --Apple-Mail=_311A7B07-9F53-4A22-BB0C-0ABBA7D288CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, >> of course it depends on your use case. >> btw, if I had a use case where rDNS, whois, 'trackability' (whatever = you >> mean by that), I would go for GUA >=20 > It's very confusing for users, administrators and applications. > Source address selection rules don't really accomodate two GUAs with > different reachability. We've had verious proposals to deal with this > (including shim6, which I still lament), and HappyEyeBalls helps, but = we need > better rules in the host stack. >=20 > Source address selection rules would seem to be easier to apply when = you have > ULA reachability for internal communication. I just don't see how better rules can solve the problem in the general = case. Good rules is good. But we need approaches like HE, and smarter = transport / session layers like MPTCP or MOSH, where you could have some = probability or preferences to likely succeeding SA/DA pairs, but you'll = fall back to throwing spaghetti on the wall pretty quickly. Ole --Apple-Mail=_311A7B07-9F53-4A22-BB0C-0ABBA7D288CE 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 iQIcBAEBCgAGBQJXWBNYAAoJEOWlEikwYRclnWkP/i+cteRtKlnU9PiesSYTdjYR NztjnZmgSSVOwnvgqnEsNgmFnL4j82PncGHj05PSDbYesc1noJdGwSyYXIG1py7V 8+FssIA3qvyqRw/DMizD78DQ6sxwzSVD0T7GDKGqqb5a8nexkr+QKQ9odEbmZUr7 hvOvX81Fgx9AjOZDqkXX3p0Y59QeHXHPKuOlAXN3AsrMSdHURtnwnUj+IuL5R9CP 4G7G0B50RYwk+8auxP5PABhva3sLH6hsWgO7FuSVtKu/6CN65ODIDBzsGkJmhhZj 5YZPnwAjRGzYiOYrzerG/MVBCNJrEqyU1n2GNaVdn84TcYAQtnlYBPFzvAF1D/rS Ik8cAfSPyyFHCbPsSOiPa6DDqUg+FIeNO4w8Xh08ibuPN170AoengvL8XWgkpSYq 4K+iJoaFQkXJuYdJnZt+V/w/FblTeHfa+Y10SJTp9lQ1riG11LoXSM480a2Xs39U pAJiZllSECklRKRW+xQJIoUBDsXG4aNf4nWdhyoycVPgHMmWubs6xhujiVoaib19 abDqMHeTYORlAA+V4tED26LhYcehnP5KW3wgDx+Qwbko9nBz/rGW2E5NwQBq1/Jl 9c5RCf3bYfH8kahn91wWYX7DNfmRKxGcC6/3wCeAL4EBx5IetIxgeywXKWUwDxuy fyPtZTfelRKEUge6r4Fz =pjtP -----END PGP SIGNATURE----- --Apple-Mail=_311A7B07-9F53-4A22-BB0C-0ABBA7D288CE-- From nobody Wed Jun 8 06:19:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7812B12B060 for ; Wed, 8 Jun 2016 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 KsCUp5_TweLi for ; Wed, 8 Jun 2016 06:19:42 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4063212B03D for ; Wed, 8 Jun 2016 06:19:42 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x189so6853004ywe.3 for ; Wed, 08 Jun 2016 06:19:42 -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; bh=HGDcoORiDUlOg3NrdivC0cmiMm4ZOdrYxJzN4RbW+eM=; b=fBFk1hrlVsLzNlQEu9r80HuZO4ZQJIUQVPTHdhvmkh0Vtjy1rJETuaw4+wwlixq9Vr Pb7ZiAR4nl8UpAf+Cb6w48qE3UMAv7OYebjf1YzbyRbe9eFF06pFsnRYnY4Zkz/rWo2Y RjyG1LkesWMrhanN/TvvcSu6Am+QC9nt+/nYTcQ4klnOlCRXT8d95dKHHVGyVm5FIxAD ebcTZMOhMfaTYjH8IYJZr3VNo1SXxf+nPFSGTX8b5op8Ds1oQspgRXipFf9L6bnxxvyT Or3439xFAUABHu87yz0Gnq4yYj+JXPNhEtoKqNsSnOskYaFPCY4xkQC8bJTAiVCHk2IA hdtw== 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; bh=HGDcoORiDUlOg3NrdivC0cmiMm4ZOdrYxJzN4RbW+eM=; b=i6FeMBeOA6Kx9x6m2nY6FdzzGO4aOrYco42L5sG0jSlrmSFc1ciEXn1Yux1A4vG/Gc Q9up5Ug2IWjxMhhiyaP8YOUfeivMjpZlyUoLNDKWV6bFteH1EdGGBttxadDO2+GVupw+ 441gmHI0A/UKlrsB2ebf8rzq7BiWat1FCE/Qo9bJAbkHNMwtMiAk6yMYx5BI0TU21Y4a u047UAc37pN/UB0ACUc9u/vIB5PIFprEMeEAV585lxyeRL+wv+ZD46JDWv3zUEvnGl6I k9MrFL8ZsMt1yWPETPW8Zp1QwjtH6h8j6mCMFqEZKWuJWLcUxLF63ZYeC0UIQnrmwkNk NttQ== X-Gm-Message-State: ALyK8tKxxKE6mHHhIX7L8ApyFpo0QzXjaJ9GbCJ4IRqDzIGoF7CudUIEC2LYy3l0ZCsa29ELX3uYfAb7K3gvGyEl X-Received: by 10.37.228.198 with SMTP id b189mr2617983ybh.25.1465391981316; Wed, 08 Jun 2016 06:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Wed, 8 Jun 2016 06:19:19 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> From: Lorenzo Colitti Date: Wed, 8 Jun 2016 22:19:19 +0900 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Jen Linkova Content-Type: multipart/alternative; boundary=001a114bc1c681543f0534c428f6 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:19:47 -0000 --001a114bc1c681543f0534c428f6 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 8, 2016 at 4:51 AM, Jen Linkova wrote: > > ULA also have one other nice property, if I remember (and understand) > > RFC6724 section 2.1 policy table correct, given a computer have two > > IPv6 addresses, global and one ULA, it will use ULA for internal > > communication and global for global, right? > > Yes, and it could be quite handy in some scenarios, such as keeping > your network working internally even if your ISP uplink is down. If > you use ULA together with GUA (assigned by your ISP(s)), ULAs can be > used for intranet communication. > Note that the specs say that by default the global address should be used. Otherwise you'll have problems like "host x in ULA A tries to connect to host y at ULA B and fails, even though both x and y have global addresses that can reach each other". --001a114bc1c681543f0534c428f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 8, 2016 at 4:51 AM, Jen Linkova <furry13@gmail.com> = wrote:
> ULA also hav= e one other nice property, if I remember (and understand)
> RFC6724 section 2.1 policy table correct, given a computer have two > IPv6 addresses, global and one ULA, it will use ULA for internal
> communication and global for global, right?

Yes, and it could be quite handy in some scenarios, such as keeping<= br> your network working internally even if your ISP uplink is down. If
you use ULA together with GUA (assigned by your ISP(s)), ULAs can be
used for intranet communication.

Note t= hat the specs say that by default the global address should be used. Otherw= ise you'll have problems like "host x in ULA A tries to connect to= host y at ULA B and fails, even though both x and y have global addresses = that can reach each other".
--001a114bc1c681543f0534c428f6-- From nobody Wed Jun 8 07:04:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69812D661 for ; Wed, 8 Jun 2016 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, SPF_PASS=-0.001] autolearn=no autolearn_force=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 IJjpWag07OUH for ; Wed, 8 Jun 2016 07:04:08 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3FB12D989 for ; Wed, 8 Jun 2016 07:03:13 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4A9968009B; Wed, 8 Jun 2016 16:03:07 +0200 (CEST) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: otroan@employees.org, Brian E Carpenter References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <574E1238.1000506@si6networks.com> Date: Tue, 31 May 2016 19:37:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:04:10 -0000 On 05/30/2016 04:00 AM, otroan@employees.org wrote: >> 3. Update to RFC4941 >> >> The temporary addresses specified in [RFC4941] MAY be used alone, >> without configuring any stable addresses. In particular the word >> 'additional' is deleted from bullet 2 in Section 3 of RFC 4941. > > do we agree that the privacy of a given address is compromised as > soon as it is used in a way that identifies the user? It's not black or white. e.g., maybe the address is not tied to an identity... but it might b useful for an attacker to correlate network activity. OTOH, an app with no identity linkeage might use an address for multiple similar apps (and this might seem beningn), but then another up which *does* link to an identity uses the same addresses, and the former apps now become linked to an identity. In "paranoid mode", you'd use "throw away connections" (this is mentioned in the id), but this obviously has implications -- including implications to the network. > that would imply that any address used to reach facebook, google, etc > is tainted and cannot be used for any other connection. > > pretty much all my devices have umbilical cords back to the "cloud" > for applications, software updates, management, data dumping etc. > those cords are also connected to an identity. > > I'd argue that there are no deployed hosts / application combinations > that can only use privacy addresses (they might use privacy addresses > as short lived stable addresses, but in that case they would be > better off with stable addresses). We agree. At the end of the day if you really care about network activity correlation, privacy addresses simply last for too long. At which point, you might wonder if they are worth the hassle. > if the consequence of this is that a temporary address can only be > used within a single connection, then I can guarantee you that there > will be many networks that will not support that. bridges do not have > unlimited space. Agreed. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 8 07:05:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0792A12D638 for ; Wed, 8 Jun 2016 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, SPF_PASS=-0.001] autolearn=no autolearn_force=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 AI9EvHyy-Vuz for ; Wed, 8 Jun 2016 07:05:15 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDAE12D58C for ; Wed, 8 Jun 2016 07:05:15 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 62E958009B; Wed, 8 Jun 2016 16:04:52 +0200 (CEST) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Lorenzo Colitti , Ole Troan References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> From: Fernando Gont Message-ID: <574E1290.8030809@si6networks.com> Date: Tue, 31 May 2016 19:39:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:05:21 -0000 On 05/30/2016 04:12 AM, Lorenzo Colitti wrote: > if the consequence of this is that a temporary address can only be > used within a single connection, then I can guarantee you that there > will be many networks that will not support that. bridges do not > have unlimited space. > > > But some can. 3GPP mobile networks and > draft-ietf-v6ops-unique-ipv6-prefix-per-host networks, need not be > limited. Residential networks aren't limited but they might have space > for thousands of ND cache entries, so thousands of addresses. If host gets s single prefix, you just track the prefix. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 8 07:09:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3E12D8E7 for ; Wed, 8 Jun 2016 07:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_PASS=-0.001] autolearn=no autolearn_force=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 Red9nN4nEXc5 for ; Wed, 8 Jun 2016 07:09:07 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3FB12D665 for ; Wed, 8 Jun 2016 07:09:07 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 57AAF805F8; Wed, 8 Jun 2016 16:09:02 +0200 (CEST) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Brian E Carpenter References: <392a5c46000f4c3391e5bd101276bea4@XCH-RCD-008.cisco.com> From: Fernando Gont Message-ID: <57572687.6010202@si6networks.com> Date: Tue, 7 Jun 2016 21:54:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:09:08 -0000 On 06/02/2016 02:19 AM, 神明é”哉 wrote: > At Thu, 2 Jun 2016 08:47:49 +1200, > Brian E Carpenter wrote: > >> The reason for that text (which I and others assert is a clarifcation >> of the intent of RFC 2460 and its predecessor RFC 1883) is to make >> it clear that such insertions are not OK. The reasons that they are >> not OK have been discussed here several times. The fact that such >> insertions and deletions can be made to work inside a closed domain >> doesn't make them OK for general use on the Internet. > > +1. > > I've stated my points on this several times, so I won't repeat them in > detail, but the "rationale" for leaving it unclear referring to > "interop issues" simply doesn't make sense to me. I'm happy to hear > the discussion on revisiting the original intent as an update to > rfc2460bis, but for the scope of rfc2460bis itself clarifying it is > the right thing to do. +1 Thanks -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 8 07:38:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699E812D672 for ; Wed, 8 Jun 2016 07:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 hXQqd8PPpWxh for ; Wed, 8 Jun 2016 07:38:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 58B1612D647 for ; Wed, 8 Jun 2016 07:38:09 -0700 (PDT) Received: from mb-2.local ([172.58.33.111]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u58Ebp1v078730 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 8 Jun 2016 14:37:56 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [172.58.33.111] claimed to be mb-2.local Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: Fernando Gont , otroan@employees.org, Brian E Carpenter References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> <574E1238.1000506@si6networks.com> From: joel jaeggli Message-ID: Date: Wed, 8 Jun 2016 07:37:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <574E1238.1000506@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rnp37wt1E6cUb8cQCeVfF6tGuRClLBtkd" Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:38:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rnp37wt1E6cUb8cQCeVfF6tGuRClLBtkd Content-Type: multipart/mixed; boundary="PeXMB7uLDcC0J4OpuIXKNeimpxc6WJuor" From: joel jaeggli To: Fernando Gont , otroan@employees.org, Brian E Carpenter Cc: 6man WG Message-ID: Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> <574E1238.1000506@si6networks.com> In-Reply-To: <574E1238.1000506@si6networks.com> --PeXMB7uLDcC0J4OpuIXKNeimpxc6WJuor Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/16 3:37 PM, Fernando Gont wrote: > On 05/30/2016 04:00 AM, otroan@employees.org wrote: >>> 3. Update to RFC4941 >>> >>> The temporary addresses specified in [RFC4941] MAY be used alone,=20 >>> without configuring any stable addresses. In particular the word=20 >>> 'additional' is deleted from bullet 2 in Section 3 of RFC 4941. >> >> do we agree that the privacy of a given address is compromised as >> soon as it is used in a way that identifies the user? >=20 > It's not black or white. e.g., maybe the address is not tied to an > identity... but it might b useful for an attacker to correlate network= > activity. In many cases where useful work is done, the act of using an address to send a packet or establish a connection identifies you to the endpoint that is the recipient. this is inherent in the id/locator role of ip addresses. throwing them away after use doesn't eliminate that identifier role, it does make them less useful as locators. > OTOH, an app with no identity linkeage might use an address for multipl= e > similar apps (and this might seem beningn), but then another up which > *does* link to an identity uses the same addresses, and the former apps= > now become linked to an identity. >=20 > In "paranoid mode", you'd use "throw away connections" (this is > mentioned in the id), but this obviously has implications -- including > implications to the network. >=20 >=20 >=20 >> that would imply that any address used to reach facebook, google, etc >> is tainted and cannot be used for any other connection. >> >> pretty much all my devices have umbilical cords back to the "cloud" >> for applications, software updates, management, data dumping etc. >> those cords are also connected to an identity. >> >> I'd argue that there are no deployed hosts / application combinations >> that can only use privacy addresses (they might use privacy addresses >> as short lived stable addresses, but in that case they would be >> better off with stable addresses). >=20 > We agree. At the end of the day if you really care about network > activity correlation, privacy addresses simply last for too long. At > which point, you might wonder if they are worth the hassle. >=20 >=20 >=20 >> if the consequence of this is that a temporary address can only be >> used within a single connection, then I can guarantee you that there >> will be many networks that will not support that. bridges do not have >> unlimited space. >=20 > Agreed. >=20 > Thanks, >=20 4 --PeXMB7uLDcC0J4OpuIXKNeimpxc6WJuor-- --Rnp37wt1E6cUb8cQCeVfF6tGuRClLBtkd 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 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldYLboACgkQ8AA1q7Z/VrLgWgCggFXB1mOOGxloROxqxjYjD/e8 lfMAn2n7sXLZvXdjYjZlnM9ovetaU18R =CSem -----END PGP SIGNATURE----- --Rnp37wt1E6cUb8cQCeVfF6tGuRClLBtkd-- From nobody Wed Jun 8 12:09:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5073112D0B3 for ; Wed, 8 Jun 2016 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RS6PVKwfPr0Z for ; Wed, 8 Jun 2016 12:09:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0711112D0BE for ; Wed, 8 Jun 2016 12:09:55 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 80054800CC; Wed, 8 Jun 2016 21:09:47 +0200 (CEST) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: otroan@employees.org, Lorenzo Colitti References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> <3F8CA752-D0B9-4516-9C93-C736BF9946CF@employees.org> <02BC17C8-35B8-4BC4-9A3B-D7DF61C84CAA@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <575869CF.3060401@si6networks.com> Date: Wed, 8 Jun 2016 20:54:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <02BC17C8-35B8-4BC4-9A3B-D7DF61C84CAA@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:09:56 -0000 On 05/31/2016 09:23 AM, otroan@employees.org wrote: > Lorenzo, > >>> I'd argue that there are no deployed hosts / application combinations that can only use privacy addresses >>> >>> Privacy addresses as defined by RFC4941? Perhaps not today, but it's not hard to change that. >> >> give me a functioning host that has no umbilical cord somewhere that leaks identity... >> >> What are you suggesting? That RFC4941 addresses don't provide any useful privacy? Or that hosts can't use only RFC4941 addresses? Something else? > > I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses. and that you cannot reuse an address you have coupled identity with for any other connection. > > 4941 may improve privacy, but it clearly isn't sufficient in itself. I think the part in RFC4941 that is of help is that (assumption?) that the IID is recomputed on attachment. i.e., lack of stability across attachment. For the temporary-ness... well, in theory changing the address once per day is better than never changing it, but... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 8 12:10:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9382C12D0BE for ; Wed, 8 Jun 2016 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DRztEdHwiF32 for ; Wed, 8 Jun 2016 12:09:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061EA12B053 for ; Wed, 8 Jun 2016 12:09:55 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2A04C80102; Wed, 8 Jun 2016 21:09:49 +0200 (CEST) Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt To: otroan@employees.org, Lorenzo Colitti References: <20160523150736.10739.19307.idtracker@ietfa.amsl.com> <85D7A11B-03B1-4570-8F4B-EA533FF2CAEA@employees.org> <3F8CA752-D0B9-4516-9C93-C736BF9946CF@employees.org> <02BC17C8-35B8-4BC4-9A3B-D7DF61C84CAA@employees.org> <90628A01-A7C0-4D2C-83ED-74F3F9963E00@employees.org> From: Fernando Gont Message-ID: <57586A6E.3090806@si6networks.com> Date: Wed, 8 Jun 2016 20:56:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <90628A01-A7C0-4D2C-83ED-74F3F9963E00@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:09:56 -0000 On 05/31/2016 10:36 AM, otroan@employees.org wrote: > Lorenzo, > >>> What are you suggesting? That RFC4941 addresses don't provide any useful privacy? Or that hosts can't use only RFC4941 addresses? Something else? >> >> I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses. >> >> Your statement does not mean much unless you define "public". The difference between RFC 4941 addresses and other addresses is not are that RFC 4941 addresses are not persistent. > > IPv6 addresses are not persistent. they are all ephemeral. it is just a matter of the lifetime. > > a public address is one registered in DNS or some other external registry. > I would argue that the address you use to reach facebook (and thereby couple address and identity) you have made that address a public address. That's the case for "throw away" addresses made in draft-gont-6man-non-stable-iids. Obviously, it comes at a cost. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 8 17:42:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD94312D65E for ; Wed, 8 Jun 2016 17:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Cv2qEbZXTeUn for ; Wed, 8 Jun 2016 17:42:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 65A7612D89F for ; Wed, 8 Jun 2016 17:42:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D7BE23494F8; Thu, 9 Jun 2016 00:42:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C57F416005C; Thu, 9 Jun 2016 00:42:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A0B7A160081; Thu, 9 Jun 2016 00:42:55 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4PSS8zjiFhvL; Thu, 9 Jun 2016 00:42:55 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 45CB616005C; Thu, 9 Jun 2016 00:42:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0583E4B07903; Thu, 9 Jun 2016 10:42:53 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> Subject: Re: ULA-C [was: Testing ULAness] In-reply-to: Your message of "Wed, 08 Jun 2016 22:19:19 +0900." Date: Thu, 09 Jun 2016 10:42:52 +1000 Message-Id: <20160609004253.0583E4B07903@rock.dv.isc.org> Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 00:42:59 -0000 In message , Lorenzo Colitti writes: > > On Wed, Jun 8, 2016 at 4:51 AM, Jen Linkova wrote: > > > > ULA also have one other nice property, if I remember (and understand) > > > RFC6724 section 2.1 policy table correct, given a computer have two > > > IPv6 addresses, global and one ULA, it will use ULA for internal > > > communication and global for global, right? > > > > Yes, and it could be quite handy in some scenarios, such as keeping > > your network working internally even if your ISP uplink is down. If > > you use ULA together with GUA (assigned by your ISP(s)), ULAs can be > > used for intranet communication. > > > > Note that the specs say that by default the global address should be used. > Otherwise you'll have problems like "host x in ULA A tries to connect to > host y at ULA B and fails, even though both x and y have global addresses > that can reach each other". Which shouldn't be a problem is host A's applications are written for multihomed servers as required by RFC 1123. Host A tries to reach the B's ULA address, that fails and it tries the GUA address. The address selection rules select A's GUA address and the connection works. And before you complain about "it takes a lot of time" there is absolutely nothing stopping A from attempting to contact B over the second address rapidly like one does with HE for IPv6 vs IPv4. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 8 18:43:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477ED12D675 for ; Wed, 8 Jun 2016 18:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D_knyvCIsgl8 for ; Wed, 8 Jun 2016 18:43:05 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4865B12D8F0 for ; Wed, 8 Jun 2016 18:43:00 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id ec8so7699119pac.0 for ; Wed, 08 Jun 2016 18:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RLGRuqEqtDmOPaL+wNVaPlR7M/SddkJVUerfwULWDCk=; b=WAkkcxiVyE5RQsftniECaECD30ZbEXyUuHnfdpWRceolOi6BYOEWCfMsdwiVyAXIFM rWQkvmU0/Rcq/R9KU4KNZdaSBHYyCFqOB67ojdKqLShkjX0GdNYIasAWbXtKOOWvRDvl LaaH8mq3xLrF6VB9Q8VEJscpfDaeyMg7vp9RyRvqKOFq9e6C7VmDzZM70+j/5oEuG6JN YEs6nQsY5LgHTcAsNerEn6fWbijJturVb8GM6v1O9kA3maP7tloLLVW//f4MqL0Jf5Mr ZyjTfz0ALTru4LOhPh2XTqegZiAbXOMceVLaUQyXjG95mtbsqcP/bb7/SoWwCiqK2Wn+ Eh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=RLGRuqEqtDmOPaL+wNVaPlR7M/SddkJVUerfwULWDCk=; b=Rcw5igicB52f1pcab3xvf1IOH8PHGAdMKaqNJwCJK6GIxltL79nTg0VeR1owSKtFaC I0+4fSJ4COw0dE5An7Tchedq8O3yysXiCRPxt0aTp8YnRlfdZvmIPfk30bgFckl6vPSO cMTVDvwrsiO9Ynr0nFDjEmL2u2d6a0/3zAkkX11R3IQVazTBEQOLC0u2tG8907ORqM4t B5QXaLZOcF2Ax7fVwJB8TaLdkO/iOR/U06w4NhTfrQH9ZfX63KOx+PQ5XDIoeHY7ZXQI cmSz9u5637qiA5LO42cnojATHT1IOu1Is9peUEv38yiRPhgTcoW6MAaP/92Wi+1Pq3Jf wCtg== X-Gm-Message-State: ALyK8tJYaqM8l5IlJv3YE5oiW+7uccPrmQK2uuhD5KkEd1vOWWZe+ZH4T7tZXt3tAAlvpg== X-Received: by 10.66.1.134 with SMTP id 6mr9132659pam.15.1465436579601; Wed, 08 Jun 2016 18:42:59 -0700 (PDT) Received: from ?IPv6:2406:e007:6f7a:1:a1bb:f63c:2ddb:4214? ([2406:e007:6f7a:1:a1bb:f63c:2ddb:4214]) by smtp.gmail.com with ESMTPSA id ce8sm5130314pad.44.2016.06.08.18.42.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 18:42:58 -0700 (PDT) Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt To: otroan@employees.org References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> Date: Thu, 9 Jun 2016 13:43:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 01:43:07 -0000 On 08/06/2016 19:31, otroan@employees.org wrote: > Brian, > >> Comments and suggestions welcome, and if there is enough interest >> we could perhaps discuss this in Berlin. > > Thanks for writing this up! > > I believe if we go back and look at what we tried to achieve it might become easier. > > ULAs are globally scoped addresses to ensure that NAT is not needed. > If ULAs were not globally scoped, then connecting to networks together using ULAs could require the use of NAT. We have "defined" ourselves out of that by declaring them to be globally scoped. Reality might be different, but that's the political direction we wanted. > > We did not want ULAs to be globally reachable. Which is why there is the by default boundary checks on routing advertisements for example. Using ULAs it would be extremely unlikely that one could engineer global reachability, although among a set of consenting administrative domains they can be routed. > > Global scope = We don't need NAT > Not global reachability = Affects SAS/DAS selection, use in DNS and so on. > > 5. Rename the registry column from 'Global' to 'Globally reachable' (and update text and RFC 6890 accordingly). > > Seems to clarify the meaning of "Global". > Wonder if that could be done just with an Errata. As long as the registry could then include words like: Note that 'globally reachable' is a practical statement about recommended routing practices. It is different from the formal 'global unicast' scope defined by [RFC4291bis]. In particular, Unique Local Addresses [RFC4193] have global unicast scope but are not globally reachable. Brian > > > > >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-carpenter-6man-whats-global-00.txt >> Date: Tue, 07 Jun 2016 18:53:59 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : What does 'global' mean in IPv6? >> Author : Brian Carpenter >> Filename : draft-carpenter-6man-whats-global-00.txt >> Pages : 4 >> Date : 2016-06-07 >> >> Abstract: >> The word 'global' is used in two different ways in various >> IPv6-related RFCs and an IANA registry. This document describes the >> resulting problem. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-6man-whats-global/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-carpenter-6man-whats-global-00 >> >> >> 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/ >> >> _______________________________________________ >> 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 >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Wed Jun 8 22:01:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F2A12D09E for ; Wed, 8 Jun 2016 22:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 emzSkKG2oSTZ for ; Wed, 8 Jun 2016 22:01:05 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5977612D0C3 for ; Wed, 8 Jun 2016 22:01:05 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id c72so27619296ywb.1 for ; Wed, 08 Jun 2016 22:01:05 -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; bh=+sHWeesDOu06dAQbdSMVzyWwEJQx0MDyz5xQTjNNRH8=; b=mXkYPBDxbUw9W4E1WQpAOjPDjm/AsyBz1khaQIslbi0LhSk0b8ws+6GJxr4rrNMJWY Ala2NHCyiDEyIebchaAxr9akX3IWF5Y5GDWHld62vCE4MyqCNVopbm12Fo5zv4fDSkQ0 QE0l/NEBXUAZfYjqZwa5zQatIZ3YBaixWrVlKVRObAVHxcpEOQ6RyW0302Zp1CYWDeKN wgar3on1U0hCR3O1MwkQFDeB7RmpWk16RhF4tbdtQlMq2n3I9ibpCIFgPMVIej4+sOAP NOOjnQRzHzC1ooXX0chJNEGupjUWLSrG3w8c3WPitf/trcRmzBguMql0zlL8/0H/D9/E E7lg== 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; bh=+sHWeesDOu06dAQbdSMVzyWwEJQx0MDyz5xQTjNNRH8=; b=ayAmpLli9FxcJSFrrEYOTxHxlNs4UsN9l92BTYkoufIdlDUPPp/AvAXEtoRNclnhTi 5elMdH5s8N8cagwFd9JBCtjEVYCo6zocEejrSpvnrilJveO7lQq7oqX2L16N05TkI2xt MN0i6lQjHnQFW3k45NrZseANaNojTx2yCZRllYbtAl7h4p7Ujrciv7Y5/Jrg7xUvqyl6 88rIIwpm0CMiV8uRvC8lBJjdTFZn7n7+nuBK2MganlrNhaGxuaQ9bPaAuxp1LBSfkCJ+ ZT26zgG4z5Aj8yW2gcHWSQK+UsJA48dPPBze+gjg1fA8aubT8PahrN0321KO7dxQGi3r nprA== X-Gm-Message-State: ALyK8tLf6fn5/KdV4IxArHHrGJLZRX2bJ79Vs7bMtX9ZpSqFEHjVguzaeCK5WW0+jKIVCkvaQjKuB14X5FNZV+Yl X-Received: by 10.37.110.65 with SMTP id j62mr4608912ybc.155.1465448464190; Wed, 08 Jun 2016 22:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Wed, 8 Jun 2016 22:00:42 -0700 (PDT) In-Reply-To: <20160609004253.0583E4B07903@rock.dv.isc.org> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 9 Jun 2016 14:00:42 +0900 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1148acd225b72d0534d14fdd Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 05:01:07 -0000 --001a1148acd225b72d0534d14fdd Content-Type: text/plain; charset=UTF-8 On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews wrote: > And before you complain about "it takes a lot of time" there is > absolutely nothing stopping A from attempting to contact B over the > second address rapidly like one does with HE for IPv6 vs IPv4. > Nothing stops an implementation from doing that, but no implementations do that. As an industry, I think we need a better engineering answer than "try every possible combination all the time", because trying all combinations all the time is expensive in terms of CPU time, radio usage, and battery life. HE was a hack to aid in IPv6 deployment. It's time to retire it. --001a1148acd225b72d0534d14fdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 9, 2016 at 9:42 AM, Mark Andrews <marka@isc.org> wrote:
And before you complain about "it t= akes a lot of time" there is
absolutely nothing stopping A from attempting to contact B over the
second address rapidly like one does with HE for IPv6 vs IPv4.

Nothing stops an implementation from doing that, bu= t no implementations do that.

As an industry, I th= ink we need a better engineering answer than "try every possible combi= nation all the time", because trying all combinations all the time is = expensive in terms of CPU time, radio usage, and battery life.
HE was a hack to aid in IPv6 deployment. It's time to reti= re it.
--001a1148acd225b72d0534d14fdd-- From nobody Wed Jun 8 22:59:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29DF12D0A2 for ; Wed, 8 Jun 2016 22:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Yx9Sbwln7q9e for ; Wed, 8 Jun 2016 22:59:28 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 91B2C12B046 for ; Wed, 8 Jun 2016 22:59:28 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 439231FCB88; Thu, 9 Jun 2016 05:59:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 24FA3160035; Thu, 9 Jun 2016 05:59:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 119D216006C; Thu, 9 Jun 2016 05:59:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pEVi4pL1QPIa; Thu, 9 Jun 2016 05:59:23 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B7AF6160035; Thu, 9 Jun 2016 05:59:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7C4D04B09FBE; Thu, 9 Jun 2016 15:59:21 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> Subject: Re: ULA-C [was: Testing ULAness] In-reply-to: Your message of "Thu, 09 Jun 2016 14:00:42 +0900." Date: Thu, 09 Jun 2016 15:59:21 +1000 Message-Id: <20160609055921.7C4D04B09FBE@rock.dv.isc.org> Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 05:59:30 -0000 In message , Lorenzo Colitti writes: > On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews wrote: > > > And before you complain about "it takes a lot of time" there is > > absolutely nothing stopping A from attempting to contact B over the > > second address rapidly like one does with HE for IPv6 vs IPv4. > > > > Nothing stops an implementation from doing that, but no implementations do > that. And they don't do it because the primitive examples for how to contact multihomed servers don't show how to do that. It really is just a matter of education and spending a small amount of time going back at retrofiting smart multihome server connection semantics. > As an industry, I think we need a better engineering answer than "try every > possible combination all the time", because trying all combinations all the > time is expensive in terms of CPU time, radio usage, and battery life. > > HE was a hack to aid in IPv6 deployment. It's time to retire it. When you can create a network without black holes then it is time to retire it. To date I've yet to see anyone do that. Additionally local ULAs, GUA, other ULAs is the best default sort order and generally results in a single connection attempt unless there is a broken link. Where you use matching ULA, GUA and GUA as the source address unless it is explicity overridden. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 9 00:04:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B1312D144 for ; Thu, 9 Jun 2016 00:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 ZeIfsFx2ydMb for ; Thu, 9 Jun 2016 00:04:21 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244B812D125 for ; Thu, 9 Jun 2016 00:04:21 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 07:04:18 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6B4B09CC4F; Thu, 9 Jun 2016 00:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=/m5LAMK8CuQT1xp8OS17wo6Cs38=; b= Yk5b9c7HBeF52ddP1dYShSjimczzZrRCLc8mdaJSAuNeGY5fo9QAYZYcvmmKi+JR RAt/zS5ek6s5F3v5M9rmqbv0cVQ/XBFF5TU2GN6uyofjQtQK/7Vo4+AyYH3yR6x4 jJPP5pP3BM/uiV7T6wnp1EZebC3+32Wowas3H26j0QM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=szogpwE7AIQdvGF8EYpjauNUwH NOeyfaFZ/B4QpvcczAdReyAV9clsH+x1elQW1gzgW31K7xoybyE7TtYDMmLZM318 cioI8NT+4DOohOYAmyC1+vJJcAiCZom9lU0wvLj8A9ZymKvDZ0mZ7TY7kXmo2e30 mnIoMAm72hSSyxWt8= Received: from h.hanazo.no (unknown [173.38.220.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 350459CC4E; Thu, 9 Jun 2016 00:04:17 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A1BF21AC4556; Thu, 9 Jun 2016 09:04:11 +0200 (CEST) Subject: Re: ULA-C [was: Testing ULAness] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_86978FC5-D9EE-4A2B-8E03-E0A66AB9FD89"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Thu, 9 Jun 2016 09:04:08 +0200 Message-Id: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:04:22 -0000 --Apple-Mail=_86978FC5-D9EE-4A2B-8E03-E0A66AB9FD89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > And before you complain about "it takes a lot of time" there is > absolutely nothing stopping A from attempting to contact B over the > second address rapidly like one does with HE for IPv6 vs IPv4. >=20 > Nothing stops an implementation from doing that, but no = implementations do that. >=20 > As an industry, I think we need a better engineering answer than "try = every possible combination all the time", because trying all = combinations all the time is expensive in terms of CPU time, radio = usage, and battery life. >=20 > HE was a hack to aid in IPv6 deployment. It's time to retire it. I disagree. I a host should optimally try all combinations, monitor them, failover = between them, load-share across them... it can obviously be smart about it, and probabilistically prefer some = SA/DA pairs over others at connection time. I've not seen any other credible alternative to deal with host based = multi-homing. even if you were only connected via a single interface to a multi-prefix = network, the network has very limited knowledge about the path = performance to the destination. cheers, Ole --Apple-Mail=_86978FC5-D9EE-4A2B-8E03-E0A66AB9FD89 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 iQEcBAEBCgAGBQJXWRTrAAoJED4aXnjSQuKWZ5MH/32vC96A2uSjVM6loT1flxan 76WXMbcjmFHuNDi/mTs+c+fbb5jfabergDTY4ygdBNXbUwNnZJ+Aoh7xwzpWUFmR 7GwfaYi4fliFc/Et78qwzt7X3IpAtT82X2uUzffaCa0BgQ8J6buUBLXwRlLD07Am TRb2EzbcZm+c1icZL2N0FyqPqBPZdV64DO8pqoEvW0BO+xfG5BXIAxWGcNm8FIs6 GmRSRkRW/cbxm8jTQy+qro0J0XpwNSpZQMdLMHjXM3yRG+p6eQKGt9Y1Hm0ugd1H Mk+W/7pRdSPFFzWLytXa/nurHUcMqII3k/Fyi0q6x8heUxoclwlKvL3GKjw0OFQ= =mI0a -----END PGP SIGNATURE----- --Apple-Mail=_86978FC5-D9EE-4A2B-8E03-E0A66AB9FD89-- From nobody Thu Jun 9 00:08:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6612D14F for ; Thu, 9 Jun 2016 00:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 8hUWz4pcyMcT for ; Thu, 9 Jun 2016 00:08:38 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D47312B01E for ; Thu, 9 Jun 2016 00:08:38 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 07:08:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1243B9CC51; Thu, 9 Jun 2016 00:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=22NSJLsKvIqfUXiU7Lgk3qlyyOY=; b= U1/ILeU8HOai3OWMNi+/kXc4an3gVYmwZzUdhe3pAs8gryz6GWwxY2lL2efJV1sg kkwtjf2c30yFPVEofC6O40llMlghiOd27O5ckYUFKoxKFCwz3O3q9oKpY7Br8tyu BPbnC9TLthiikMGmxIEJ2isxEnGxblidlSAP1u+cM5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=leGuj7z14Ii3K7OeBf8scxDFNp RCSxnsBbfEtd8jKz8uLB39f0mvOMtE1vbGwaBurlJUJNpQV4FhWZnCwebtYgjjW2 lixDjPQpIcHP13mU1eKFPXEgda93DaYQN/a76zDfVLuTDoBIvBM99tiG6/cI+hxC fPhNHP8cUWwTFSAJ0= Received: from h.hanazo.no (unknown [173.38.220.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CF89E9CC4F; Thu, 9 Jun 2016 00:08:34 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C6D711AC64BD; Thu, 9 Jun 2016 09:08:31 +0200 (CEST) Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_49A673C7-4EA2-4B91-B3CE-551764972C14"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> Date: Thu, 9 Jun 2016 09:08:31 +0200 Message-Id: References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:08:39 -0000 --Apple-Mail=_49A673C7-4EA2-4B91-B3CE-551764972C14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> Comments and suggestions welcome, and if there is enough interest >>> we could perhaps discuss this in Berlin. >>=20 >> Thanks for writing this up! >>=20 >> I believe if we go back and look at what we tried to achieve it might = become easier. >>=20 >> ULAs are globally scoped addresses to ensure that NAT is not needed. >> If ULAs were not globally scoped, then connecting to networks = together using ULAs could require the use of NAT. We have "defined" = ourselves out of that by declaring them to be globally scoped. Reality = might be different, but that's the political direction we wanted. >>=20 >> We did not want ULAs to be globally reachable. Which is why there is = the by default boundary checks on routing advertisements for example. = Using ULAs it would be extremely unlikely that one could engineer global = reachability, although among a set of consenting administrative domains = they can be routed. >>=20 >> Global scope =3D We don't need NAT >> Not global reachability =3D Affects SAS/DAS selection, use in DNS and = so on. >>=20 >> 5. Rename the registry column from 'Global' to 'Globally reachable' = (and update text and RFC 6890 accordingly). >>=20 >> Seems to clarify the meaning of "Global". >> Wonder if that could be done just with an Errata. >=20 > As long as the registry could then include words like: >=20 > Note that 'globally reachable' is a practical statement about = recommended > routing practices. It is different from the formal 'global unicast' = scope > defined by [RFC4291bis]. In particular, Unique Local Addresses = [RFC4193] have > global unicast scope but are not globally reachable. I'm fine with that. in practice the statement about global unicast scope is also a practical = statement about recommended practice. cheers, Ole --Apple-Mail=_49A673C7-4EA2-4B91-B3CE-551764972C14 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 iQEcBAEBCgAGBQJXWRXvAAoJED4aXnjSQuKWsQwH/15MfjBMxqRC5WZqwteeuLrE Z5kki8JSuT6ROUirfRF40Ytz+TjSaR8LwCng7r9qBXr94ZCrFlRqb7mEWXhQqNEb tvcHvBO2xcKOQgHSYwOspAZDH87C/uQwN5MYFJXuwlzurok3uGJyJAzG3zDz+vBX bEP14NvtGDXgo1iFJuPgPEU33AjszU6ZTVYHjQsbZayTuFSIEVLp+ODBzlYFSldb qkHH9WpKk6BOR/5pYaelFZMHLYy5D1MN+IOpy4OlQ/IEBy49Vs/n8zKltEUm2doF GHReQv5WFyoXEdPpzBBUXzm74bF8pw87Krd0vDnTlI0omsYlhzrswwlMFtRhPQ0= =D8QW -----END PGP SIGNATURE----- --Apple-Mail=_49A673C7-4EA2-4B91-B3CE-551764972C14-- From nobody Thu Jun 9 00:10:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87912D125 for ; Thu, 9 Jun 2016 00:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 P9rtJrScGAGF for ; Thu, 9 Jun 2016 00:10:37 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551D712B01E for ; Thu, 9 Jun 2016 00:10:37 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id g20so29704595ywb.0 for ; Thu, 09 Jun 2016 00:10:37 -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; bh=GIw2TLJ23i6jSonW/06dqSbat1RkbgkmGXXGF+lznzo=; b=HjcuUq5znOD7okNhBnu/Nxe6OXMGu5v8rqjCEuDjoOHFTUX1STX2EeE+BaS5Tplruy VY2j7695vWTIm/v+hZT/WjjlHCFbs2jZ6oxTlU5kpdcxWcCOgfl/LyaxUA4xneL4Y0o0 RUZBDgr4EZIJtq70Iop9xXE+/wkXJP8iJNommPZGv4QspvlmEz7keZDDJUseqSmnqBg+ Lc8rzHp/8Dm5shsLELyqyDbgCLCGvUBJppR6KNV+baqcm+gyfFjfx1nZ1/hUPK8oYRmR 8r643Yz736W76LyPQh6Ga/WQeswkpTL1/kX4cs5BkhrPXPwBeBsW0v325ditvW1pVSED EZnA== 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; bh=GIw2TLJ23i6jSonW/06dqSbat1RkbgkmGXXGF+lznzo=; b=jHsHCi5aq9EkAOBmfbLiBbn4Ul5/7Gk2VBtp0+Y5gd017xtLeFEmJ+zddGMBjnq2T+ j86iXyTYrAkakykmEkqRGb4kVqyTs9yDbtA7TNs6A8IJLkZywjKYQfLyPM4LcykB9pih If5OfuLON8daGOg4jrEY6+144qbzwOST+mTY5WvcdwZUj+7H/sHKW1LcGOPopLVxjrNx 3APBflAt1nrSov0qFYo5C2dcbxq2zmvljjBINBysKevfvfURn/CzkrCkbgkihQnVqQTv 3alHkty24la6Sbw3cwWKq6RniS8ImlQQZNST4zSjmWcbr0RYRuswF9EoZ4LPuBoNLGam YxMQ== X-Gm-Message-State: ALyK8tJcHcUmyoOG8n488q+1M26CH9vjYQfuL/M9mX3eZ53tFhQpokaPROmfKdksUqYCYGEMvYIzVnxSIXw4/JGj X-Received: by 10.13.220.69 with SMTP id f66mr5526217ywe.132.1465456236301; Thu, 09 Jun 2016 00:10:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Thu, 9 Jun 2016 00:10:16 -0700 (PDT) In-Reply-To: <20160609055921.7C4D04B09FBE@rock.dv.isc.org> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 9 Jun 2016 16:10:16 +0900 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Mark Andrews Content-Type: multipart/alternative; boundary=94eb2c0815c8669f5a0534d31e5c Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:10:38 -0000 --94eb2c0815c8669f5a0534d31e5c Content-Type: text/plain; charset=UTF-8 On Thu, Jun 9, 2016 at 2:59 PM, Mark Andrews wrote: > > HE was a hack to aid in IPv6 deployment. It's time to retire it. > > When you can create a network without black holes then it is time > to retire it. To date I've yet to see anyone do that. > All IPv4-only networks operate in that mode and have been for decades. Almost 90% of Internet users still only have IPv4. An unmanaged system with N-way redundancy usually ends up operating with N-1 failures. --94eb2c0815c8669f5a0534d31e5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 9, 2016 at 2:59 PM, Mark Andrews <marka@isc.org> wrote:<= br>
> HE was a hack to ai= d in IPv6 deployment. It's time to retire it.

When you can create a network without black holes then it is time to retire it.=C2=A0 To date I've yet to see anyone do that.

All IPv4-only networks operate in that mode and ha= ve been for decades. Almost 90% of Internet users still only have IPv4.

An unmanaged system with N-way redundancy usually end= s up operating with N-1 failures.=C2=A0
--94eb2c0815c8669f5a0534d31e5c-- From nobody Thu Jun 9 00:37:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D912D578 for ; Thu, 9 Jun 2016 00:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7-UDWwnmic9G for ; Thu, 9 Jun 2016 00:37:24 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D0712D544 for <6man@ietf.org>; Thu, 9 Jun 2016 00:37:19 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id g67so43891910vkb.3 for <6man@ietf.org>; Thu, 09 Jun 2016 00:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5oVUTOJgNVs0iJgvxJXc5YZB8lUoYxKAfc6rX4q7O+E=; b=ASgMvR+O0cqw2S8110Usimf8MgWPEIitZMRbR+B2j67Molfgb+H9iuDb3jZk7LBdtf zsqcVgCaoBpQ+FGK9Xx+cN54KdZTaVm4tsvrQKRm3ezao5fBkE4SN4TlXb+Oal1Te5rb CWOMuYx37NgPeSaISsdzt32gFzkwq7U0eQUh8qq5bSXLP6YraE84ZkRESMj7p1H63qQm aWLZ9pi59rZoBlX+AM6dxHQILlhkSZ1F4WLxY2SO1m8akk0MO2shKTi0iNbhtGCb4fLc 2ayJiVohzO2tALXVrCBvxouLBRbJ2O13mjk3vQkPwXCg6g5HfvC50bWYyDKcyWhGZ87s 9ckA== 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; bh=5oVUTOJgNVs0iJgvxJXc5YZB8lUoYxKAfc6rX4q7O+E=; b=dyoF7ptXKxCNAGKIcMRuqYE0sySuHlILr9FlLJxoeLcFA4dtVR8MfmxmkUgZa1z8QM 5RIjBtKMPFl2xupA54UiOKJVkdgo8TMBuokC6gMhYeSh/t14o/dL4YIm4kQnpG2j/nxx 053SifpEsERn2xqd9Wv+I8wBHOMffhBFmCFDiahVMPR313WElAuBztNcEAJQeLiHg7fz jEzF72d8KCKzLKbrFA+OnpYECtpxDGMgZDaVDWl9vRzLEZcExmJmk9CxFbIGyZWWSaGM qVBEmfvmeMlZp37AJJAUxW6c8FInqGt9yHSYqZdrls2nE0GMNAA89xPixdRBsuZxoEzU CUXw== X-Gm-Message-State: ALyK8tJBLpC+1p73JNhRaD3/6T1wnTw8pQhmdUikSBRURB0l02rJrtGdm7wn6ZNisfQZtcnljJGOTadNa67DRg== X-Received: by 10.31.136.194 with SMTP id k185mr4080066vkd.2.1465457838178; Thu, 09 Jun 2016 00:37:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.54 with HTTP; Thu, 9 Jun 2016 00:36:48 -0700 (PDT) In-Reply-To: References: <20160523150736.10739.56619.idtracker@ietfa.amsl.com> <57431E27.8090209@si6networks.com> From: Mark Smith Date: Thu, 9 Jun 2016 17:36:48 +1000 Message-ID: Subject: Re: RFC4941, temp-addr only, etc. (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-00.txt) To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , 6man@ietf.org, =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:37:30 -0000 Hi, On 1 Jun 2016 10:28, "Lorenzo Colitti" wrote: > > On Wed, Jun 1, 2016 at 8:23 AM, Mark Smith wrote: >> >> The answer is MPTCP. > > If you ask me, a protocol that cannot be deployed is never the answer to anything. Apple deployed it in IOS 7, and is being used by Siri. https://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html https://support.apple.com/en-au/HT201373 Apparently it is also available in OS X, although I don't know if any applications are using it. https://labs.neohapsis.com/2014/10/20/mptcp-roams-free-by-default-os-x-yosemite/ >But MPTCP is not the only way to do multipath, and it's true that that's OT for this thread. >> >> >all the suggestions in Appendix A have equal or less stability than the interface link-layer address. On client systems, interface name and index are at best as persistent >> >> as the MAC address. >> >> If I recall, Fedora assigns interface names based on PCI slot. > > On ubuntu they come from udev rules: > > # PCI device 0x8086:0x0085 (iwlwifi) > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="84:3a:4b:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0" > ... > # USB device 0x:0x (r8152) > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5" > > PCI slot (or USB bus location) really isn't going to work well for the USB ethernet adapter which I use every day. >> This situation is also discussed in Appendix A. USB is an interesting case. The Net_Iface could be set to/tied to the USB port (bus/port), for cases where the USB port has a designated role of some form. I could imagine if I was doing some networking experiments on a PC that I would want to associate an RC7217 address with a USB port rather than the USB NIC I plug into it, since I have a few USB NICs of the same brand and model. This might also apply if the USB bus is used as an internal bus, where the USB NIC has a different form factor and connection than normal (e.g., since new versions of USB support 10Gbps, using USB as an internal device bus might become cheaper than other less commodity alternatives.) Alternatively, Net_Iface could be tied to a property of a particular USB NIC, such that it didn't matter what USB port the USB NIC was plugged into, the RFC7217 address would follow the specific USB NIC. I think that would be my normal everyday preference, as I conceptually associate network connectivity with a particular the USB NIC, regardless of what USB port I plug it into. Finally, probably for most cases, RFC7217s and more generally stable addresses might be unnecessary for USB NICs, as they're commonly used on end-user hosts rather than devices where stable addresses are used e.g., servers or routers. It would only be people like you and I who, depending on what we're doing e.g., experiments or tests, might want stable addresses on the USB NIC attached to our laptop. So it very much depends on the use case as to what the best value for the Net_Iface parameter might be, not only for USB, but also for some of the other interface attachment methods or scenarios. >> Get some time on a commercial router and you'll find out that none of what you're saying occurs. > > Of course it doesn't. What I'm saying applies to hosts, Right. I think that's the problem. You've been discussion from the perspective of end-user hosts (that don't present any long term services to the network), where as default-*-iids is about the default for any type of device (nodes) that is currently using EUI-64s for stable addresses. It is raising the minimum privacy bar for stable addresses, not replacing RFC4941s. Default address selection rules will enforce the choice of RFC4941s if there is a choice between RFC7217s and RFC4941s. but it does apply to most hosts, and hosts are the things that have the greater privacy requirements. You want to make RFC7217 a MUST for commercial routers, sure: Ole is the one you have to fight on that one, not me :-) > Sure. I want RFC7217s to be used as the default for router interface addresses (all LLs/ULAs/GUAs), so that I don't have to stop them changing by using static LL/ULA/GUA addresses if I replace the interface module with one that has a different MAC address. I think static router interface addresses to attain stability should be a choice for a network operator rather than a requirement. Regards, Mark. From nobody Thu Jun 9 00:48:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0AC12B035 for ; Thu, 9 Jun 2016 00:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ntAVutDj8DwD for ; Thu, 9 Jun 2016 00:48:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C269B12D0EE for ; Thu, 9 Jun 2016 00:48:08 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id d127so44231369vkh.2 for ; Thu, 09 Jun 2016 00:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5PR+hKyz5toKGH/zaSB0Y7Zoo3HnxBtoazUlI64QA1U=; b=lOb8LUUpPk44aPLQ98TlWVjm8/gfeVXyBjRW8QrRxOECRPjbLzmsvGmHx5/qjVD1Ys xgP3EkzyW7FaKjlz+pHwesi1DSJypm1DDvTXn5bTgtOJpc+dPQdiSPSi0XWItoTJVbDN PHfmmq8WYrTaAHEmA9L2n8/U6Sjz8o/hiPv1J9zPaZf75x6Ml+07W2BqlL2Ib/47e8HW aajnkK1KIwV8yHcYnfVKBvzD47IguCHn3A9EWVIoRTbdIIoDaqcUpLc0LpFh9wZzDO4u 6CPKHZLBKLeyL/dJfbzKf3t6kDtQCNSoRWAhy6fGRJe6+CNzNBYeR2hCJgrnBgKUw5Vk 1I3Q== 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; bh=5PR+hKyz5toKGH/zaSB0Y7Zoo3HnxBtoazUlI64QA1U=; b=PGW9wEs9V/wK7m3sdAPgpT02wn2anqHmvK/C8SNDyK0DzGrEWQI5GZcgjcKHC6vY25 YtPxo0xjrJN8a0UcIK6sId/GmdkMvYjKcREmRGJDRr/Kct5eccYhGlOFdBRMOFIj2iSB QCyawP0iZVvVkdrDSYtOgERjLthTP3SI2uhpypKuaTRuut5ZATj0qfc40AX8MZWtyhRL IPpILgEwQhV5OYml5wSk8E99sIjuKW88EvKDWWNDaBLe0wRDvzrz/u8iX6e/rTTkzlOU 5mAzoDmmb7aTbGeUeaILDb48fT7Ju+u96hcKrLmJNOhQStyNX/We2xcHpxkVGWCQVASE 2vmQ== X-Gm-Message-State: ALyK8tLcN1LQygK7Ef1iZBZsI5nqW54gf6yotFjOn8TnMQDG/DiJunLPVdD1l608WUASNE78zVxvwVwTkaYxbA== X-Received: by 10.159.54.171 with SMTP id p40mr3407877uap.129.1465458487863; Thu, 09 Jun 2016 00:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.54 with HTTP; Thu, 9 Jun 2016 00:47:38 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> From: Mark Smith Date: Thu, 9 Jun 2016 17:47:38 +1000 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:48:11 -0000 On 9 June 2016 at 17:04, wrote: >> And before you complain about "it takes a lot of time" there is >> absolutely nothing stopping A from attempting to contact B over the >> second address rapidly like one does with HE for IPv6 vs IPv4. >> >> Nothing stops an implementation from doing that, but no implementations do that. >> >> As an industry, I think we need a better engineering answer than "try every possible combination all the time", because trying all combinations all the time is expensive in terms of CPU time, radio usage, and battery life. >> >> HE was a hack to aid in IPv6 deployment. It's time to retire it. > > I disagree. > I a host should optimally try all combinations, monitor them, failover between them, load-share across them... > it can obviously be smart about it, and probabilistically prefer some SA/DA pairs over others at connection time. > +1 > I've not seen any other credible alternative to deal with host based multi-homing. > even if you were only connected via a single interface to a multi-prefix network, the network has very limited knowledge about the path performance to the destination. > I've viewed HE to be a form of packet loss recovery that is across protocols and across a set of addresses. I've also thought the combination of Multipath TCP and HE would be interesting - HE to help bring up the MPTCP subflows faster, rather than waiting for the first subflow to be established before bringing up subsequent ones. Regards, Mark. > cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 9 07:56:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F612D825 for ; Thu, 9 Jun 2016 07:56:17 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 FTE_ByzVjVpv for ; Thu, 9 Jun 2016 07:56:16 -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 1E1E412D804 for ; Thu, 9 Jun 2016 07:56:16 -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 0DC76880E1 for ; Thu, 9 Jun 2016 07:56:16 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D5AD9328081A for ; Thu, 9 Jun 2016 07:56:15 -0700 (PDT) Subject: Re: Testing ULAness To: ipv6@ietf.org References: From: Brian Haberman Message-ID: Date: Thu, 9 Jun 2016 10:56:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fWhEf8a5gtWfAENDLSCkL5s73hPSBPlUJ" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:56:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fWhEf8a5gtWfAENDLSCkL5s73hPSBPlUJ Content-Type: multipart/mixed; boundary="rvpusGP74kpwOXgCEHmkTB9mBBlJGWHII" From: Brian Haberman To: ipv6@ietf.org Message-ID: Subject: Re: Testing ULAness References: In-Reply-To: --rvpusGP74kpwOXgCEHmkTB9mBBlJGWHII Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for the delay in responding, but I have been traveling... On 6/5/16 12:37 AM, Brian E Carpenter wrote: > Hi, >=20 > The IANA IPv6 Special-Purpose Address Registry* has a column marked "Gl= obal". > For fc00::/7 (ULA) this is set to "False". >=20 > That is surely wrong. ULAs are explicitly defined as having global scop= e. >=20 > This has consequences. For example, in the Python ipaddress module, > the property .is_global returns False on a ULA. The test for ULAness > turns out to be (x.is_private and not x.is_link_local). >=20 > *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-s= pecial-registry.xhtml >=20 I have not been able to work through this entire thread as of yet, but I wanted to respond to point above as one of the authors of the RFC that created the registry. Global is False given that, while probably unique, these addresses are not guaranteed globally routable. 4193 says: Their limitation is in the routability of the prefixes, which is limited to a site and any explicit routing agreements with other sites to propagate them... The authors of 6890 discussed this at length both amongst ourselves and with the larger community. The consensus was that ULAs are not guaranteed globally routable. Regards, Brian --rvpusGP74kpwOXgCEHmkTB9mBBlJGWHII-- --fWhEf8a5gtWfAENDLSCkL5s73hPSBPlUJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXWYOOAAoJEBOZRqCi7goq/ioIAJNwaKmLEkWp6RguFXIOiRjh gT5e6EHMZBDjur8+gxCrC+0c9OWmZ/HgBCnZNiHBTfqmgguD9CM/JhJp1KMzQZMI CCiLkuUdycm5SoifpYWb6cN1CWdaFP/6eegvqkxZ3Xz7XIVoBaaFFp5S9Goryr7E Gau/1g9F72bu1i3bftmq1K4kndHo/VstSCUFuNXRfEAPXigAQOiToZPsyxEN/xPQ rM/dyvujyXkuEBlhJdq4y4iWpTMDLmlWpZWb4s1HM8igagKgULodVi3JIykiy2V5 oa4v9Q56F5gfVA9tk8W/W/j4eHewD1pjIbBIbcLfmMjlJV9WcLJTXkZCe6JwS+A= =WU1t -----END PGP SIGNATURE----- --fWhEf8a5gtWfAENDLSCkL5s73hPSBPlUJ-- From nobody Thu Jun 9 09:31:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2E712D81E for ; Thu, 9 Jun 2016 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 N8X_MvanAGYi for ; Thu, 9 Jun 2016 09:31:05 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1969212D769 for ; Thu, 9 Jun 2016 09:31:05 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id z123so39532371itg.0 for ; Thu, 09 Jun 2016 09:31:05 -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; bh=I5lxWOW15+lfBX81GDRGNeT+OCUFFIW129lpTET6vjc=; b=AOPjyM/V8s0KatxBvfBLK/GN/3gV9UF+O5qbwPNhabZbcuXZ5WYkduD9VdMJHTfRQy djdFQTXQLdky3yS3MV1CBScmfov3HHRn0lpnx1ZpKS7WrJ1U5p5bKEsfpk4wF8giBYJC e2Fk1C4pXXAECdwQpcsvYQCrUWua7XxXqPHqrkg4bu7C3kduGeXE0Oi5K5/tRJ+tBm8G cBHyusO4fQ45HgGmSxhJkEb7ZbSKb7ooHj6gtkoFloYbtzA1POh1rnp3W6q/okUOQ2Yd 2Ofc9bgn4Tkj3bMLfgl1uunUakUKn9pjPmL9nDZqjA4wiRK7rvcRLsPtEYxdn/mQ9Wq1 Nspg== 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; bh=I5lxWOW15+lfBX81GDRGNeT+OCUFFIW129lpTET6vjc=; b=TccDnBIEFFKQ188TpcKaQrhjSC4gecW05XMflIiTsJ6ZblZktp90sgoxynb1+y2evS Zo6ETNn8kyxvJdyw4hEnR60ECEMKREo6ErkoxiiI1hg58Z0LntsV8xJv34ds99pIXflA qkgndSi83bQvVwLX0wvcXMhIoheHr31tXSqCrBwvRsGSfO6ia2xGcUcNs4iX+6RBVUn1 wFSJtpZfceclVAXT6lf35T+OHVby43b8i0DqKawGtB5JFaIPkR/zkA92Jam0yP8Dd91s eT/6ieTi1o1K/bXMoloF6+N36xtVdpbjVKxeGfC/J6X9o777LLJFQZuGqakgTEhli7XW tXyw== X-Gm-Message-State: ALyK8tIUegk8WbDAuNL8ddrfPrFx1rK0Nn49SOacPX2zTKmWRWI67EwWf0ltlMvsg4If2BUV1t8TSEllwPIdRwQM X-Received: by 10.36.146.194 with SMTP id l185mr19694756itd.94.1465489864250; Thu, 09 Jun 2016 09:31:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.68.169 with HTTP; Thu, 9 Jun 2016 09:30:44 -0700 (PDT) In-Reply-To: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> From: Erik Kline Date: Thu, 9 Jun 2016 09:30:44 -0700 Message-ID: Subject: Re: ULA-C [was: Testing ULAness] To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:31:10 -0000 On 9 June 2016 at 00:04, wrote: >> And before you complain about "it takes a lot of time" there is >> absolutely nothing stopping A from attempting to contact B over the >> second address rapidly like one does with HE for IPv6 vs IPv4. >> >> Nothing stops an implementation from doing that, but no implementations do that. >> >> As an industry, I think we need a better engineering answer than "try every possible combination all the time", because trying all combinations all the time is expensive in terms of CPU time, radio usage, and battery life. >> >> HE was a hack to aid in IPv6 deployment. It's time to retire it. > > I disagree. > I a host should optimally try all combinations, monitor them, failover between them, load-share across them... > it can obviously be smart about it, and probabilistically prefer some SA/DA pairs over others at connection time. Underlying this is an assumption that you're not paying any additional cost for those extra keep-alive packets. We don't yet have a good platform-independent way of knowing which links are metered and which are not. From nobody Thu Jun 9 16:03:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF3F12D732 for ; Thu, 9 Jun 2016 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X3N6u_bFZ2ca for ; Thu, 9 Jun 2016 16:03:29 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C8F12D763 for ; Thu, 9 Jun 2016 16:03:29 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id t190so17150777pfb.3 for ; Thu, 09 Jun 2016 16:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=v51YWuj05QBSQnbbjcB26OaTbfpQmAt28BTVA0AQFCk=; b=vqNHhUW87zM/j9TuuNbSfoQ7XTlqKdlUYg0LuPKqf5bHnbwGCYRo6lbVHiCmDygjSa z4TYZuxNmosEcEoZx4AO+AFub4hc8XR7d4NsHszEJ44oJff5pprM5WBlHYYq9KMfRE8Q V+fJh1ex/++5p7MDzNX5Kfhq4XJF4xIe3naBaxU9pdJUGuBY4gvcgxOhc8tMSf93e5yl D2a0kC4tZCB16po+i5/5+PnJAMjgOjy1lsM/h7sjDb8tBYit4BrcJoj/RASvAZf70Cyk zzpYW6i1Qk/MbOxHlS3VMApS6zgoC4PST/3KIcJUnF2Lh37Nlk88RZHqk8fQNLICzKK5 Kqtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=v51YWuj05QBSQnbbjcB26OaTbfpQmAt28BTVA0AQFCk=; b=bgsV3e+ov0cUzY5KFY4+ydxrHnaT9VC4Kp/KqPO8pkWN3k44+eHQurLbUZhfO3zAVp 3xGTFpwrndjLTLSYEa1FOufOJSc0xCtVPt49ovi/EQ14d9ku/bjlPs8Jg5PDVZLm4Hir 3JsJYfyx8yXHfm1IUFuHIfeWHycZ4ioXH0NdYYc5XeSwrDOZE6tX2A+bltRTcWYCKQh0 wd2B/saTsJTjaFmlqU9eh6I8tP6j04jO/3eaFtK3SnEHjDKtk8aeVZhEc3b7KsZ/efRR wAzix7WwYAR62eTIEIy+wjp3T/MbacojuTx9MAxO1YpU+7W91dMtNAUj5ruK6sNuUolo MYyQ== X-Gm-Message-State: ALyK8tLFu7UIm06hK+1OV+Gk3nx914k4upDp3KK0YKM2lj+1eafK5CzUDiySrKUylQfn/w== X-Received: by 10.98.7.154 with SMTP id 26mr7131663pfh.2.1465513408655; Thu, 09 Jun 2016 16:03:28 -0700 (PDT) Received: from ?IPv6:2406:e007:655a:1:8cf6:73dd:3e9d:20bd? ([2406:e007:655a:1:8cf6:73dd:3e9d:20bd]) by smtp.gmail.com with ESMTPSA id ez6sm12537435pab.12.2016.06.09.16.03.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 16:03:28 -0700 (PDT) Subject: Happiness [was ULA-C [was: Testing ULAness]] To: Mark Andrews , Lorenzo Colitti References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 10 Jun 2016 11:03:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160609055921.7C4D04B09FBE@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 23:03:31 -0000 On 09/06/2016 17:59, Mark Andrews wrote: > > In message > , Lorenzo Colitti writes: >> On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews wrote: >> >>> And before you complain about "it takes a lot of time" there is >>> absolutely nothing stopping A from attempting to contact B over the >>> second address rapidly like one does with HE for IPv6 vs IPv4. >>> >> >> Nothing stops an implementation from doing that, but no implementations do >> that. > > And they don't do it because the primitive examples for how to > contact multihomed servers don't show how to do that. It really > is just a matter of education and spending a small amount of time > going back at retrofiting smart multihome server connection semantics. > >> As an industry, I think we need a better engineering answer than "try every >> possible combination all the time", because trying all combinations all the >> time is expensive in terms of CPU time, radio usage, and battery life. >> >> HE was a hack to aid in IPv6 deployment. It's time to retire it. > > When you can create a network without black holes then it is time > to retire it. To date I've yet to see anyone do that. +1. HE saved my sanity two days ago, for example, when my ISP chose to give me an IPv6 prefix but to black hole all IPv6 packets for a while. When that becomes physically impossible, we can retire HE. Brian > > Additionally local ULAs, GUA, other ULAs is the best default sort > order and generally results in a single connection attempt unless > there is a broken link. Where you use matching ULA, GUA and GUA > as the source address unless it is explicity overridden. > > Mark > From nobody Thu Jun 9 16:32:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565FE12D7BD for ; Thu, 9 Jun 2016 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nbtlkxmJex5H for ; Thu, 9 Jun 2016 16:32:33 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1361212D1B2 for ; Thu, 9 Jun 2016 16:32:32 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x189so52294030ywe.3 for ; Thu, 09 Jun 2016 16:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=lptIAXvFovDY36p47fRLDKddnzOr+qCPWnERRe1Bvus=; b=QjMPW6qOhLlAuQf+F8UEpfm/7XwIncgQHShM8wrJA1WaqHkauBbOPqfGEtql7PfK9z wtPIUm2CG0FG/z01RStp8l48TWkHKs/BDWRcQwv8ihvSoHV3RDzZUkJDfl+rIx61Z2G/ VvAIU67llNTV79oll5qS4RxZi95Tw2Pghn7ZP2uJ7c11xFUL31qY7OA9WDOhE7CZtUkN jaNL/P/6hXPSkCBx4Ff1wUiWs4DjuA5SMwMjCm77Ssl+tSdmIscXSezxCnEQeJwjz898 pryrTNXd3FFStGVGio68tqF0e5b9f0HWMhAkmCNO8Ir6t9WBcMjgGYQyfhzi/5F8oayl QGYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=lptIAXvFovDY36p47fRLDKddnzOr+qCPWnERRe1Bvus=; b=MSfUmEGOUvTsw1FqFmluNBkON+nfyZaweANliNtNtkru9w3RI/KT4JRziQgPOjeULu txVZ/Wbj97LaOcocjbhYbJG6nmDPVpLJq3tjKzkM63Y7iLGMz0I8t2tW5k4o8IGXGEuN 2nrqWou6TYLyZJi7wRl9XzWFnDJEt0efQyVbiie+qt8hkZXUm7mujqOnltoftOC+xIV+ 24yDM4zQv067Bs69jPj+Q/XWLpku14QJPO/aMoEXlQ3TPSDZSRqIFrpRmisVymImsJIy oio8zQhYuUyKMd5O6QzlZQjcj++pvhkHmJkL7RTw+kol+pLG3YJpj3PdAIbTA3dPZ964 Vhcg== X-Gm-Message-State: ALyK8tKBbbQ9EYbNe7JhHOAeimjewHvNBbZOSor3vRdEjsd4e7fI2Ph6tpqd0KRW10Lqgw== X-Received: by 10.37.223.5 with SMTP id w5mr285162ybg.139.1465515151367; Thu, 09 Jun 2016 16:32:31 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id l124sm4566086ywf.24.2016.06.09.16.32.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 16:32:29 -0700 (PDT) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9BB8A11E-B8D9-4145-B621-DC8FE0A2E060"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 9 Jun 2016 16:32:26 -0700 Message-Id: References: To: Brian Haberman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 23:32:35 -0000 --Apple-Mail=_9BB8A11E-B8D9-4145-B621-DC8FE0A2E060 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Brian, > On Jun 9, 2016, at 7:56 AM, Brian Haberman = wrote: >=20 > Sorry for the delay in responding, but I have been traveling... >=20 > On 6/5/16 12:37 AM, Brian E Carpenter wrote: >> Hi, >>=20 >> The IANA IPv6 Special-Purpose Address Registry* has a column marked = "Global". >> For fc00::/7 (ULA) this is set to "False". >>=20 >> That is surely wrong. ULAs are explicitly defined as having global = scope. >>=20 >> This has consequences. For example, in the Python ipaddress module, >> the property .is_global returns False on a ULA. The test for ULAness >> turns out to be (x.is_private and not x.is_link_local). >>=20 >> = *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-spec= ial-registry.xhtml >>=20 >=20 > I have not been able to work through this entire thread as of yet, but = I > wanted to respond to point above as one of the authors of the RFC that > created the registry. >=20 > Global is False given that, while probably unique, these addresses are > not guaranteed globally routable. 4193 says: >=20 > Their limitation is in the routability of the prefixes, which is > limited to a site and any explicit routing agreements with other > sites to propagate them... >=20 > The authors of 6890 discussed this at length both amongst ourselves = and > with the larger community. The consensus was that ULAs are not > guaranteed globally routable. You are correct about RFC4193, but the confusion is that the text in = RFC6890 that defines Global doesn=92t mention globally routable. It = says something much more limited: o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain. I read that as covered by "any explicit routing agreements with other = sites to propagate=94, not globally routable. Some sort of = clarification or errata for this RFC and IANA registry is needed. Bob --Apple-Mail=_9BB8A11E-B8D9-4145-B621-DC8FE0A2E060 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 iQEcBAEBCgAGBQJXWfyKAAoJEK7rdBF357uoIFsIALZThtzR9vLTQoN4nr0tf1y9 OFg4NnX+ymmTkKjp3roxdqDp4Jp8Kof3MDAtNfwY1/xWRg2bRQWXghYceOWvmfsn nSTHQ3zEJJrXof2tdlY9p3Y1LUnp8x6aBj99hZ9SSljecVnUKaR+x+xELMWGCVtX BPV1xEAoa0mA2lHpHZQBnY8IcX9hBv6nJ3JTOQpP14YF0rfOj3eeQu9GpNM1bCUc xzC0GNkiLxe8qQBxEfkWYgyRxhumiIagu6ifKXkKZDJ1ZlPrsGGl6ZVNip8+JOHz biiSNK29i7ZpUfycazNzJ1p31b1RKOBkJ7xwjfsGG9VH0JJ2b4P0DUcL63oXSH4= =EqC4 -----END PGP SIGNATURE----- --Apple-Mail=_9BB8A11E-B8D9-4145-B621-DC8FE0A2E060-- From nobody Fri Jun 10 02:39:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5312D572 for ; Fri, 10 Jun 2016 02:39:28 -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 autolearn_force=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 96E2g9DdK0uf for ; Fri, 10 Jun 2016 02:39:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8512B03E for ; Fri, 10 Jun 2016 02:39:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bBIuR-0000KTC; Fri, 10 Jun 2016 11:39:23 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Happiness [was ULA-C [was: Testing ULAness]] From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> In-reply-to: Your message of "Fri, 10 Jun 2016 11:03:35 +1200 ." Date: Fri, 10 Jun 2016 11:39:22 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:39:28 -0000 In your letter dated Fri, 10 Jun 2016 11:03:35 +1200 you wrote: >+1. HE saved my sanity two days ago, for example, when my ISP chose >to give me an IPv6 prefix but to black hole all IPv6 packets for a >while. When that becomes physically impossible, we can retire HE. Another use case for HE tunnels: my ISP provides native IPv6 but believes that only a hand full of customers would need reverse DNS and therefor it it is not a priority. So I use a HE tunnel for outgoing traffic. From nobody Fri Jun 10 02:47:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720E212D190 for ; Fri, 10 Jun 2016 02:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 2mWIizLmxRwe for ; Fri, 10 Jun 2016 02:46:57 -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 1EF5812D94C for ; Fri, 10 Jun 2016 02:46:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u5A9kies002129 for ; Fri, 10 Jun 2016 11:46:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BFE48205267 for ; Fri, 10 Jun 2016 11:47:17 +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 B92FF205232 for ; Fri, 10 Jun 2016 11:47:17 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u5A9khRR031061 for ; Fri, 10 Jun 2016 11:46:44 +0200 Subject: Re: Happiness [was ULA-C [was: Testing ULAness]] To: ipv6@ietf.org References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <6b103628-8403-6444-5791-c8c280b17129@gmail.com> Date: Fri, 10 Jun 2016 11:46:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:47:01 -0000 Le 10/06/2016 à 01:03, Brian E Carpenter a écrit : > On 09/06/2016 17:59, Mark Andrews wrote: >> >> In message >> >> >> , Lorenzo Colitti writes: >>> On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews >>> wrote: >>> >>>> And before you complain about "it takes a lot of time" there >>>> is absolutely nothing stopping A from attempting to contact B >>>> over the second address rapidly like one does with HE for IPv6 >>>> vs IPv4. >>>> >>> >>> Nothing stops an implementation from doing that, but no >>> implementations do that. >> >> And they don't do it because the primitive examples for how to >> contact multihomed servers don't show how to do that. It really is >> just a matter of education and spending a small amount of time >> going back at retrofiting smart multihome server connection >> semantics. >> >>> As an industry, I think we need a better engineering answer than >>> "try every possible combination all the time", because trying all >>> combinations all the time is expensive in terms of CPU time, >>> radio usage, and battery life. >>> >>> HE was a hack to aid in IPv6 deployment. It's time to retire it. >> >> When you can create a network without black holes then it is time >> to retire it. To date I've yet to see anyone do that. > > +1. HE saved my sanity two days ago, for example, when my ISP chose > to give me an IPv6 prefix but to black hole all IPv6 packets for a > while. When that becomes physically impossible, we can retire HE. A colleague plans to use Hurricane Electric tunnelling (HE) soon to make measurements of IPv6 energy consumption on a smartphone; HE because in that part of the world there is too little chance to get a native IPv6 connection at this time. It's a topic that makes laugh when mentioned. There are many other parts of the world where native IPv6 is not for soon. In April I discussed with an Argentinian network responsible and was told that the IPv6 arrival in the Malvine islands is something never heard of. And there there was that same smile on her face as when I ask IPv6 in other regions. And my experience teaches me there is usually a certain lapse of time between never hearing of IPv6 and deployment. Alex > > Brian > >> >> Additionally local ULAs, GUA, other ULAs is the best default sort >> order and generally results in a single connection attempt unless >> there is a broken link. Where you use matching ULA, GUA and GUA as >> the source address unless it is explicity overridden. >> >> Mark >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 10 02:54:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA23212D0E3 for ; Fri, 10 Jun 2016 02:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 kE0Dq9Tc5lK9 for ; Fri, 10 Jun 2016 02:54:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8EC128E18 for ; Fri, 10 Jun 2016 02:54:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D56E910EF for ; Fri, 10 Jun 2016 11:54:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PGslAxlZ_ZHA for ; Fri, 10 Jun 2016 11:54:19 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 10 Jun 2016 11:54:23 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C36252004E for ; Fri, 10 Jun 2016 11:54:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6eIuk4JRr8oc for ; Fri, 10 Jun 2016 11:54:22 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5317D20047 for ; Fri, 10 Jun 2016 11:54:22 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 11:54:21 +0200 From: "Bajpai, Vaibhav" To: "ipv6@ietf.org" Subject: Re: Happiness [was ULA-C [was: Testing ULAness]] Thread-Topic: Happiness [was ULA-C [was: Testing ULAness]] Thread-Index: AQHRwqMwmkAvGTmge0uCV8P28UzylZ/iUy+AgAACIIA= Date: Fri, 10 Jun 2016 09:54:21 +0000 Message-ID: References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> <6b103628-8403-6444-5791-c8c280b17129@gmail.com> In-Reply-To: <6b103628-8403-6444-5791-c8c280b17129@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [122.163.252.97] Content-Type: multipart/signed; boundary="Apple-Mail=_09DE2B69-6564-44BE-936D-928A84DFFB9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:54:29 -0000 --Apple-Mail=_09DE2B69-6564-44BE-936D-928A84DFFB9A X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, I think the thread was initially talking about happy eyeballs (HE), but = the recent replies have digressed it into hurricane electric (HE). Let=92s please expand acronyms when using them. Thanks! Best, Vaibhav > On 10 Jun 2016, at 15:16, Alexandre Petrescu = wrote: >=20 > Le 10/06/2016 =E0 01:03, Brian E Carpenter a =E9crit : >> On 09/06/2016 17:59, Mark Andrews wrote: >>>=20 >>> In message >>> >>>=20 >>>=20 > , Lorenzo Colitti writes: >>>> On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews >>>> wrote: >>>>=20 >>>>> And before you complain about "it takes a lot of time" there >>>>> is absolutely nothing stopping A from attempting to contact B >>>>> over the second address rapidly like one does with HE for IPv6 >>>>> vs IPv4. >>>>>=20 >>>>=20 >>>> Nothing stops an implementation from doing that, but no >>>> implementations do that. >>>=20 >>> And they don't do it because the primitive examples for how to >>> contact multihomed servers don't show how to do that. It really is >>> just a matter of education and spending a small amount of time >>> going back at retrofiting smart multihome server connection >>> semantics. >>>=20 >>>> As an industry, I think we need a better engineering answer than >>>> "try every possible combination all the time", because trying all >>>> combinations all the time is expensive in terms of CPU time, >>>> radio usage, and battery life. >>>>=20 >>>> HE was a hack to aid in IPv6 deployment. It's time to retire it. >>>=20 >>> When you can create a network without black holes then it is time >>> to retire it. To date I've yet to see anyone do that. >>=20 >> +1. HE saved my sanity two days ago, for example, when my ISP chose >> to give me an IPv6 prefix but to black hole all IPv6 packets for a >> while. When that becomes physically impossible, we can retire HE. >=20 > A colleague plans to use Hurricane Electric tunnelling (HE) soon to = make > measurements of IPv6 energy consumption on a smartphone; HE because in > that part of the world there is too little chance to get a native IPv6 > connection at this time. It's a topic that makes laugh when = mentioned. >=20 > There are many other parts of the world where native IPv6 is not for > soon. In April I discussed with an Argentinian network responsible = and > was told that the IPv6 arrival in the Malvine islands is something = never > heard of. And there there was that same smile on her face as when I = ask > IPv6 in other regions. And my experience teaches me there is usually = a > certain lapse of time between never hearing of IPv6 and deployment. >=20 > Alex >=20 >>=20 >> Brian >>=20 >>>=20 >>> Additionally local ULAs, GUA, other ULAs is the best default sort >>> order and generally results in a single connection attempt unless >>> there is a broken link. Where you use matching ULA, GUA and GUA as >>> the source address unless it is explicity overridden. >>>=20 >>> Mark >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_09DE2B69-6564-44BE-936D-928A84DFFB9A X-Clacks-Overhead: GNU Terry Pratchett 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 iQEcBAEBCgAGBQJXWo5MAAoJEHR3XKwTWKOZd20H/3hLFG+ssFUI6sb3njiifEbs koM0WqGn+aVvzgGnERLwdLzGySWtIFIyH1WlKfuGIFuFV0oDfwzfrIZtmj+tqbZw xkFu0ERAcC/RCE3SrKP6Mj4hIUvx+Av0jx/A9JcHmAAOjoTVSapnYqMwgIpj3giX VgRNp5gBujdB4XYZHSh5pjqK1WVvNMbYAUq0skQB/dJTcH49xs2ogSJ+yi6jwxD2 p+A4N0S7spbkiEEjDh/h5Lf0bim/4WcemgwwGQrNIw6+ruw7Xtk18en0dR75ak1m jit0mSQtwidicKF8cWpWZoUJ6Z3Vzk1Ye+1jbXsvDKDxt7YpES80bQtMMr/ysoI= =4J16 -----END PGP SIGNATURE----- --Apple-Mail=_09DE2B69-6564-44BE-936D-928A84DFFB9A-- From nobody Fri Jun 10 03:07:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4A12B05C for ; Fri, 10 Jun 2016 03:07:56 -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 autolearn_force=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 n8OZbtO93ud6 for ; Fri, 10 Jun 2016 03:07:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C110D128E18 for ; Fri, 10 Jun 2016 03:07:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bBJM1-0000JbC; Fri, 10 Jun 2016 12:07:53 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Happiness [was ULA-C [was: Testing ULAness]] From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> <20468B75-7ABF-4D81-8724-02F797701AA5@employees.org> In-reply-to: Your message of "Fri, 10 Jun 2016 11:43:34 +0200 ." <20468B75-7ABF-4D81-8724-02F797701AA5@employees.org> Date: Fri, 10 Jun 2016 12:07:53 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:07:56 -0000 >I think HE meant Happy Eyeballs in this thread not Hurricane Electric. = >;-) The discussion on NANOG was larger than this one. :-) I guess using HE for happy eyeballs is just too confusing. From nobody Fri Jun 10 04:23:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5C312D56D for ; Fri, 10 Jun 2016 04:23:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 etOkYIcbBYu7 for ; Fri, 10 Jun 2016 04:23: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 D555912D1D0 for ; Fri, 10 Jun 2016 04:23:31 -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 C12FB880C2; Fri, 10 Jun 2016 04:23:31 -0700 (PDT) Received: from [192.168.6.88] (rrcs-24-142-187-66.central.biz.rr.com [24.142.187.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5714F328081A; Fri, 10 Jun 2016 04:23:31 -0700 (PDT) Date: Fri, 10 Jun 2016 07:23:25 -0400 Subject: Re: Testing ULAness From: Brian Haberman To: Bob Hinden MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: <20160610112331.5714F328081A@clairseach.fuaim.com> Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:23:34 -0000 Qm9iLAogICAgIFRoZSBrZXkgcGFydCBvZiB0aGF0IGRlZmluaXRpb24gaXMgdGhlIGxhc3QgcGFy dCBhYm91dCAiYmV5b25kIGFuIGFkbWluaXN0cmF0aXZlIGJvdW5kYXJ5Iiwgd2hpY2ggaXMgd2hl cmUgdGhlIGFzcGVjdHMgb2YgNDE5MyBjb21lIGluLgoKQnJpYW4gT24gSnVuIDksIDIwMTYgNzoz MiBQTSwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOgo+Cj4gQnJpYW4s IAo+Cj4gPiBPbiBKdW4gOSwgMjAxNiwgYXQgNzo1NiBBTSwgQnJpYW4gSGFiZXJtYW4gPGJyaWFu QGlubm92YXRpb25zbGFiLm5ldD4gd3JvdGU6IAo+ID4gCj4gPiBTb3JyeSBmb3IgdGhlIGRlbGF5 IGluIHJlc3BvbmRpbmcsIGJ1dCBJIGhhdmUgYmVlbiB0cmF2ZWxpbmcuLi4gCj4gPiAKPiA+IE9u IDYvNS8xNiAxMjozNyBBTSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6IAo+ID4+IEhpLCAKPiA+ PiAKPiA+PiBUaGUgSUFOQSBJUHY2IFNwZWNpYWwtUHVycG9zZSBBZGRyZXNzIFJlZ2lzdHJ5KiBo YXMgYSBjb2x1bW4gbWFya2VkICJHbG9iYWwiLiAKPiA+PiBGb3IgZmMwMDo6LzcgKFVMQSkgdGhp cyBpcyBzZXQgdG8gIkZhbHNlIi4gCj4gPj4gCj4gPj4gVGhhdCBpcyBzdXJlbHkgd3JvbmcuIFVM QXMgYXJlIGV4cGxpY2l0bHkgZGVmaW5lZCBhcyBoYXZpbmcgZ2xvYmFsIHNjb3BlLiAKPiA+PiAK PiA+PiBUaGlzIGhhcyBjb25zZXF1ZW5jZXMuIEZvciBleGFtcGxlLCBpbiB0aGUgUHl0aG9uIGlw YWRkcmVzcyBtb2R1bGUsIAo+ID4+IHRoZSBwcm9wZXJ0eSAuaXNfZ2xvYmFsIHJldHVybnMgRmFs c2Ugb24gYSBVTEEuIFRoZSB0ZXN0IGZvciBVTEFuZXNzIAo+ID4+IHR1cm5zIG91dCB0byBiZSAo eC5pc19wcml2YXRlIGFuZCBub3QgeC5pc19saW5rX2xvY2FsKS4gCj4gPj4gCj4gPj4gKmh0dHA6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWFuYS1pcHY2LXNwZWNpYWwtcmVnaXN0cnkvaWFu YS1pcHY2LXNwZWNpYWwtcmVnaXN0cnkueGh0bWwgCj4gPj4gCj4gPiAKPiA+IEkgaGF2ZSBub3Qg YmVlbiBhYmxlIHRvIHdvcmsgdGhyb3VnaCB0aGlzIGVudGlyZSB0aHJlYWQgYXMgb2YgeWV0LCBi dXQgSSAKPiA+IHdhbnRlZCB0byByZXNwb25kIHRvIHBvaW50IGFib3ZlIGFzIG9uZSBvZiB0aGUg YXV0aG9ycyBvZiB0aGUgUkZDIHRoYXQgCj4gPiBjcmVhdGVkIHRoZSByZWdpc3RyeS4gCj4gPiAK PiA+IEdsb2JhbCBpcyBGYWxzZSBnaXZlbiB0aGF0LCB3aGlsZSBwcm9iYWJseSB1bmlxdWUsIHRo ZXNlIGFkZHJlc3NlcyBhcmUgCj4gPiBub3QgZ3VhcmFudGVlZCBnbG9iYWxseSByb3V0YWJsZS4g NDE5MyBzYXlzOiAKPiA+IAo+ID7CoMKgIFRoZWlyIGxpbWl0YXRpb24gaXMgaW4gdGhlIHJvdXRh YmlsaXR5IG9mIHRoZSBwcmVmaXhlcywgd2hpY2ggaXMgCj4gPsKgwqAgbGltaXRlZCB0byBhIHNp dGUgYW5kIGFueSBleHBsaWNpdCByb3V0aW5nIGFncmVlbWVudHMgd2l0aCBvdGhlciAKPiA+wqDC oCBzaXRlcyB0byBwcm9wYWdhdGUgdGhlbS4uLiAKPiA+IAo+ID4gVGhlIGF1dGhvcnMgb2YgNjg5 MCBkaXNjdXNzZWQgdGhpcyBhdCBsZW5ndGggYm90aCBhbW9uZ3N0IG91cnNlbHZlcyBhbmQgCj4g PiB3aXRoIHRoZSBsYXJnZXIgY29tbXVuaXR5LiBUaGUgY29uc2Vuc3VzIHdhcyB0aGF0IFVMQXMg YXJlIG5vdCAKPiA+IGd1YXJhbnRlZWQgZ2xvYmFsbHkgcm91dGFibGUuIAo+Cj4gWW91IGFyZSBj b3JyZWN0IGFib3V0IFJGQzQxOTMsIGJ1dCB0aGUgY29uZnVzaW9uIGlzIHRoYXQgdGhlIHRleHQg aW4gUkZDNjg5MCB0aGF0IGRlZmluZXMgR2xvYmFsIGRvZXNu4oCZdCBtZW50aW9uIGdsb2JhbGx5 IHJvdXRhYmxlLsKgIEl0IHNheXMgc29tZXRoaW5nIG11Y2ggbW9yZSBsaW1pdGVkOiAKPgo+IG/C oMKgwqAgR2xvYmFsIC0gQSBib29sZWFuIHZhbHVlIGluZGljYXRpbmcgd2hldGhlciBhbiBJUCBk YXRhZ3JhbSB3aG9zZSAKPiDCoMKgwqDCoCBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGRyYXduIGZy b20gdGhlIGFsbG9jYXRlZCBzcGVjaWFsLXB1cnBvc2UgCj4gwqDCoMKgwqAgYWRkcmVzcyBibG9j ayBpcyBmb3J3YXJkYWJsZSBiZXlvbmQgYSBzcGVjaWZpZWQgYWRtaW5pc3RyYXRpdmUgCj4gwqDC oMKgwqAgZG9tYWluLiAKPgo+IEkgcmVhZCB0aGF0IGFzIGNvdmVyZWQgYnkgImFueSBleHBsaWNp dCByb3V0aW5nIGFncmVlbWVudHMgd2l0aCBvdGhlciBzaXRlcyB0byBwcm9wYWdhdGXigJ0sIG5v dCBnbG9iYWxseSByb3V0YWJsZS7CoCBTb21lIHNvcnQgb2YgY2xhcmlmaWNhdGlvbiBvciBlcnJh dGEgZm9yIHRoaXMgUkZDIGFuZCBJQU5BIHJlZ2lzdHJ5IGlzIG5lZWRlZC4gCj4KPiBCb2IgCj4K Pgo+Cg== From nobody Fri Jun 10 04:58:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE8F12B02D for ; Fri, 10 Jun 2016 04:58:11 -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 autolearn_force=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 Dxmo8F88WNsF for ; Fri, 10 Jun 2016 04:58:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9E12D179 for ; Fri, 10 Jun 2016 04:58:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bBL4j-0000EnC; Fri, 10 Jun 2016 13:58:09 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: ULA-C [was: Testing ULAness] From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> In-reply-to: Your message of "Thu, 9 Jun 2016 09:04:08 +0200 ." Date: Fri, 10 Jun 2016 13:58:08 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:58:12 -0000 In your letter dated Thu, 9 Jun 2016 09:04:08 +0200 you wrote: >> As an industry, I think we need a better engineering answer than "try >every possible combination all the time", because trying all >combinations all the time is expensive in terms of CPU time, radio >usage, and battery life. >> >> HE was a hack to aid in IPv6 deployment. It's time to retire it. > >I disagree. >I a host should optimally try all combinations, monitor them, failover >between them, load-share across them... >it can obviously be smart about it, and probabilistically prefer some >SA/DA pairs over others at connection time. > >I've not seen any other credible alternative to deal with host based >multi-homing. >even if you were only connected via a single interface to a multi-prefix >network, the network has very limited knowledge about the path >performance to the destination. I can see two problems with happy eyeballs: 1) Only connection setup gets tested. If that connection has bad performance there is no fallback 2) There is no happy eyeballs protocol. It is just a vague description of a technique. For the first problem, MPTCP would be more suitable than happy eyeballs. For the second problem, I think there should be a clear base line that can just be implemented. Not an endless variety of possibilities, but something that is expected to work well in many cases and does not overload the network. Of course implementation can go beyond that. But without something that is simple to convert into code, it may take forever for embedded devices, etc. to do something sensible in this area. From nobody Fri Jun 10 08:37:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F0912D60E for ; Fri, 10 Jun 2016 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c3iGTwYUC_xZ for ; Fri, 10 Jun 2016 08:37:28 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CA412D62F for ; Fri, 10 Jun 2016 08:37:28 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m124so107092233wme.1 for ; Fri, 10 Jun 2016 08:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=TSnhc4Sc+qhDAb0tWrBLX5ERlEMsjJsnCOfNoRwpnrA=; b=Syt3HUo7D8FnOgFcB65LkxBts/TjVdO1WekImdyW+ESMl+fzqayRVWY8HaMThc8SjQ ktAU6OwUDX34unjLndoWDC37wR60Kr/OVHBWkpykiOHa4ymennbW/o2RnzvMZX4587Ph Rr2deLBnXmGwE4sJUPkyekUnLM3lVbsKU/PIfvVl6AZdMISmWiSPbkkg8lXXkrvKgQnW u1VIP7lOIZoaG0mnA5dhKGQ5KooFvjtsGqX51JaGk1Fuo60rvkd1jVh7uVv7oDuNkWFL MjZdVu/mHQHy1k2y2ndMa6mhxQ4fPm0nDOlUQ0uPBQqG3RpzqlinS9Ffgo9yQl86xP7S +WFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=TSnhc4Sc+qhDAb0tWrBLX5ERlEMsjJsnCOfNoRwpnrA=; b=mqtVOqHsrHs4jojrdt+99rX33vcAphrIyhir1FAdJo85Lp7vd11dTn6RMfntelLv1r cVkHswPDRA34zIhyrS5HIsn4IDwl3RWLy0FGWddoBOTTF1OHONuvl0Ya33UzptDK5VjL eJSUSLRxEsVXUlky34UMc4bFcgpdW9S0vvZ/ooEA9VHtkcx5Q+/++CngthjJO3JAeU7V 1tfaq5992oiBw3VSdDuVxPSRMoa+lNvc9Gyc96Pdi+RHQXsl6rDgpoUqVARMJTekegr4 At9roWF4lyjDKek+rWDSoLASn9cts9l0vakVS/rtPOafhj/S5/Dkvmxv+UBrjSnO+qvB 4ZSg== X-Gm-Message-State: ALyK8tLHkRdp0NBW9NHbl1mT48ASabcPTAByBVsJ2v2VzgpEhkbCMDxqY3B6vH3lLHBsIg== X-Received: by 10.28.39.196 with SMTP id n187mr3372455wmn.4.1465573046053; Fri, 10 Jun 2016 08:37:26 -0700 (PDT) Received: from [10.0.0.24] (c-71-202-18-198.hsd1.ca.comcast.net. [71.202.18.198]) by smtp.gmail.com with ESMTPSA id m5sm3875262wmm.10.2016.06.10.08.37.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 08:37:24 -0700 (PDT) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0341F9C4-7E20-47CE-AC27-5FA961B05415"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <20160610112331.5714F328081A@clairseach.fuaim.com> Date: Fri, 10 Jun 2016 08:37:20 -0700 Message-Id: References: <20160610112331.5714F328081A@clairseach.fuaim.com> To: Brian Haberman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 15:37:30 -0000 --Apple-Mail=_0341F9C4-7E20-47CE-AC27-5FA961B05415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Jun 10, 2016, at 4:23 AM, Brian Haberman = wrote: >=20 > Bob, > The key part of that definition is the last part about "beyond an = administrative boundary", which is where the aspects of 4193 come in. I get that, but that can be achieved by two ASs sharing a route for a = specific ULA prefix. If the intent is that global means "global = routable=E2=80=9D then the RFC should say so in a clear manner. For = example, something like: o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is routed globally. I could file an errata. Bob >=20 > Brian On Jun 9, 2016 7:32 PM, Bob Hinden wrote: >>=20 >> Brian, >>=20 >>> On Jun 9, 2016, at 7:56 AM, Brian Haberman = wrote: >>>=20 >>> Sorry for the delay in responding, but I have been traveling... >>>=20 >>> On 6/5/16 12:37 AM, Brian E Carpenter wrote: >>>> Hi, >>>>=20 >>>> The IANA IPv6 Special-Purpose Address Registry* has a column marked = "Global". >>>> For fc00::/7 (ULA) this is set to "False". >>>>=20 >>>> That is surely wrong. ULAs are explicitly defined as having global = scope. >>>>=20 >>>> This has consequences. For example, in the Python ipaddress module, >>>> the property .is_global returns False on a ULA. The test for = ULAness >>>> turns out to be (x.is_private and not x.is_link_local). >>>>=20 >>>> = *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-spec= ial-registry.xhtml >>>>=20 >>>=20 >>> I have not been able to work through this entire thread as of yet, = but I >>> wanted to respond to point above as one of the authors of the RFC = that >>> created the registry. >>>=20 >>> Global is False given that, while probably unique, these addresses = are >>> not guaranteed globally routable. 4193 says: >>>=20 >>> Their limitation is in the routability of the prefixes, which is >>> limited to a site and any explicit routing agreements with other >>> sites to propagate them... >>>=20 >>> The authors of 6890 discussed this at length both amongst ourselves = and >>> with the larger community. The consensus was that ULAs are not >>> guaranteed globally routable. >>=20 >> You are correct about RFC4193, but the confusion is that the text in = RFC6890 that defines Global doesn=E2=80=99t mention globally routable. = It says something much more limited: >>=20 >> o Global - A boolean value indicating whether an IP datagram whose >> destination address is drawn from the allocated special-purpose >> address block is forwardable beyond a specified administrative >> domain. >>=20 >> I read that as covered by "any explicit routing agreements with other = sites to propagate=E2=80=9D, not globally routable. Some sort of = clarification or errata for this RFC and IANA registry is needed. >>=20 >> Bob >>=20 >>=20 >>=20 --Apple-Mail=_0341F9C4-7E20-47CE-AC27-5FA961B05415 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 iQEcBAEBCgAGBQJXWt6wAAoJEK7rdBF357uourIIAIp+aJMe9DvQr+Q7yf5bCqC2 r+w/w842XL849xIPCTndth4vf8vQZvCvAzdjSMxPiwNR69SiDe644I17paJBN5/I IS9jjVQPZuHaHiVowD1VGfjWbGmyaFDeT3Q7NyE05/HhzHzWynEIE21TvsJGLcfF CRjddekQSm5CrtF9CTDC0AYUmKO++cbc3NR9M9yxyf5G5N/TlW+T59YFsxYk74qu wrl4oB4GZUcPRgt3k9NuKr5FFQIbo/0LcEYufY2DbXK/ZtFe2yDK/0uDhW6Z9S7s eh3h9WgLFbr0W7lx285drmZZQwN3mPtABPKNA0PglaO4y+hX0XTfVVOdbNb4M7g= =FsKK -----END PGP SIGNATURE----- --Apple-Mail=_0341F9C4-7E20-47CE-AC27-5FA961B05415-- From nobody Fri Jun 10 09:13:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F156F12D81D for ; Fri, 10 Jun 2016 09:13:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 cZ879ids7e_8 for ; Fri, 10 Jun 2016 09:13:27 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61DE12D82C for <6man@ietf.org>; Fri, 10 Jun 2016 09:13:26 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id z189so185608298itg.0 for <6man@ietf.org>; Fri, 10 Jun 2016 09:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=Zw1ZDKHtefRLxUnQDWujVsAxCwfd+afBYomrH+lznbg=; b=SnWiicbJ7F/wUcEZaFfmGUwTqF0PixB1uqB6udKKkV4gW3ADh+E3zz2WI0tEk+MsFc t+aFRnTmXP4qh9/XoueuAJ9enxieEGv/uoupxE7BEVj296cGciZEnwBS4332fM8ewpQM rTdOZrfCxkCZUbVc1xPZxrRd2TJwBPXWwD0SgI5F0I4UGwm+akrIkVyDj3Kd7rWgca1k JKil3y7T8mR08TRj0i18x3TDQB/QrwjgqBf8nrIQkiNvwYELWMVC76JdtVkqdEQJp4w/ FI8pepOrCbqGGZoPR0/xm+VusAZtTPTyFsRnbT/kYz60vzodj80EiziouFpKjelCouas vNog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Zw1ZDKHtefRLxUnQDWujVsAxCwfd+afBYomrH+lznbg=; b=LoywoCLeb8cv6ushP6hughjhu/RVj1/s2Gc8jUgBkE5kLl+PYjnUeWs+iWwwy79+f6 ew62ajiwDuUJYpIu0QEy58dPsegPxw2w9Fr/xpsgIpJHqVqtJuSphi3b9JC832CCX59Z De2F/Zp4cE9CnIGZPt5mUq5w/tR+kfK5MWdSM5NQ0EioBqI9QfLmD5vXKI1aIzMKe0cL 9SRWmncMapXpSPkFq4xjMmjYdduioqIYVZ3R1dkLAxmMzobLuw1rLA+oVxt7b5aCdItd jdirB8MtB/5PuzSBdkZf/RFRc0LQ/lBPsCzgPqst/M2V83ftSwZsrL0CGuU4ZsdNe5vB y0YA== X-Gm-Message-State: ALyK8tIkvmrUkeKUN9iO+8DXlsai5g60IKQ7nKP20e01fpQ2GgJ5kD48Mmy6kNbp96lO0zrTNZ4lrrwbUt9tmQ== MIME-Version: 1.0 X-Received: by 10.36.22.195 with SMTP id a186mr5581531ita.37.1465575206230; Fri, 10 Jun 2016 09:13:26 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 09:13:26 -0700 (PDT) Date: Fri, 10 Jun 2016 09:13:26 -0700 Message-ID: Subject: Hop-by-hop options in 2460bis From: Tom Herbert To: 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:13:29 -0000 >From the draft: "It should be noted that due to performance restrictions nodes may ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop option header, or assign packets containing a hop-by-hop option header to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour." This effectively makes deployment of Hop-by-Hop options a nonstarter. For instance, if my packets go through ten routers to a destination, and nine routers implement the my HBH option but the tenth drops it, then HBH is unusable for that destination. Also, with this text we cannot claim that the tenth router is out of compliance, and if the tenth router throws HBH into a slow path instead that doesn't really help us much either to deploy at scale. If processing HBH is a performance issue then a node should ignore it. I suggest this alternate text for the above paragraph. "A intermediate node in the path of a packet MUST either process the Hop-by-Hop Option header or ignore it. A node MUST NOT drop a packet solely on the basis that the Hop-by-Hop Option header is present." Also, I think there is also a potential ambiguity is this text: "The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type:" Since intermediate nodes can process HBH options are they expected to take this actions? I think the answer should be no, it seems like only the receiver should be allowed to drop packets with unknown options. Note that if intermediate nodes are allowed to ignore the HBH option this might be in conflict with the rules about handling unrecognized options-- all options in that case are implicitly skipped. Tom From nobody Fri Jun 10 09:23:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD99712D5CD for ; Fri, 10 Jun 2016 09:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 96uqH3JuW0T0 for ; Fri, 10 Jun 2016 09:23:22 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9923212D11C for <6man@ietf.org>; Fri, 10 Jun 2016 09:23:22 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id o127so23845673iod.2 for <6man@ietf.org>; Fri, 10 Jun 2016 09:23:22 -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; bh=TRHQgIPpwzNB1ETSCx3wfjnvbJ/QiCW3T4qBTwLbu2A=; b=eys2GVn/zHoJA9gr0QkjbjeyeqeWsty/ZALUwGpKfUguDH0bNE72QIj5CT1KBu7Y1I TlpGihF/aRsqcDwy7e/5akwYyR0pr/MeG/Pe1WozFtfg2H9tsgfHCXd0ba4U/KALSKsk /OJ1UKO2Z2hFp+32+AEBqTHtL1oZNNLVQZjZ3dSwkmrmGywz1MdbAm27CQkBikO+hQSg W+Bpa2Kiy92BVMtE5idAgH4YX7CNblNKNCn6hVmR00CX/q1bpvTQarQ/rNoXYRi7yJlT BW/1C3l4+jBtPTaIgLMIRSNpUdsVYBP7c3Y7crVupsj8Azh0OE0xgVUoE5sA8NwlMnnf Q8UA== 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; bh=TRHQgIPpwzNB1ETSCx3wfjnvbJ/QiCW3T4qBTwLbu2A=; b=NGklggcNsN/3DOjwHhaf3da3Ygynjdkv3fqXHYfb9RZQMTdOzRm5PGSazqEQSyzMJ1 vkPdgwAv9iM/gGMXDgjU7OwO3JaiDnsMk9P2Wkl7FMP7GDe5oxP+AP0b339vGjC99Skk 1MtlT95fEFG3R3QuWZu3/KJ1j9ro4JYYB2Nckp8l3F12xjncFsFLLYFaVJbZqZNNekr3 4z60g1eAG21qqBAzjY/cZ/9ERUGhmsXWtOOWPP7EIFD8t2uX2A9gnzjEhVuR/t7W+ZAc 2iEHfJQT2GvDO7bkJPHdy4FWBatk//if4XcG53E6ljQpBn47VAZXTZhGAMv8Tjp9L/Qp DHew== X-Gm-Message-State: ALyK8tLr+nPlctR7ffZHZ/MLd+yyAGJRyCALruBUZiRfh/0SPPxu2aSIUonGDbEN9hLIHugcvRuMqGD3Og5sebVC X-Received: by 10.107.39.144 with SMTP id n138mr5268205ion.145.1465575801765; Fri, 10 Jun 2016 09:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.68.169 with HTTP; Fri, 10 Jun 2016 09:23:02 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Fri, 10 Jun 2016 09:23:02 -0700 Message-ID: Subject: Re: Hop-by-hop options in 2460bis To: Tom Herbert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:23:24 -0000 I agree with your concern, but I'm skeptical that "ignore" will be a practical option, since everybody loves to get their hands on port numbers--even if only for incrementing logging counters. From nobody Fri Jun 10 09:32:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2A612D94C for ; Fri, 10 Jun 2016 09:32:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 A7IG3PA4wUbL for ; Fri, 10 Jun 2016 09:32:01 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A395112D84F for <6man@ietf.org>; Fri, 10 Jun 2016 09:32:00 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id z189so186055778itg.0 for <6man@ietf.org>; Fri, 10 Jun 2016 09:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1F0JYfgUunJ13pZyC/Kp/CRoiuqgGmbGv8fPuXtA5dA=; b=yyS06apUXJVswKjf/A6im90ZHyRASMa565Ix8KE3GFVnubW3nLAsA0ZHZAPt/cNyfd czuvP9cqcQCqpfQ8hS0Y6+1RZVKaYmQArfDxB0w89uWPsoSlo6T8hkiT98svGWG9FOUq Pkwc8dxSl2p8EDmnB7c4O5x81ozWly1OFbsi28tCmpl2Hc1B2oGY602T3qwkY1Pp+ZSC ib0w1T4JcDPgswG+uTuXhsoNNcc8U5M/2PVZKhfU5HVqZGZ21TWPh4mCjor9QBnRUOhB w3vmA74+QQsYz787ijJPbDapC14iPfqLjGp7mftYvlEfz8NS4ZwBxwczEULEHlaaFOfV kYIA== 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:date :message-id:subject:from:to:cc; bh=1F0JYfgUunJ13pZyC/Kp/CRoiuqgGmbGv8fPuXtA5dA=; b=etF+CD8DsjtOSr6j5LmvNBY7ekHRMHghpVD1+CL4hnj0DT0R4wjVJdbDLyO/v/5Xfs /GyI7I7l0rApmu4x0vmt6PrqDY5VTz6bDGlyp/Df6QlWuDqBuPIyRB4pqD/hfnExO0D/ LRb21ApdLPeXCp7KmOpIBi4y5JTHhLYPHktG+80T0/LEOBWcprJgJABTfsz7Mu3+onbU Y7R2GEZ2GNQt6/wNgO5S+qsHmMBbFzTnDEL5x+vYrdk9ZbJx64AzCB0T+HX3k3XC8rpG WEQSIOfCC2Egfz8T2gDKUQn+90IR+Y5rRE0Gh4tiNZzQLoKIETTxK6X71Mn3WsARsQz4 veSg== X-Gm-Message-State: ALyK8tJqZhCM01u+/RTPX/lOOhXEykoEdiiZXnQqJoKo9Izm+8D6FpGFXhW+Z8m00XZip+rVHS/ZWTLiI5LKoQ== MIME-Version: 1.0 X-Received: by 10.36.46.74 with SMTP id i71mr5617931ita.91.1465576319547; Fri, 10 Jun 2016 09:31:59 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 09:31:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jun 2016 09:31:59 -0700 Message-ID: Subject: Re: Hop-by-hop options in 2460bis From: Tom Herbert To: Erik Kline Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:32:02 -0000 On Fri, Jun 10, 2016 at 9:23 AM, Erik Kline wrote: > I agree with your concern, but I'm skeptical that "ignore" will be a > practical option, since everybody loves to get their hands on port > numbers--even if only for incrementing logging counters. "ignore" in the sense that a node does not have to process the options within the header. A node can alway skip over an EH to parse the next header as long as it can identify the EH. Tom From nobody Fri Jun 10 10:23:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6165212D77B for ; Fri, 10 Jun 2016 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 6sRYcCmcsMnr for ; Fri, 10 Jun 2016 10:23:08 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D25112D663 for <6man@ietf.org>; Fri, 10 Jun 2016 10:23:08 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2016 17:23:07 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4F8CC9CC4E; Fri, 10 Jun 2016 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=WYUZ73ho+m5/Qw0o2eDStmOfFHs=; b= M07Sjx+MH7jZJHkf4PkoZpIRlfwxfl7UPsyxSCAyRFoPH/ytIHyUNWA0A39S/C0O +8VszoANHv/su2ZZPzsChDUOxcfihAA2LbGZryt+zL4rzGnf2tF6fufXd8XS6B6V wCTo0ld8RI7DdK8b2dmWcuvEa4eNqkU6gHmWQew/qCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=TO11bxwcdAPiuNJn2gEYonmOu+ EDNufrgzRa38FnMyyLaHlLy2nptXupQi7hhzn/FPTrdMo3MSZsMypFaQ2L/e25+2 wCdENwkjileE8C/NcvXTZ60g8/gwM9+f39+g7tWVYJQtcKFpDpMbXmsykFbPQPgm p3FZocFDmrPTJBlbA= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 0C3849CC51; Fri, 10 Jun 2016 10:23:06 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AA8231C0BB43; Fri, 10 Jun 2016 19:22:59 +0200 (CEST) Subject: Re: Hop-by-hop options in 2460bis Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F7A9A9C7-A3B6-4A82-A28E-779CF517D2AB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Fri, 10 Jun 2016 19:22:56 +0200 Message-Id: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> References: To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 17:23:10 -0000 --Apple-Mail=_F7A9A9C7-A3B6-4A82-A28E-779CF517D2AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, Did you see the text I suggested here: https://mailarchive.ietf.org/arch/msg/ipv6/dNtdwOgvvVL6Hz1uOykNKYOhEeU [...] I agree, that a clarification of what the "may process" means. Ron = proposed the following text on a different thread: When an implementation skips over an HBH Options header, it continues = to process the packet, as if the HBH Options header had not been present in the header chain. [...] > Also, I think there is also a potential ambiguity is this text: >=20 > "The Option Type identifiers are internally encoded such that their > highest-order two bits specify the action that must be taken if the > processing IPv6 node does not recognize the Option Type:" >=20 > Since intermediate nodes can process HBH options are they expected to > take this actions? I think the answer should be no, it seems like only > the receiver should be allowed to drop packets with unknown options. > Note that if intermediate nodes are allowed to ignore the HBH option > this might be in conflict with the rules about handling unrecognized > options-- all options in that case are implicitly skipped. with the changes proposed in the other thread we may get around that. 2460 has the following text: The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: the "must -> should -> may process" change, we're relaxing which nodes = need to process the option. only the nodes processing the option needs to consider the high order = bits. cheers, Ole --Apple-Mail=_F7A9A9C7-A3B6-4A82-A28E-779CF517D2AB 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 iQEcBAEBCgAGBQJXWvdzAAoJED4aXnjSQuKW85gH/3bgDv85eZXsiP6KSjL4pI3Y GP/vslVdWLHBZ5x4I3IJf5wfknN2NZzwSiGAdvw43JosQdCGkMtJEtcvpAwm/+2g +tB/zi9JCA4CJ4OG6v5osC/qMWm/gCzjhjA5Jd+hU5S0e2gIQcbKWPqSBiXBlYUT 91FUSiM08WKMhMyZa6BTxbvwp6rBNjDVl9eZpqVYRiUR/nrwToLCiYY1nGvcyYg4 2AkTYxzqFNdru8FVE46nG94U6pkktYImD8PhriTg09oRd71VVy4iOYBE46qzN2dt NoGIzhBlR5N/Z/L/uWkKbxqlPvoopIcNAheSZILkoQdEjZcoicLMjbta/uD2IV8= =UjJS -----END PGP SIGNATURE----- --Apple-Mail=_F7A9A9C7-A3B6-4A82-A28E-779CF517D2AB-- From nobody Fri Jun 10 10:47:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1753712D797 for ; Fri, 10 Jun 2016 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 jKcRtyLC8zyI for ; Fri, 10 Jun 2016 10:47:55 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C3D12D5AB for <6man@ietf.org>; Fri, 10 Jun 2016 10:47:55 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id o127so25807498iod.2 for <6man@ietf.org>; Fri, 10 Jun 2016 10:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ihchzIc5+vxN9LacThOCs1Igwh3vT6Z8MXzk7316lB4=; b=dzudBbUd+D5LI5VeGOKKqvIzkWJCWAxNZxmaoTy8zOXCMfINrahJgrYKqUp22o3fM7 t2VFMtdBu3HzE1HCK4KOSHDyk1pBZn03nHqV6p8Xiw6sUO0hjqyDKoanbPCILkiyUVer YlMGoQUz4ByEYEvHnEkTc3veZewz3Ifc2sT9a8PpMB8R1K/xBWrycNAOZweOkUyWVSnZ UG8aEvxIYVcCs4G2psANn40RmTpWH97xnVs1V7iSvV9S3zUpx5tuvJ7LeppAJ3EV1tmk zJGlM9U5Pcm4garARltLQghX/vaXiS5/T3ARIXy49krDYyg+d3s1QzGuDipFfrlwARae /iJw== 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:date :message-id:subject:from:to:cc; bh=ihchzIc5+vxN9LacThOCs1Igwh3vT6Z8MXzk7316lB4=; b=IONQmAJKvzWmD7c96UWcZvQyeEFzCuqSofTMKPwWQiTiIwaDo6JLg9NkqX/vVn8jvs sKQEAOIoWqw499Hwap0BEM36U536Fps005NH9RKFVbnCzoclvTVtv+yAkuKT6qR9VpcI Gj831Zr+TfgPwY6DD/Xz3mhJrwnOqey2vTp/hc32FXhSjAsQIei5if3aDCxvYj5NLcOK jehA8Ldk/8Lm8Rf3vWxWv7tKjHDBNI6EALK48PpY0ytLkG5dKMnbu6HlzaVb8fmj96jx N7BrJxYX2iHteGGVQWhjxvuFTZgD8GgzipotE+3GhqrfcoYeKbvby+ucGP10VvEgETR5 ZB/g== X-Gm-Message-State: ALyK8tJLAx2/my+TO0JyZ0o1MuOW7JVA2ZBue/bw09Vxvwj16IWNZ5CD6FKOKvNjZljf+0t4BOP6iiyNShV+3g== MIME-Version: 1.0 X-Received: by 10.107.162.131 with SMTP id l125mr5947510ioe.84.1465580874452; Fri, 10 Jun 2016 10:47:54 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 10:47:54 -0700 (PDT) In-Reply-To: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> Date: Fri, 10 Jun 2016 10:47:54 -0700 Message-ID: Subject: Re: Hop-by-hop options in 2460bis From: Tom Herbert To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 17:47:57 -0000 On Fri, Jun 10, 2016 at 10:22 AM, wrote: > Tom, > > Did you see the text I suggested here: > > https://mailarchive.ietf.org/arch/msg/ipv6/dNtdwOgvvVL6Hz1uOykNKYOhEeU > > [...] > > I agree, that a clarification of what the "may process" means. Ron proposed the following text on a different thread: > > When an implementation skips over an HBH Options header, it continues to process the packet, as if > the HBH Options header had not been present in the header chain. > Thanks for pointing that out. I think that's fine, but I would like to see some explicit requirement that nodes cannot drop packets just because HBH option or any other type of EH are present. If they are permitted to do that it undermines the whole facility and makes it unlikely we will ever deploy any EH in the Internet. > [...] > >> Also, I think there is also a potential ambiguity is this text: >> >> "The Option Type identifiers are internally encoded such that their >> highest-order two bits specify the action that must be taken if the >> processing IPv6 node does not recognize the Option Type:" >> >> Since intermediate nodes can process HBH options are they expected to >> take this actions? I think the answer should be no, it seems like only >> the receiver should be allowed to drop packets with unknown options. >> Note that if intermediate nodes are allowed to ignore the HBH option >> this might be in conflict with the rules about handling unrecognized >> options-- all options in that case are implicitly skipped. > > with the changes proposed in the other thread we may get around that. > 2460 has the following text: > > The Option Type identifiers are internally encoded such that their > highest-order two bits specify the action that must be taken if the > processing IPv6 node does not recognize the Option Type: > > the "must -> should -> may process" change, we're relaxing which nodes need to process the option. > only the nodes processing the option needs to consider the high order bits. > Allowing intermediate nodes to drop unrecognized options creates non-deterministic behavior. For example, if a flow is going through one path then all packets with HBH are delivered to the destination, but if routing changes and and some intermediate node starting dropping packets due to unrecognized EH then we lose connectivity for the flow. If we're lucky we might get an ICMP param problem, but if we don't we've lost the flow without endpoints having any idea why. This is why I think only receiver should drop for unrecognized options. Tom > cheers, > Ole From nobody Fri Jun 10 11:46:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A304812B047 for ; Fri, 10 Jun 2016 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Eue9koY4SlTY for ; Fri, 10 Jun 2016 11:46:30 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B91112D095 for <6man@ietf.org>; Fri, 10 Jun 2016 11:46:30 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2016 18:46:28 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 01BBD9CC7C; Fri, 10 Jun 2016 11:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=VWOWFh/gy080OQAa547GtokUwnY=; b= YTxWkbKaZdklaG3KfUbHQsFz+OLJDewB3Ff3E2/mQdFiD3IzyYOxagZlRvGPVsHe C8SJcifgQNmIVHodLzHtm4CUWefVQy5tCJxh8j6iAD27nfMUkp3p2aTlBnOSllml 6/nmTguSfHZ5N6VITwjZKbcQ/R2FSIW9PPlQauUWo2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=nDVUTEEBtSFZLrY0Ot+VaNGJA0 xiylr57seTIIQRZ/LH6KBXA5EWjVXX5AH+vW4aGfdrNtC1XaG14QGWkuol0B5hey 1qSpGepyVu8PZtoB5nZwGu5fgv48fvT+ukLJAleD12ZZxZOo5eilqmSUDFWuybcZ nNorvnd+kbUQnshxk= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 816409CC51; Fri, 10 Jun 2016 11:46:27 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5998F1C0F88A; Fri, 10 Jun 2016 20:46:25 +0200 (CEST) Subject: Re: Hop-by-hop options in 2460bis Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_60763072-7494-4B90-9E62-63535B9DBC2E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Fri, 10 Jun 2016 20:46:22 +0200 Message-Id: <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:46:31 -0000 --Apple-Mail=_60763072-7494-4B90-9E62-63535B9DBC2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, >> I agree, that a clarification of what the "may process" means. Ron = proposed the following text on a different thread: >>=20 >> When an implementation skips over an HBH Options header, it = continues to process the packet, as if >> the HBH Options header had not been present in the header chain. >>=20 > Thanks for pointing that out. I think that's fine, but I would like to > see some explicit requirement that nodes cannot drop packets just > because HBH option or any other type of EH are present. If they are > permitted to do that it undermines the whole facility and makes it > unlikely we will ever deploy any EH in the Internet. NEW: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by nodes along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While RFC2460 required that all nodes must process the Hop-by- Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. Nodes that do not process or examine the Hop-by-Hop Options header = must ignore it, and it must be passed on unchanged if forwarded. [...] >> the "must -> should -> may process" change, we're relaxing which = nodes need to process the option. >> only the nodes processing the option needs to consider the high order = bits. >>=20 > Allowing intermediate nodes to drop unrecognized options creates > non-deterministic behavior. For example, if a flow is going through > one path then all packets with HBH are delivered to the destination, > but if routing changes and and some intermediate node starting > dropping packets due to unrecognized EH then we lose connectivity for > the flow. If we're lucky we might get an ICMP param problem, but if we > don't we've lost the flow without endpoints having any idea why. This > is why I think only receiver should drop for unrecognized options. Yes, I accept that argument. Mandatory options (those with any of the = two high order bits set) are mandatory for a reason. Take the jumbo or = the RPL option, you cannot expect that those can be forwarded through a = network unless every node along the path supports the option. I would = argue that trying to send a mandatory option over a network which isn't = configured to handle it is a configuration error. The packet would = likely be dropped regardless of processing of the high order bits. In = practice that means that it is highly unlikely that mandatory options = will be supported in the Internet. Which is why I think that we do not have to change the specification for = the high order bits. Best regards, Ole --Apple-Mail=_60763072-7494-4B90-9E62-63535B9DBC2E 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 iQEcBAEBCgAGBQJXWwsBAAoJED4aXnjSQuKWb9cH/2qBEj44ch0/3CIae7uLtArK MQNeazRwzRXOe8/4h2lVwqBHGCQxYHAk0nfIVWiCynMYKc9HPKvEvnhZ59MpaGBz L+0kD6qWG/ACUiRyzuzueAyOJHjP9koaWu7LXmH79CZKt0EykFO96r+Y039AvhaX DEfCTklP2pqTOwmfuj+JkmUxPfGnkyce48FHCDZCiuCIYtTgfsqoCCuskm7LomwL RQxlurwdKkTRGx5+fx/d6blPGFMAM/KOt/tJbTkiTCY1l5ZPZFDipJEo6dLIcKhm seCbcziiw1cM/hJXMtgrmhe25BDSSJr/oFOs8lKQlSJqMO3aIvjfJ7rFq9JhKYk= =NoLS -----END PGP SIGNATURE----- --Apple-Mail=_60763072-7494-4B90-9E62-63535B9DBC2E-- From nobody Fri Jun 10 11:47:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DCF12D5F7 for ; Fri, 10 Jun 2016 11:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 hU5iat0lhMP2 for ; Fri, 10 Jun 2016 11:47:29 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6017412D52D for ; Fri, 10 Jun 2016 11:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1465584449; x=2329498049; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0/iRjvsneG9bSqb/I2UDkjtt6n/4ZIf7ymC6t+j/Quk=; b=m85fRH946i2F1xQlC4Gqa7d5Ejl5hcLw/SNXCimgjgwsRiGEJ3gcNCL34fj+1xp+ rmGClEjMQ0xjsnivDMhNuzvzwf1MOpbn2H28YCTINjultQ7O7CtwQJFNLk/cozv5 L+HwDu247P9GuDHFV52pqEcYSa+1nEbZRa9Q6EJHDtaQbAO97Ur1JtaMePvEQA7R AR3SSePX+gZASagwzm08zD3WRMG9A7grGcLcwrCMU0lE8Paq7dsUznU23KVfV5LP YIvygEroglYi4ygi3SLLGGSHkvjvXXqbsy6KniRh5hQVVp0o1D2C6xaDNTtT2Ms8 nE0cKHh+BHkvrSYWHEEF3Q==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id EF.DE.03030.14B0B575; Fri, 10 Jun 2016 11:47:29 -0700 (PDT) X-AuditID: 11973e13-f798e6d000000bd6-e1-575b0b41dde7 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 13.DF.07991.14B0B575; Fri, 10 Jun 2016 11:47:29 -0700 (PDT) Received: from [17.153.43.100] (unknown [17.153.43.100]) by koseret.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0O8K00135K74EG30@koseret.apple.com> for ipv6@ietf.org; Fri, 10 Jun 2016 11:47:28 -0700 (PDT) Sender: dschinazi@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ULA-C [was: Testing ULAness] From: David Schinazi In-reply-to: Date: Fri, 10 Jun 2016 11:47:30 -0700 Content-transfer-encoding: quoted-printable Message-id: <02C78F40-F8B5-4163-8DA6-17E031413A8A@apple.com> References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYruvIHR1ucO0Rj8XLs++ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcW5WA3PBXtmKez+vsTYwPhfvYuTgkBAwkZi9I6mLkRPIFJO4 cG89G4gtJLCXUWLH7CKIuInEvzvzmCDi/UwSU1+VdTFyQdgT/ncygySEBaQlui7cZQWZySyg LjFlSi5ImFdAT2Ly0QY2iBJNiSlXz7GAlLAJaEkcWGMEEuYUMJa4fPc6WAmLgKrE7MXnGUFs ZgFtiSfvLrBCjLGReNK3hQli7Xt2ift/zoHdIyIgKLH9wQ8WiDtlJZ6cXMQCUiQhMINN4tiB LcwTGIVnIZw0C8lJs5DsWMDIvIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKICn2wnvYDy9yuoQ owAHoxIPb8SuyHAh1sSy4srcQ4zSHCxK4rz7r0eFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBMnbu3cm78+p9ME1Vu9aXLfFD8oHJG9puJ/Y4969c/O/r7RPGkDK7uiI9icy/fDV+mpmex k4mvxyUpVFk6z2mheU9IYdy6yPLNiQc/rt/QbblZNvriE363Wte6vI/lWZfWN1ferzznP3WV l9VFu3dSRgWf9d5un3TR+s3Bla1f+J1evT36rlJHiaU4I9FQi7moOBEAPRNoV0ECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUiON1OXdeROzrc4NQUDouXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49ysBuaCvbIV935eY21gfC7excjJISFgIvHvzjwmCFtM4sK9 9WwgtpBAP5PE1FdlXYxcEPaE/53MIAlhAWmJrgt3WbsYOTiYBdQlpkzJBQnzCuhJTD7awAZR oikx5eo5FpASNgEtiQNrjEDCnALGEpfvXgcrYRFQlZi9+DwjiM0soC3x5N0FVogxNhJP+rYw Qax9zy5x/885sNtEBAQltj/4wQJxp6zEk5OLWCYwCsxCuGIWkitmIRm7gJF5FaNAUWpOYqWJ XmJBQU6qXnJ+7iZGUNA1FIbvYPy3zOoQowAHoxIPb8SuyHAh1sSy4srcQ4wSHMxKIryTOaLD hXhTEiurUovy44tKc1KLDzEmAz0wkVlKNDkfGBF5JfGGJiYGJsbGZsbG5ibmpAkrifNeegW0 VSA9sSQ1OzW1ILUIZgsTB6dUA6PCdkO3u9FC0zZEB34TXv/68fNpDIGKsqvccvfvbK56y7E8 TE3beJn709cJd1hmV237XHnv966CIxPdGqSnHrfZt92Hf/aDWt7APTPVHHu+rT3S9Je1kl1V 8dLlvZ6eat66My5I/D+hsENLwmDFjrzvG9jyfjOKJX58sanDMerjnPbLrvsmF0crsRRnJBpq MRcVJwIAEKbwln4CAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:47:31 -0000 I don't know about all the hosts out there, but I know a great many = devices that implement a lot of the techniques discussed above. When an address fails to connect, they fall through the entire list that = DNS returned in quick succession. This is done independently of address family and ensures that the = eyeball quickly ends up with a functional connection. All happy eyeballs recommends is that you may want to try the first = address from the second address family sooner than after all of the = addresses from the first address family. If there are different types of addresses (say an ULA and a global = address), RFC 6724 source address selection makes sure to use the = correct source. There's no need to try to connect from every single source address to = every destination, simply the best source for each destination. (If the source is multi homed with different global prefixes you may = want to try both of these but that's not very widespread at this time) Regarding MPTCP, all you need is to treat it like regular happy eyeballs = TCP at setup time and send multiple SYNs until one connects and then = start opening subflows. Host downtimes and routing blackholes are as much a fact of life as = packet loss, sure the network will operate with N-1 failures but it will = operate. If the operator returns multiple addresses in DNS, they probably want = eyeballs to use them, not take one and start crying if it doesn't work. And yes all of this involves complexity but as long as you keep all of = it hidden behind a connect-by-name API, it just works=E2=84=A2. David > On Jun 10, 2016, at 04:58, Philip Homburg = wrote: >=20 > In your letter dated Thu, 9 Jun 2016 09:04:08 +0200 you wrote: >>> As an industry, I think we need a better engineering answer than = "try=20 >> every possible combination all the time", because trying all=20 >> combinations all the time is expensive in terms of CPU time, radio=20 >> usage, and battery life. >>>=20 >>> HE was a hack to aid in IPv6 deployment. It's time to retire it. >>=20 >> I disagree. >> I a host should optimally try all combinations, monitor them, = failover=20 >> between them, load-share across them... >> it can obviously be smart about it, and probabilistically prefer some=20= >> SA/DA pairs over others at connection time. >>=20 >> I've not seen any other credible alternative to deal with host based=20= >> multi-homing. >> even if you were only connected via a single interface to a = multi-prefix=20 >> network, the network has very limited knowledge about the path=20 >> performance to the destination. >=20 > I can see two problems with happy eyeballs: > 1) Only connection setup gets tested. If that connection has bad = performance > there is no fallback > 2) There is no happy eyeballs protocol. It is just a vague description = of a > technique.=20 >=20 > For the first problem, MPTCP would be more suitable than happy = eyeballs. >=20 > For the second problem, I think there should be a clear base line that > can just be implemented. Not an endless variety of possibilities, but > something that is expected to work well in many cases and does not > overload the network. >=20 > Of course implementation can go beyond that. But without something = that is > simple to convert into code, it may take forever for embedded devices, = etc. > to do something sensible in this area. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 10 13:18:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53312D1E6 for ; Fri, 10 Jun 2016 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8dD5a2OB-Rcn for ; Fri, 10 Jun 2016 13:18:11 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA3012D59F for ; Fri, 10 Jun 2016 13:18:11 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id y124so26373333pfy.0 for ; Fri, 10 Jun 2016 13:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=91mQtGlPvXCCA+FcZjAgPBINv7lULMPCNQv/Tkt+r+A=; b=vt5/cJCoq5cBJuLY2xkWAMnExKK9ZxavGjnjgwKzebNhgVTgyJivCvKadWtkZKEElw yij5Yf/7sPbXeYCbESO+OvNRmfPJ/WPgqeR0hJENLLKneI+5+3xDIFxkFbqxCNdZf8J0 1g8IDNj14+RMjIX5heI9kQMvmAm61I0h8QDp1otzf2NHxWfLseD2dMR3Rf8VL1QthF5q Bk/rSEdDEF0+SEUWtxTSiGlayr9RPeQbYPkY1jyLHuvuMEpjDlKfM0xPK0cEP4lTGMp1 3V3ZYGYe6urD6EXkT0FABguP3WA2gxWIasMXrhRI1OjXAxrvQDNdyQgATWyvWPFn3gFT RQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=91mQtGlPvXCCA+FcZjAgPBINv7lULMPCNQv/Tkt+r+A=; b=iJtZPaFcxTMvyod2ObyRO6m+s4DcLqZz20wwC5wiLM5R7CBCeaACBDPflleMOiihJr /DXWv1mKDakUcrShEVAZGi1la5uSiLYY87SMfDEPGDn06ahKhDVQSKpDBY+8CcALIUBX l2sU7lJeOnNGzn8LlJUNckNIRsbpcP3GpR5KghWx6k/xU5foEqOeilnCJfDNQa4gvNRS MYXUKTLY4wL1ecn+rZHi07jWLWSF899R62XcGUwO8Xc5V2Ya1KEjCcvRL76gRJQU+QDk xA97d5z6rHRnGB48hC/p7sHt/xRa+y6D3dYaBj48jpBv5gpWIvnN9KKt4mMS2kmDBFJo 33fQ== X-Gm-Message-State: ALyK8tIEk4qmecpagvmcnw9lCZqYR6c3Pgt3DoZo08SKtuD++FTYLGKvA0iMvJQGCBIFVg== X-Received: by 10.98.13.154 with SMTP id 26mr3918730pfn.35.1465589890545; Fri, 10 Jun 2016 13:18:10 -0700 (PDT) Received: from [192.168.178.22] ([118.148.77.94]) by smtp.gmail.com with ESMTPSA id o22sm13906757pfa.15.2016.06.10.13.18.08 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 13:18:09 -0700 (PDT) Subject: Re: Happiness [was ULA-C [was: Testing ULAness]] To: ipv6@ietf.org References: <22582.1465221680@obiwan.sandelman.ca> <26441.1465315449@obiwan.sandelman.ca> <20160609004253.0583E4B07903@rock.dv.isc.org> <20160609055921.7C4D04B09FBE@rock.dv.isc.org> <6b103628-8403-6444-5791-c8c280b17129@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <938ef660-cc49-7edc-4995-3b140003c411@gmail.com> Date: Sat, 11 Jun 2016 08:18:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:18:14 -0000 On 10/06/2016 21:54, Bajpai, Vaibhav wrote: > All, >=20 > I think the thread was initially talking about happy eyeballs (HE), but= the > recent replies have digressed it into hurricane electric (HE). >=20 > Let=E2=80=99s please expand acronyms when using them. That's why I changed the subject to 'happiness' but apparently that wasn'= t enough of a clue that I thought we were taking about happy eyeballs. But either HE would have fixed my problem the other day ;-) Brian >=20 > Thanks! >=20 > Best, Vaibhav >=20 >=20 >> On 10 Jun 2016, at 15:16, Alexandre Petrescu wrote: >> >> Le 10/06/2016 =C3=A0 01:03, Brian E Carpenter a =C3=A9crit : >>> On 09/06/2016 17:59, Mark Andrews wrote: >>>> >>>> In message >>>> = >>>> >>>> >> , Lorenzo Colitti writes: >>>>> On Thu, Jun 9, 2016 at 9:42 AM, Mark Andrews >>>>> wrote: >>>>> >>>>>> And before you complain about "it takes a lot of time" there >>>>>> is absolutely nothing stopping A from attempting to contact B >>>>>> over the second address rapidly like one does with HE for IPv6 >>>>>> vs IPv4. >>>>>> >>>>> >>>>> Nothing stops an implementation from doing that, but no >>>>> implementations do that. >>>> >>>> And they don't do it because the primitive examples for how to >>>> contact multihomed servers don't show how to do that. It really is >>>> just a matter of education and spending a small amount of time >>>> going back at retrofiting smart multihome server connection >>>> semantics. >>>> >>>>> As an industry, I think we need a better engineering answer than >>>>> "try every possible combination all the time", because trying all >>>>> combinations all the time is expensive in terms of CPU time, >>>>> radio usage, and battery life. >>>>> >>>>> HE was a hack to aid in IPv6 deployment. It's time to retire it. >>>> >>>> When you can create a network without black holes then it is time >>>> to retire it. To date I've yet to see anyone do that. >>> >>> +1. HE saved my sanity two days ago, for example, when my ISP chose >>> to give me an IPv6 prefix but to black hole all IPv6 packets for a >>> while. When that becomes physically impossible, we can retire HE. >> >> A colleague plans to use Hurricane Electric tunnelling (HE) soon to ma= ke >> measurements of IPv6 energy consumption on a smartphone; HE because in= >> that part of the world there is too little chance to get a native IPv6= >> connection at this time. It's a topic that makes laugh when mentioned= =2E >> >> There are many other parts of the world where native IPv6 is not for >> soon. In April I discussed with an Argentinian network responsible an= d >> was told that the IPv6 arrival in the Malvine islands is something nev= er >> heard of. And there there was that same smile on her face as when I a= sk >> IPv6 in other regions. And my experience teaches me there is usually = a >> certain lapse of time between never hearing of IPv6 and deployment. >> >> Alex >> >>> >>> Brian >>> >>>> >>>> Additionally local ULAs, GUA, other ULAs is the best default sort >>>> order and generally results in a single connection attempt unless >>>> there is a broken link. Where you use matching ULA, GUA and GUA as >>>> the source address unless it is explicity overridden. >>>> >>>> Mark >>>> >>> >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Vaibhav Bajpai > www.vaibhavbajpai.com >=20 > Room 91, Research I > School of Engineering and Sciences > Jacobs University Bremen, Germany > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Fri Jun 10 13:21:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0FD12D694 for ; Fri, 10 Jun 2016 13:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ModmK7ZnA5wT for ; Fri, 10 Jun 2016 13:21:04 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C08112D741 for ; Fri, 10 Jun 2016 13:21:03 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 62so26330224pfd.1 for ; Fri, 10 Jun 2016 13:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PnXnZhmeb+so9iQShPTwji7xQhW24VzoOjGwmyU3Jzo=; b=Z2xylA/CGT5912riqh++LDAX2ZZmXsNBbk1SkrbSvWtInTJjwO3AVOxFTtev6rqRle Jp9hW3O6pCmjXkOvmlqel0qufV0qsGcDL9pFazivRyxIEFeKdMK+YzqdmWUPR00q2SRa psGS3LvNEtl8uXAaZEBdWY7VR1T0h/XwXsgw/GqiisoiSTx0Yl12waBGxB3DQz6jT5T/ esFqXD49Qgcq/QDey1RokF5uL9nm9ht9sS4drskrFxkXJO7TjRrs1Kpn4HxwBN6B/fBj H0r200XM95tbVuJLEBuZBqvFmnyQo+L30YDDN38e1rAoJNC618RAlwFxjIzQyC4LNSkk iB2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PnXnZhmeb+so9iQShPTwji7xQhW24VzoOjGwmyU3Jzo=; b=H15MY0Y5ruRxdFBXKKGJnKCarRy6vFJ7mlHQv3+hnF/9cJciFCX3/KQ3kf1FtLoBgG l9P1M5YrrHoEvayIdjZRbMDM+1/gF6yv5ASNeRQfD1uUVVNAGzap3wwi0ZWWBdsJKUv2 oDpbH96/6jM40sbCryxIc0zZ7UFfzdR7KuhMxt6ee7V1TFON++bygbDrhF6NkJTj3OgY 44bJlpR/Q4YIV2q3G6S3/TZgX4UZB/1xRVK7iOeh8V6bz3dEiah1nrIyJI2zFCt8NHUp CZ58DF9nuaVbiipQFZjgQ4DF4DnRmJASEc63h459JUaVzhJqleW3vJix2DnF2ZMp8oSP KDHw== X-Gm-Message-State: ALyK8tLSME3Ng6SwfxkpoCb8Y0eEsbCfkKSgoeHBVcjxiJPmsKUD7hJXTCu0EFZ0jIwoyw== X-Received: by 10.98.86.151 with SMTP id h23mr3948974pfj.137.1465590062811; Fri, 10 Jun 2016 13:21:02 -0700 (PDT) Received: from [192.168.178.22] ([118.148.77.94]) by smtp.gmail.com with ESMTPSA id m81sm19648333pfi.51.2016.06.10.13.21.00 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 13:21:02 -0700 (PDT) Subject: Re: Testing ULAness To: ipv6@ietf.org References: <20160610112331.5714F328081A@clairseach.fuaim.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 11 Jun 2016 08:21:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:21:06 -0000 On 11/06/2016 03:37, Bob Hinden wrote: > Brian, >=20 >> On Jun 10, 2016, at 4:23 AM, Brian Haberman = wrote: >> >> Bob, >> The key part of that definition is the last part about "beyond an = administrative boundary", which is where the aspects of 4193 come in. >=20 > I get that, but that can be achieved by two ASs sharing a route for a s= pecific ULA prefix. If the intent is that global means "global routable=E2= =80=9D then the RFC should say so in a clear manner. For example, someth= ing like: >=20 > o Global - A boolean value indicating whether an IP datagram whose > destination address is drawn from the allocated special-purpose > address block is routed globally. That's insufficient, because it still leaves the word 'global' on its own having different meanings in different RFCs. That's why I wrote my quick draft. Brian >=20 > I could file an errata. >=20 > Bob >=20 >> >> Brian On Jun 9, 2016 7:32 PM, Bob Hinden wrote:= >>> >>> Brian, >>> >>>> On Jun 9, 2016, at 7:56 AM, Brian Haberman wrote: >>>> >>>> Sorry for the delay in responding, but I have been traveling... >>>> >>>> On 6/5/16 12:37 AM, Brian E Carpenter wrote: >>>>> Hi, >>>>> >>>>> The IANA IPv6 Special-Purpose Address Registry* has a column marked= "Global". >>>>> For fc00::/7 (ULA) this is set to "False". >>>>> >>>>> That is surely wrong. ULAs are explicitly defined as having global = scope. >>>>> >>>>> This has consequences. For example, in the Python ipaddress module,= >>>>> the property .is_global returns False on a ULA. The test for ULAnes= s >>>>> turns out to be (x.is_private and not x.is_link_local). >>>>> >>>>> *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ip= v6-special-registry.xhtml >>>>> >>>> >>>> I have not been able to work through this entire thread as of yet, b= ut I >>>> wanted to respond to point above as one of the authors of the RFC th= at >>>> created the registry. >>>> >>>> Global is False given that, while probably unique, these addresses a= re >>>> not guaranteed globally routable. 4193 says: >>>> >>>> Their limitation is in the routability of the prefixes, which is >>>> limited to a site and any explicit routing agreements with other >>>> sites to propagate them... >>>> >>>> The authors of 6890 discussed this at length both amongst ourselves = and >>>> with the larger community. The consensus was that ULAs are not >>>> guaranteed globally routable. >>> >>> You are correct about RFC4193, but the confusion is that the text in = RFC6890 that defines Global doesn=E2=80=99t mention globally routable. I= t says something much more limited: >>> >>> o Global - A boolean value indicating whether an IP datagram whose= >>> destination address is drawn from the allocated special-purpose >>> address block is forwardable beyond a specified administrative >>> domain. >>> >>> I read that as covered by "any explicit routing agreements with other= sites to propagate=E2=80=9D, not globally routable. Some sort of clarif= ication or errata for this RFC and IANA registry is needed. >>> >>> Bob >>> >>> >>> >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Fri Jun 10 13:25:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C7612D921 for ; Fri, 10 Jun 2016 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 obwUnrPin64h for ; Fri, 10 Jun 2016 13:25:32 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E9412D904 for ; Fri, 10 Jun 2016 13:25:32 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g20so76821354ywb.0 for ; Fri, 10 Jun 2016 13:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=iDnXfiHVsuGG1+vKtz2eck4JL3RqfMOhI6/NRLwe1v8=; b=Jws9bfYlWFOxxP7Klw3L8tGBGUd5U7rrsoW/jVXevijerMg6Wf/N6pgiG6uAGNmERk lkfDwOfhB2zqQrGW2z+3ATuYFTgfPDqZO69Vp7yzfDbJTam2LoBOzcrSqe5zwtwj85tt czeZjHLTTsmQJRx5rMws9jo9f6W+cGxRtnZLNdy1gq+qy/unA9EDpf4QrNQfLSnviDP6 wnXYjXyQRUhD8DtkgrEDg9puWjluPB9typ82LcFEpAI/Ac+bCWGEjNU3nu5lwD5I7lq8 38ZCvA7Ep15DMI8+mB6OTIYPCgUEbXy1t10kq9Ixw9Gfi4QhIC3HNRqA4PUTvKUlGKNf N/EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=iDnXfiHVsuGG1+vKtz2eck4JL3RqfMOhI6/NRLwe1v8=; b=RZZ9VYqWzxvG0kKix+sYQVvhI7U58SjcnyAYthW0GSYIZsevT3sUrGZoH+RLFieNuK Aws8/cX65QtiZ7m/5BDALTz2IvUt6Xa3Fel1Mzuzqa7tAlUVLR5v3J85i+IBThBsAFUu zagSdRMc/BzCP1Lp7/rUUbrEE646jasIhSeIqTV/Ljfhah2FU3KKXX7Bpil6xuE8jtCS C4kBd0NPMIfnbRDkeFIEAyYiD4zNb1rzJ5H5RhTJ8cEi1aqM4n6OuR2nUuL9d2Wj5D3x oosjmqsQnJJy3fTYYpZTVESbyFqm7VrSMNuH/Own9K//jazzwTD+1QhyHKeqw+ykzzzW YoLA== X-Gm-Message-State: ALyK8tI9oRlKK7UmXxh45sOPG6UovNBY1g3AgqVcjpMZL4sl66pjZJgNtHNu5CQvLi2wCQ== X-Received: by 10.129.84.136 with SMTP id i130mr2053710ywb.135.1465590331355; Fri, 10 Jun 2016 13:25:31 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r8sm6894193ywb.20.2016.06.10.13.25.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 13:25:30 -0700 (PDT) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5DF3A0A2-765C-406F-87DE-BEF0DEAD30F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Fri, 10 Jun 2016 13:25:28 -0700 Message-Id: <1B2063A6-B8DC-46E0-B50A-39CD95A6FEB9@gmail.com> References: <20160610112331.5714F328081A@clairseach.fuaim.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:25:34 -0000 --Apple-Mail=_5DF3A0A2-765C-406F-87DE-BEF0DEAD30F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Jun 10, 2016, at 1:21 PM, Brian E Carpenter = wrote: >=20 > On 11/06/2016 03:37, Bob Hinden wrote: >> Brian, >>=20 >>> On Jun 10, 2016, at 4:23 AM, Brian Haberman = wrote: >>>=20 >>> Bob, >>> The key part of that definition is the last part about "beyond an = administrative boundary", which is where the aspects of 4193 come in. >>=20 >> I get that, but that can be achieved by two ASs sharing a route for a = specific ULA prefix. If the intent is that global means "global = routable=E2=80=9D then the RFC should say so in a clear manner. For = example, something like: >>=20 >> o Global - A boolean value indicating whether an IP datagram whose >> destination address is drawn from the allocated special-purpose >> address block is routed globally. >=20 > That's insufficient, because it still leaves the word 'global' on its > own having different meanings in different RFCs. That's why I wrote > my quick draft. Your draft could also update RFC6890 as well as the IANA registry. Bob >=20 > Brian >>=20 >> I could file an errata. >>=20 >> Bob >>=20 >>>=20 >>> Brian On Jun 9, 2016 7:32 PM, Bob Hinden = wrote: >>>>=20 >>>> Brian, >>>>=20 >>>>> On Jun 9, 2016, at 7:56 AM, Brian Haberman = wrote: >>>>>=20 >>>>> Sorry for the delay in responding, but I have been traveling... >>>>>=20 >>>>> On 6/5/16 12:37 AM, Brian E Carpenter wrote: >>>>>> Hi, >>>>>>=20 >>>>>> The IANA IPv6 Special-Purpose Address Registry* has a column = marked "Global". >>>>>> For fc00::/7 (ULA) this is set to "False". >>>>>>=20 >>>>>> That is surely wrong. ULAs are explicitly defined as having = global scope. >>>>>>=20 >>>>>> This has consequences. For example, in the Python ipaddress = module, >>>>>> the property .is_global returns False on a ULA. The test for = ULAness >>>>>> turns out to be (x.is_private and not x.is_link_local). >>>>>>=20 >>>>>> = *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-spec= ial-registry.xhtml >>>>>>=20 >>>>>=20 >>>>> I have not been able to work through this entire thread as of yet, = but I >>>>> wanted to respond to point above as one of the authors of the RFC = that >>>>> created the registry. >>>>>=20 >>>>> Global is False given that, while probably unique, these addresses = are >>>>> not guaranteed globally routable. 4193 says: >>>>>=20 >>>>> Their limitation is in the routability of the prefixes, which is >>>>> limited to a site and any explicit routing agreements with other >>>>> sites to propagate them... >>>>>=20 >>>>> The authors of 6890 discussed this at length both amongst = ourselves and >>>>> with the larger community. The consensus was that ULAs are not >>>>> guaranteed globally routable. >>>>=20 >>>> You are correct about RFC4193, but the confusion is that the text = in RFC6890 that defines Global doesn=E2=80=99t mention globally = routable. It says something much more limited: >>>>=20 >>>> o Global - A boolean value indicating whether an IP datagram = whose >>>> destination address is drawn from the allocated special-purpose >>>> address block is forwardable beyond a specified administrative >>>> domain. >>>>=20 >>>> I read that as covered by "any explicit routing agreements with = other sites to propagate=E2=80=9D, not globally routable. Some sort of = clarification or errata for this RFC and IANA registry is needed. >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_5DF3A0A2-765C-406F-87DE-BEF0DEAD30F2 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 iQEcBAEBCgAGBQJXWyI4AAoJEK7rdBF357uoihcH/j/PUPsdgf70KyDEb6xVVJt6 PIEVEgIZgicY1QDpSYvb4BRmovc43Bmubm+Maej3Tec/X0eCqdi+aDXFHUYSp7xu lyLYuB2q/I8/9G900a3WvKQ+tLYF0EfiYTfG2qm1CVM/JpGZoAyTWngoLT1jMOjj 5kAdysHzBfIW7vKBr8+UmE4YKbLO7hAlAqgh4J004wuzrifUYZtKleD+9NloRaZS VH3pDk4f7SAxwVgw+gWTKn032JJB0lR49/1KMNjBwl+Yg1rMz+akmFCPMi2ffoyE Jt9ITx5ieXGZuLeYJk6lMYB8pBhgcPC2spMX8+vjOgRNg3BhvDapn/Qc3nUakNA= =LOjn -----END PGP SIGNATURE----- --Apple-Mail=_5DF3A0A2-765C-406F-87DE-BEF0DEAD30F2-- From nobody Fri Jun 10 13:40:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468A112D948 for ; Fri, 10 Jun 2016 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WTfLdHnjpHPk for ; Fri, 10 Jun 2016 13:40:01 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8FA12D1E6 for ; Fri, 10 Jun 2016 13:40:01 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 62so26445344pfd.1 for ; Fri, 10 Jun 2016 13:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DKlj7ZCeYHg0Rbe0Zz4P0auo9YmUEe341Eg4gHddvJk=; b=ixHw0C9K/D2r4weqrcuVmIQvoLVM8k7BbBi7SkgnZlcgDe6pXL+MdvP5zbF48RNkD+ NhUOJLKDA9CJdnPpH8qlrjvhMW1APupiNF5cf4JjKstzsAaySH9BfBzJY0U6ecofprMK c0gsfYBkDaeI+ViKfGXjGzzPpIT6K+RA5VXAUE1ilISKNOBYeu7qCL2G3tim3Ldh6IMy OGumz8SIorEzSfgJGwCyRTYPUNSGLfDEhCFWK3+s/VHi6deQ7DmsFgzPmhzjrd/Xo4Wi e3TCiciUx553UhcKOfLJ7nI4/UX2pi3cqBUu/PRuPFJVQFhCrnlKCsRTnnKHx4AiP/DV Jsiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DKlj7ZCeYHg0Rbe0Zz4P0auo9YmUEe341Eg4gHddvJk=; b=RTiVjlMl0n76HffMGZhAlFywu62pz4qT/nDF8XbtSu+loBObi8kD2U4vLCCMGy+Mpv XOt9XbSEILum6YnwGlGKNPsE+XFdeWAPaBKEZ47OcHgaU2xgopS2ValXFElU+D3eK3kw VMUlEJ8YJP6S4kWti+3tFdbnGff8Ot1+13mBng+k4MneIS8qU46l7ysLwtn36XrkqAIw j5z7vOtzPD8My2t6r4GZgBDTHHyu/YLqEcm758P/sdFkEKPmZTarfDqiN9IkXVHynv05 rHUreBar5nlakupOtm1Kl0k8apsNqhu2HVNaRKRAq9NVqhmK4ef3Ha/GtAZo94665paD HntA== X-Gm-Message-State: ALyK8tJJfciKGFSTcE4onMY0LLqkMV8JWfy4C0dXvyD6N9jjfYOPwKVHkdZZQ6iuHzqY/w== X-Received: by 10.98.7.154 with SMTP id 26mr4046787pfh.2.1465591200731; Fri, 10 Jun 2016 13:40:00 -0700 (PDT) Received: from [192.168.178.22] ([118.148.77.94]) by smtp.gmail.com with ESMTPSA id 6sm19775085pfv.26.2016.06.10.13.39.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 13:40:00 -0700 (PDT) Subject: Re: Testing ULAness To: Bob Hinden References: <20160610112331.5714F328081A@clairseach.fuaim.com> <1B2063A6-B8DC-46E0-B50A-39CD95A6FEB9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <96e2b020-352b-eeb1-5673-5d167c35bed5@gmail.com> Date: Sat, 11 Jun 2016 08:40:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1B2063A6-B8DC-46E0-B50A-39CD95A6FEB9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:40:03 -0000 On 11/06/2016 08:25, Bob Hinden wrote: > Brian, >=20 >> On Jun 10, 2016, at 1:21 PM, Brian E Carpenter wrote: >> >> On 11/06/2016 03:37, Bob Hinden wrote: >>> Brian, >>> >>>> On Jun 10, 2016, at 4:23 AM, Brian Haberman wrote: >>>> >>>> Bob, >>>> The key part of that definition is the last part about "beyond an= administrative boundary", which is where the aspects of 4193 come in. >>> >>> I get that, but that can be achieved by two ASs sharing a route for a= specific ULA prefix. If the intent is that global means "global routabl= e=E2=80=9D then the RFC should say so in a clear manner. For example, so= mething like: >>> >>> o Global - A boolean value indicating whether an IP datagram whose= >>> destination address is drawn from the allocated special-purpose >>> address block is routed globally. >> >> That's insufficient, because it still leaves the word 'global' on its >> own having different meanings in different RFCs. That's why I wrote >> my quick draft. >=20 > Your draft could also update RFC6890 as well as the IANA registry. Yes indeed. I will spin the draft nearer the deadline, if anything like a consensus view has appeared. (We might indeed be able to handle the whole thing by errata, but it seems useful to have a draft to work from.)= Brian >=20 > Bob >=20 >> >> Brian >>> >>> I could file an errata. >>> >>> Bob >>> >>>> >>>> Brian On Jun 9, 2016 7:32 PM, Bob Hinden wrot= e: >>>>> >>>>> Brian, >>>>> >>>>>> On Jun 9, 2016, at 7:56 AM, Brian Haberman wrote: >>>>>> >>>>>> Sorry for the delay in responding, but I have been traveling... >>>>>> >>>>>> On 6/5/16 12:37 AM, Brian E Carpenter wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The IANA IPv6 Special-Purpose Address Registry* has a column mark= ed "Global". >>>>>>> For fc00::/7 (ULA) this is set to "False". >>>>>>> >>>>>>> That is surely wrong. ULAs are explicitly defined as having globa= l scope. >>>>>>> >>>>>>> This has consequences. For example, in the Python ipaddress modul= e, >>>>>>> the property .is_global returns False on a ULA. The test for ULAn= ess >>>>>>> turns out to be (x.is_private and not x.is_link_local). >>>>>>> >>>>>>> *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-= ipv6-special-registry.xhtml >>>>>>> >>>>>> >>>>>> I have not been able to work through this entire thread as of yet,= but I >>>>>> wanted to respond to point above as one of the authors of the RFC = that >>>>>> created the registry. >>>>>> >>>>>> Global is False given that, while probably unique, these addresses= are >>>>>> not guaranteed globally routable. 4193 says: >>>>>> >>>>>> Their limitation is in the routability of the prefixes, which is= >>>>>> limited to a site and any explicit routing agreements with other= >>>>>> sites to propagate them... >>>>>> >>>>>> The authors of 6890 discussed this at length both amongst ourselve= s and >>>>>> with the larger community. The consensus was that ULAs are not >>>>>> guaranteed globally routable. >>>>> >>>>> You are correct about RFC4193, but the confusion is that the text i= n RFC6890 that defines Global doesn=E2=80=99t mention globally routable. = It says something much more limited: >>>>> >>>>> o Global - A boolean value indicating whether an IP datagram who= se >>>>> destination address is drawn from the allocated special-purpose= >>>>> address block is forwardable beyond a specified administrative >>>>> domain. >>>>> >>>>> I read that as covered by "any explicit routing agreements with oth= er sites to propagate=E2=80=9D, not globally routable. Some sort of clar= ification or errata for this RFC and IANA registry is needed. >>>>> >>>>> Bob >>>>> >>>>> >>>>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- >=20 From nobody Fri Jun 10 13:42:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B512B05A for ; Fri, 10 Jun 2016 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vMIDppK7ANgP for ; Fri, 10 Jun 2016 13:42:20 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E2A12D943 for <6man@ietf.org>; Fri, 10 Jun 2016 13:36:56 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 62so26426220pfd.1 for <6man@ietf.org>; Fri, 10 Jun 2016 13:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+Y6jG/LWB93aMbs1EGBKFoMRe9QnbbWwS96fqNhnN2Y=; b=kHuemq2IUb40P+2VsQr4vreDxz+XV5LIkEdLofPJmdJIuUFzrcSK2gi/b6x8a0gttK IxnatfdTtPcJ0ivJU0MJ+SFqvZOTYR410CnAClIjGHWlgf4CrYchwBbCi/ph2tPbsFbO +dh9x+nKeQ2W8lUk7jduyNGuo2SlJevWrtj8o5lgeBbSJ8zO90EbWz94xfD0jyK0usbC xW2NwhxEVFXYTm+x4epXitiG5/Sgzo3n/ppvgZPwEPZi5b/bKiiGS1DNfUADPJVKc6g7 Gp/FkkR2QBNQE2cPj4R//HE2qnWORg5gvIVWNLac6bRBmcXFqHGuxw4P7Qh5keod42zS o2NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+Y6jG/LWB93aMbs1EGBKFoMRe9QnbbWwS96fqNhnN2Y=; b=XZzoWE90g65XGVEt33GaprsQPXmE8duAMmFCJb02v3doH+z/X0r9LQbG8HrKz7+91P hvdJt2V+v0N9S4RV2sp7CxqWTwR34acDGhXy1qVM/5lNVlAtjm0p8gxX9lYFdbI2Hfek gqcCCiJdl2TXNjl6jGso7aNbzhot5sO7edFEbNHM9nO6vfep+wKuqC0ih7GOIW4Jc+Fi 2ww0qF3BQGqu6zzufzeP8xEtpPnSo9gihUINyypz2DNGknnsoBTX27y+lYZMT7IZEgD+ T3bRe4TPrd8AqXp8lpw0ZrusS8br1PsUNdo1geVxmgUNFaeh+FRH525n8XIAHGmfkCVq 4j3Q== X-Gm-Message-State: ALyK8tIN+16Ti4pB1YcmmLtvpIBihxcmDVX9863k15Tz1DDjaLJenTMY9/9oHtmhRct4aA== X-Received: by 10.98.5.196 with SMTP id 187mr3999823pff.133.1465591015926; Fri, 10 Jun 2016 13:36:55 -0700 (PDT) Received: from [192.168.178.22] ([118.148.77.94]) by smtp.gmail.com with ESMTPSA id x187sm19653883pfx.87.2016.06.10.13.36.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 13:36:55 -0700 (PDT) Subject: Re: Hop-by-hop options in 2460bis To: otroan@employees.org, Tom Herbert References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <72afcfbd-95b7-cce3-0668-5bb48791127f@gmail.com> Date: Sat, 11 Jun 2016 08:36:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:42:24 -0000 On 11/06/2016 06:46, otroan@employees.org wrote: > Tom, > >>> I agree, that a clarification of what the "may process" means. Ron proposed the following text on a different thread: >>> >>> When an implementation skips over an HBH Options header, it continues to process the packet, as if >>> the HBH Options header had not been present in the header chain. >>> >> Thanks for pointing that out. I think that's fine, but I would like to >> see some explicit requirement that nodes cannot drop packets just >> because HBH option or any other type of EH are present. If they are >> permitted to do that it undermines the whole facility and makes it >> unlikely we will ever deploy any EH in the Internet. > > NEW: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by nodes along a packet's delivery path, including the > source and destination nodes. The Hop-by-Hop Options header, when > present, must immediately follow the IPv6 header. Its presence is > indicated by the value zero in the Next Header field of the IPv6 > header. > > NOTE: While RFC2460 required that all nodes must process the Hop-by- > Hop Options header, it is now expected that nodes only process the > Hop-by-Hop Options header if explicitly configured to do so. > Nodes that do not process or examine the Hop-by-Hop Options header must ignore it, > and it must be passed on unchanged if forwarded. I agree that this is a more realistic desired behaviour. The text in RFC7045 was an attempt to describe the real world. The fact is that processing HbH at line speed on a multi Gbit link isn't going to happen any time soon. Brian > [...] > >>> the "must -> should -> may process" change, we're relaxing which nodes need to process the option. >>> only the nodes processing the option needs to consider the high order bits. >>> >> Allowing intermediate nodes to drop unrecognized options creates >> non-deterministic behavior. For example, if a flow is going through >> one path then all packets with HBH are delivered to the destination, >> but if routing changes and and some intermediate node starting >> dropping packets due to unrecognized EH then we lose connectivity for >> the flow. If we're lucky we might get an ICMP param problem, but if we >> don't we've lost the flow without endpoints having any idea why. This >> is why I think only receiver should drop for unrecognized options. > > Yes, I accept that argument. Mandatory options (those with any of the two high order bits set) are mandatory for a reason. Take the jumbo or the RPL option, you cannot expect that those can be forwarded through a network unless every node along the path supports the option. I would argue that trying to send a mandatory option over a network which isn't configured to handle it is a configuration error. The packet would likely be dropped regardless of processing of the high order bits. In practice that means that it is highly unlikely that mandatory options will be supported in the Internet. > > Which is why I think that we do not have to change the specification for the high order bits. > > Best regards, > Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 10 13:49:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7312D7AC for ; Fri, 10 Jun 2016 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 96hm9zWxRMyq for ; Fri, 10 Jun 2016 13:49:43 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4C412D150 for <6man@ietf.org>; Fri, 10 Jun 2016 13:49:43 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x189so77294533ywe.3 for <6man@ietf.org>; Fri, 10 Jun 2016 13:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=I/VwGYO62/0jOOd0Ms1YD1QltK/WaJYM2sHcP0OtbKw=; b=t83B1KNVZzz1ktZBg47jsH2gCR3HpGUHyQNIwSZ54wZaQVb+6+Bdh+bfVchiInojae DSycntA/dVdCG9GZcUvyj8USQihFHoHrOo/AhjQlRufyoTQ6Wl2ozBlRJBDVLg35oCqB EPku9Wu498QcYwyZmxzSj81kYY6f4S738xLlwJc8Io5QEiG3T9uD1Gs2aJwP9KycbtBw 74I+UrbNpn8P6bf2jZALBHT2OGN8YViIpeOSDolDS4I1NhDPTmDEiE+W09FlyESYhWMn r6WwCuWCR72xJ9sVLJ1yMYO+t1e3vmlNz+6dySKjfq2VM1aMbpuTnN4JEjVHzxmvYV7w TRzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=I/VwGYO62/0jOOd0Ms1YD1QltK/WaJYM2sHcP0OtbKw=; b=WvMJkmqgnC5UrBJp7PclBBeG2s8cBEkFhHsQZnf4eyjNv99vlDVVIm9gqJndh9B7GH z/8j1cLIXZgYBu/ziXEOslsjRavGMXmEZnJz4rP5i9SAO6v0pBxLC1KcJn2bKtjEE2/g LUHz3BpfGCQ8QCJSmvCZ/h7jUfVUncnMaSZuIDNYyxOu1dDKzNhKCJG3XrGM44wmDtF1 kKZcmCfw/PT/gdeuFCXASyDJLjzzFsB1HJ2HydismSRQFelvo1nHUgZc8OUaz9ShNZ8f PXNpzFaODSLglvnDdlIYRe9n6le5mQQrxs+iC5xHAqiDRnqmmppvodH5N44S8/ygKC+t QFrQ== X-Gm-Message-State: ALyK8tKLpFaGHMHDTCW77uQGRWEr+EO3itERTxZlStWkArcj+ggeRCzF/wDBqcN+lX1VRA== X-Received: by 10.129.107.138 with SMTP id g132mr2436773ywc.74.1465591782437; Fri, 10 Jun 2016 13:49:42 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y68sm3132005ywg.26.2016.06.10.13.49.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 13:49:40 -0700 (PDT) Subject: Re: Hop-by-hop options in 2460bis Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A72F16E-91BB-4D89-B2D0-7F22FBE89842"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> Date: Fri, 10 Jun 2016 13:49:36 -0700 Message-Id: <1804FCD4-7D27-464D-B039-E322657B6B37@gmail.com> References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: 6man@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:49:45 -0000 --Apple-Mail=_6A72F16E-91BB-4D89-B2D0-7F22FBE89842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ole, > On Jun 10, 2016, at 11:46 AM, otroan@employees.org wrote: >=20 > Tom, >=20 >>> I agree, that a clarification of what the "may process" means. Ron = proposed the following text on a different thread: >>>=20 >>> When an implementation skips over an HBH Options header, it = continues to process the packet, as if >>> the HBH Options header had not been present in the header chain. >>>=20 >> Thanks for pointing that out. I think that's fine, but I would like = to >> see some explicit requirement that nodes cannot drop packets just >> because HBH option or any other type of EH are present. If they are >> permitted to do that it undermines the whole facility and makes it >> unlikely we will ever deploy any EH in the Internet. >=20 > NEW: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by nodes along a packet's delivery path, including the > source and destination nodes. The Hop-by-Hop Options header, when > present, must immediately follow the IPv6 header. Its presence is > indicated by the value zero in the Next Header field of the IPv6 > header. >=20 > NOTE: While RFC2460 required that all nodes must process the Hop-by- > Hop Options header, it is now expected that nodes only process the > Hop-by-Hop Options header if explicitly configured to do so. > Nodes that do not process or examine the Hop-by-Hop Options header = must ignore it, > and it must be passed on unchanged if forwarded. I think this is fine, except for the last sentence that I think it too = prescriptive for rfc2460bis. It is requiring new behavior. Saying = something like: It is expected that nodes that do not process or examine the = Hop-by-Hop Options header will ignore it, and it will be passed on unchanged if forwarded would be fine. Thanks, Bob >=20 > [...] >=20 >>> the "must -> should -> may process" change, we're relaxing which = nodes need to process the option. >>> only the nodes processing the option needs to consider the high = order bits. >>>=20 >> Allowing intermediate nodes to drop unrecognized options creates >> non-deterministic behavior. For example, if a flow is going through >> one path then all packets with HBH are delivered to the destination, >> but if routing changes and and some intermediate node starting >> dropping packets due to unrecognized EH then we lose connectivity for >> the flow. If we're lucky we might get an ICMP param problem, but if = we >> don't we've lost the flow without endpoints having any idea why. This >> is why I think only receiver should drop for unrecognized options. >=20 > Yes, I accept that argument. Mandatory options (those with any of the = two high order bits set) are mandatory for a reason. Take the jumbo or = the RPL option, you cannot expect that those can be forwarded through a = network unless every node along the path supports the option. I would = argue that trying to send a mandatory option over a network which isn't = configured to handle it is a configuration error. The packet would = likely be dropped regardless of processing of the high order bits. In = practice that means that it is highly unlikely that mandatory options = will be supported in the Internet. >=20 > Which is why I think that we do not have to change the specification = for the high order bits. >=20 > Best regards, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_6A72F16E-91BB-4D89-B2D0-7F22FBE89842 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 iQEcBAEBCgAGBQJXWyfhAAoJEK7rdBF357uoA7gIAInosvIh2BHwa5fkWnhRT94V 1JmACJAdc26qEhlTUG1UNhIHiljGX8vrDscn09G3eAV78MpkyUQQtnTLiOhOxvrU ogYHSbYqTm9j3apJBzz2tlnHX4CsxtC6C5vaBIvyLi+g9qNUMhxnVLcih+CWQWvy i9qyuuNmDSU1PboLZxWsTErIG8SQdMAjiObDg2TUzLTLKwpdKrwZ2eY3IPBJal80 L0yJyjMTmcMLHJmi3tZ/PY9guFmsb7h2dUKP+JsWym8bUs4OekzKcD4jpWIJ1Fqh dDWxAOxl1dr5mXuEDjALK47Jdlp48c5Ox/IvaqdW1PbxvocUpJQcNr3nH5Ly8Y4= =nDw5 -----END PGP SIGNATURE----- --Apple-Mail=_6A72F16E-91BB-4D89-B2D0-7F22FBE89842-- From nobody Fri Jun 10 13:56:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8830B12D959 for ; Fri, 10 Jun 2016 13:56:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 xiKhnppstn4N for ; Fri, 10 Jun 2016 13:56:45 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AFD12D956 for <6man@ietf.org>; Fri, 10 Jun 2016 13:56:45 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id a5so5447082ita.1 for <6man@ietf.org>; Fri, 10 Jun 2016 13:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=qo+Wby662JLSwttKIiprj61w4C+p9SsqoD85yELQUtU=; b=jl2m3KY0uJA18nt5IyM/EYSOeuxv+OXacLbZ5i9XXArLj1hUgqUUT5Wxg9/xj8YPLi 3mzj7sAdhq08+CWICyFnvbBKu7awcYKJ7h6qg+/F/HPyiUMSp+PqSTYi/hJO35ERD11C thoHDV6G1kkL65W5qGQTerjrFvzs+7Bhuz62jWp91zooPNFEXGTP8JszGCbLbGTuV8aR U0ZT/hQuAUpL8qyJwNYeP2/5bhT/I3TPHIjKC9B8h8R5fU7+RE0zos50bl6usZ4hD2Sa CjzRrHyBmXMT7N+/haEnTIiP4dtlmE3194Dq18Loyi4OpDBafHiYd4YytdgMVcTgSxrC 7fhA== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=qo+Wby662JLSwttKIiprj61w4C+p9SsqoD85yELQUtU=; b=Qv1nwC7SYNsatcj1zO9jfIJa00sP1LZOTpf7XLR5+rJ9JnLRAtAZW3fVsnIn4D2tSQ 0y2L2kj5kAZoaVW1uMWI3gkwKkWcAFHgaDIFYqkqePXqbY7HHIVO356jdRbxxebIH6sg vCzKGCet6KD5nXZIneECTSqh91od46fq9g6SnTYIE0I906H+RNYX0D8zXAshi0uCd/m/ 6yx6yL+8TkyCnvw9xQUTpFpTZjLZcJdNTv3lrw+hz4ugUWo2SseAaNWl2NL7Q2u5AWwB 7Bg/hzIZSh1/7A43aFB2e5TeNHk4TqxHuCQqHYVy6GN3Hc4HUI5+enrTBAGrMHMF9+Va yyQA== X-Gm-Message-State: ALyK8tJf3puKi7DzUfZQ06AQppvGaa5VunZWs0r/4Ere30kJ3qyuzJAg520IAskLtWSGX8Q5y4UsSbCegtRAJw== MIME-Version: 1.0 X-Received: by 10.36.16.67 with SMTP id 64mr1697764ity.88.1465592204788; Fri, 10 Jun 2016 13:56:44 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 13:56:44 -0700 (PDT) In-Reply-To: <1804FCD4-7D27-464D-B039-E322657B6B37@gmail.com> References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> <1804FCD4-7D27-464D-B039-E322657B6B37@gmail.com> Date: Fri, 10 Jun 2016 13:56:44 -0700 Message-ID: Subject: Re: Hop-by-hop options in 2460bis From: Tom Herbert To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:56:47 -0000 On Fri, Jun 10, 2016 at 1:49 PM, Bob Hinden wrote: > Ole, > >> On Jun 10, 2016, at 11:46 AM, otroan@employees.org wrote: >> >> Tom, >> >>>> I agree, that a clarification of what the "may process" means. Ron pro= posed the following text on a different thread: >>>> >>>> When an implementation skips over an HBH Options header, it continues= to process the packet, as if >>>> the HBH Options header had not been present in the header chain. >>>> >>> Thanks for pointing that out. I think that's fine, but I would like to >>> see some explicit requirement that nodes cannot drop packets just >>> because HBH option or any other type of EH are present. If they are >>> permitted to do that it undermines the whole facility and makes it >>> unlikely we will ever deploy any EH in the Internet. >> >> NEW: >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by nodes along a packet's delivery path, including the >> source and destination nodes. The Hop-by-Hop Options header, when >> present, must immediately follow the IPv6 header. Its presence is >> indicated by the value zero in the Next Header field of the IPv6 >> header. >> >> NOTE: While RFC2460 required that all nodes must process the Hop-by- >> Hop Options header, it is now expected that nodes only process the >> Hop-by-Hop Options header if explicitly configured to do so. >> Nodes that do not process or examine the Hop-by-Hop Options header mus= t ignore it, >> and it must be passed on unchanged if forwarded. > > I think this is fine, except for the last sentence that I think it too pr= escriptive for rfc2460bis. It is requiring new behavior. Saying something= like: > > It is expected that nodes that do not process or examine the Hop-by-Hop= Options header will > ignore it, and it will be passed on unchanged if forwarded > This sounds somewhat weak and passive to me. Can we say: Nodes that do not process or examine the Hop-by-Hop Options header must ignore it, and must pass it on unchanged if forwarded. Thanks, Tom > would be fine. > > Thanks, > Bob > > >> >> [...] >> >>>> the "must -> should -> may process" change, we're relaxing which nodes= need to process the option. >>>> only the nodes processing the option needs to consider the high order = bits. >>>> >>> Allowing intermediate nodes to drop unrecognized options creates >>> non-deterministic behavior. For example, if a flow is going through >>> one path then all packets with HBH are delivered to the destination, >>> but if routing changes and and some intermediate node starting >>> dropping packets due to unrecognized EH then we lose connectivity for >>> the flow. If we're lucky we might get an ICMP param problem, but if we >>> don't we've lost the flow without endpoints having any idea why. This >>> is why I think only receiver should drop for unrecognized options. >> >> Yes, I accept that argument. Mandatory options (those with any of the tw= o high order bits set) are mandatory for a reason. Take the jumbo or the RP= L option, you cannot expect that those can be forwarded through a network u= nless every node along the path supports the option. I would argue that try= ing to send a mandatory option over a network which isn't configured to han= dle it is a configuration error. The packet would likely be dropped regardl= ess of processing of the high order bits. In practice that means that it is= highly unlikely that mandatory options will be supported in the Internet. >> >> Which is why I think that we do not have to change the specification for= the high order bits. >> >> Best regards, >> Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Fri Jun 10 14:06:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFB12D961 for ; Fri, 10 Jun 2016 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KwUZNKaY4V8G for ; Fri, 10 Jun 2016 14:06:22 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E56512D958 for <6man@ietf.org>; Fri, 10 Jun 2016 14:06:22 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g20so77683609ywb.0 for <6man@ietf.org>; Fri, 10 Jun 2016 14:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=eLs0ynoXvZwe93XZ9XoAnv2ttQvgIEr44H05ky8L/2M=; b=QuHqeL0rHwK/f+CwkI4yIyBNI37erLYFS3IIU2aI7OjKyR5s6yTVmCKaItpdJoDZDM bMjuCvo6rOsQ6l83wD16TP06+gWyuJ73WO44ovirwmdyPWv+yrwgQicTCTzFZ6238YMI fltBUz0qesI+KYQR7MjDMWfEFSC90jrK4EW3RQ4Eo7EHX1RyID/KYNkZTR+NbXYbwpQK 3k9VRdx7N0ej0izWiS+hb2lwgP8s4biu0t7SWRoelkwHarbCaq5xeYpXji99tiARw9pN GfeCPuUqu7dQCh4N39djpdS0xynqDF2DsCg0qJtfbU11WD5Xt7PY0MJOQA7gBM0QOxtx Q+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=eLs0ynoXvZwe93XZ9XoAnv2ttQvgIEr44H05ky8L/2M=; b=WlZUclQmsbQKpIjnWwe1iLQbgn22RzCiSU+Oo0Q0O0d2q1NxOrebGeHywKz61Uj9O8 uPqH2iLgU1d6GihFOMgSEpg4/0bGPRhxMlGXBB036b2HAjDC6FAMC0DYu2L792xpoFHG cWKds4UdJf6x74qQKxDXjxAISGxxLbH+qEQQGuCJb0YeKzaB2DL6d2Hi75DckUEdca4n CrsL7h8Nvd5t94nVVXZdj27Yk0G+l7pZrHazeHO/eCqQcLeAA3sPawc5y8hVgaoe/6Jo 5di6bRl+BfW26otyAFjWsv+f76zHLHoftt6nQmPu36igQogFaqt/xTsWaNBLcf67VwDE gV6w== X-Gm-Message-State: ALyK8tJLX6rP8x+KZ3nf7NL/hpI2TtHnzTdZvO3vu8U1ZJ1i4+ivpJTAFXhlrXqXwBDKXg== X-Received: by 10.129.83.197 with SMTP id h188mr2408959ywb.87.1465592781161; Fri, 10 Jun 2016 14:06:21 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d71sm6995114ywb.50.2016.06.10.14.06.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 14:06:20 -0700 (PDT) Subject: Re: Hop-by-hop options in 2460bis Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BEE7CDA2-155D-4E6F-A44E-DADE2BA4EA78"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Fri, 10 Jun 2016 14:06:17 -0700 Message-Id: References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> <1804FCD4-7D27-464D-B039-E322657B6B37@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.2104) Archived-At: Cc: 6man@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 21:06:24 -0000 --Apple-Mail=_BEE7CDA2-155D-4E6F-A44E-DADE2BA4EA78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, >>=20 >> I think this is fine, except for the last sentence that I think it = too prescriptive for rfc2460bis. It is requiring new behavior. Saying = something like: >>=20 >> It is expected that nodes that do not process or examine the = Hop-by-Hop Options header will >> ignore it, and it will be passed on unchanged if forwarded >>=20 > This sounds somewhat weak and passive to me. Can we say: >=20 > Nodes that do not process or examine the Hop-by-Hop Options header > must ignore it, and must pass it on unchanged if forwarded. >=20 Purposely so. The reason is that we can't advance this to Internet = Standard if we introduce new behavior. We can relax the requirements, = as the text proposed by Ole does. Hope that helps. Bob --Apple-Mail=_BEE7CDA2-155D-4E6F-A44E-DADE2BA4EA78 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 iQEcBAEBCgAGBQJXWyvJAAoJEK7rdBF357uoTfgIAKtKRgagZpC7YMrb8jwIlUrZ 2DECHH3pyAz1sdgrg5GX8dd4uzcRnUeSP35lmmv32SMl+Wp6mFp76LBMjP7WDdJx 4RDHG/1bC+X14nlsj3AyXIRUW1bAs7trCvmyvOJaP6Vl9L0jjFum/1Jau9+wpJR3 T8wvTqirZb9XnJUGNwQLBG5zQE5uf19B8CJaBc/eTLzaGygV3wzYuD/051UerDp/ 4sxWTNbzkoEPOyMv9lTrZfbnYMNw/4Fxx0XvhzP8lH972/fdwIRwpFYmRY+yoFjw lfUmgrFkUqF1RTQsY0073YwbuVAV7MAvf9jxgGxlM5Ut9N1gYnpgfT4aZ1qUO1g= =H46J -----END PGP SIGNATURE----- --Apple-Mail=_BEE7CDA2-155D-4E6F-A44E-DADE2BA4EA78-- From nobody Fri Jun 10 19:40:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2089312D88F for ; Fri, 10 Jun 2016 19:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ERa1tKHzGY2C for ; Fri, 10 Jun 2016 19:40:37 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B74112D59A for ; Fri, 10 Jun 2016 19:40:37 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x189so82473521ywe.3 for ; Fri, 10 Jun 2016 19:40:37 -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; bh=6WIwDtTf2j1Heu+R3OugfDqBtgs6fOBqojCGZSRa35Y=; b=g7ByW1OUeab0trJXpLJXPnY588cOKk1TBneENvTZF8XTM3BukDf90rJoLxPVCz0TS7 yLbutj2HTmgaw2re4IVsiNMTKjcdMk++EdrZqQ/6TPsM5qJRnNI9nMZCU3d4p+ahBDdK GpHwhNcZj9E6urX9xFbaOntjf099e2JCGSaIrte/GA+xmfm2iAuPpX7BoCuHNfOttL4W T6+mdQQf5QiGYrVcklyaHQMlL9ymUcgy5fJNEY8g+8SUIGm7VzmeQC6WVoK+WTJU5Eg1 CCyhwC/v4wPWGWYQpu8wnEDEYe+g+mek85G2d1hgKHBsVliIOnYTlDKzPCW1AzFxw1F3 oncw== 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; bh=6WIwDtTf2j1Heu+R3OugfDqBtgs6fOBqojCGZSRa35Y=; b=Z1TaHSosP46OWqnpiMIROhpxL7yQmZusT4jzZQqqL9i+m3vOlmM2SXfXaO5sqHyTuw hfXBmTxKL1Hze7A0RFicGFJRme74daoY9RocqlvuOr1a0iO8y9Io/C3vWlm5Vs9uobJ3 1uPVTi9iEObUXaJfotsLR7DlQTTj9GpOguRiBlKuYsrSSFWguroBXwIuI3MMamadYWna 9qo9S6xUL3BzPi1HFTTaviaTCEbfIKPSP5Ua4/yfWtEfWJMSEZjKSSwMGfSQcP0NRRZ9 oDjJqeIds1DRgxZZ4qCMsz1pTiD4juNM+5xGYaAZgM2cKeIgEbF4cBGw5gygnrs4dkKS mOiA== X-Gm-Message-State: ALyK8tKErSgxJBozOTx7vdqWt2eJyWKpyC5lv5efC7+jqKKFzuznJ+F16/KyM3rQqVezrGjYBp05obNt0mzzjzQf X-Received: by 10.37.228.198 with SMTP id b189mr2726589ybh.25.1465612836636; Fri, 10 Jun 2016 19:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.192.129 with HTTP; Fri, 10 Jun 2016 19:40:16 -0700 (PDT) In-Reply-To: References: <20160610112331.5714F328081A@clairseach.fuaim.com> From: Lorenzo Colitti Date: Sat, 11 Jun 2016 11:40:16 +0900 Message-ID: Subject: Re: Testing ULAness To: Bob Hinden Content-Type: multipart/alternative; boundary=001a114bc1c68211660534f794e7 Archived-At: Cc: Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:40:39 -0000 --001a114bc1c68211660534f794e7 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 11, 2016 at 12:37 AM, Bob Hinden wrote: > > The key part of that definition is the last part about "beyond an > administrative boundary", which is where the aspects of 4193 come in. > > I get that, but that can be achieved by two ASs sharing a route for a > specific ULA prefix. But that's also possible (and commonly done) for private IPv4 space, which we all agree should have Global: false. The fact that two administrative domains can agree to route bits of address space between each other does not mean that that address space is global or even valid (it could be bogon space, for example). --001a114bc1c68211660534f794e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jun 11, 2016 at 12:37 AM, Bob Hinden <bob.hinden@gmail.com><= /span> wrote:
>=C2=A0= =C2=A0 =C2=A0The key part of that definition is the last part about "= beyond an administrative boundary", which is where the aspects of 4193= come in.

I get that, but that can be achieved by two ASs sharing a route for = a specific ULA prefix.

But that's also = possible (and commonly done) for private IPv4 space, which we all agree sho= uld have Global: false.

The fact that two administ= rative domains can agree to route bits of address space between each other = does not mean that that address space is global or even valid (it could be = bogon space, for example).
--001a114bc1c68211660534f794e7-- From nobody Fri Jun 10 20:52:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3AC12D13A for ; Fri, 10 Jun 2016 20:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 enM8lYgyR0y8 for ; Fri, 10 Jun 2016 20:52:27 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BEA12B007 for ; Fri, 10 Jun 2016 20:52:27 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id b5so29064816pas.3 for ; Fri, 10 Jun 2016 20:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=71cFBl+SF/czsOeC4pNjpmPUqqw/Ene1clLJYNKyS4A=; b=y9zeNw2YacCLfrzFSU9UGir4l31iU2gzrMaqxe6wFtdCjn2ouniQX9e+H0FHWo4dq1 fK4qZVIr8tH8doQ5W5hQ5ddtOp3dKfUgvRGAPC2zB/CxfpGXC9EsAQA6c6oCO7v9uSCw rikAejGkQHMb/uRMAPesZM2S4G9qiiWE1Pr9p9JvbdakQC9TaR03tis0rk2g2NkuYKUL C7Uwz2GQDm0CJBtIW6zEgQ60VaSdYZwJW2ZIrhE3My8UXlzPOX2kE1kID7/alPR//nYg BFQ7MmyOqtHBnZegu4M5R2IRChH+p+MXGkGSnNbRoR3oA5tCBmcSHgYZ/Al0IhRlmmQi tPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=71cFBl+SF/czsOeC4pNjpmPUqqw/Ene1clLJYNKyS4A=; b=ZVr6Cwzr70ja40iNS4oUSk6sDDBJcqym6nsWL2BqnVn+jWgLbDvqcg7Kt6Cuoy0vmh i0LM8ut+yUOSowk9ORnALENre58UxckBdBPu9DrKH55H3vlRtAgmKH7JBCIDeJElv5yf p0k4chaIWScU5O2L1Z6T+c/M8rRlWmQ3s5PlK2ehoElaBwYutwx5ZaqNDRxp6T6P1JMm THwo1Rxixd5n37RFZ7CbHBJ7dYr3LJbGRpe3y+WSkuvwJJTScproHjZ7oUzL4erQpkut ILvNtQwOr0lrbnDG3xaC8uJXcl04a2gZ2J8ch/ym8+J4dTwSTAu+nsBBkZOg6P6rZrRQ KveA== X-Gm-Message-State: ALyK8tLzHB9PgL0mg07WOaoEJyUlDldrhe/POlTqWx7TBas96+DqC6HX+P76lrjllCEhJA== X-Received: by 10.66.251.2 with SMTP id zg2mr6302224pac.32.1465617146228; Fri, 10 Jun 2016 20:52:26 -0700 (PDT) Received: from [192.168.178.22] ([118.148.77.94]) by smtp.gmail.com with ESMTPSA id bm8sm20995945pad.10.2016.06.10.20.52.22 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 20:52:24 -0700 (PDT) Subject: Re: Testing ULAness To: ipv6@ietf.org References: <20160610112331.5714F328081A@clairseach.fuaim.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 11 Jun 2016 15:52:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 03:52:29 -0000 On 11/06/2016 14:40, Lorenzo Colitti wrote: > On Sat, Jun 11, 2016 at 12:37 AM, Bob Hinden wrote: > >>> The key part of that definition is the last part about "beyond an >> administrative boundary", which is where the aspects of 4193 come in. >> >> I get that, but that can be achieved by two ASs sharing a route for a >> specific ULA prefix. > > > But that's also possible (and commonly done) for private IPv4 space, which > we all agree should have Global: false. Afaik, there is no formal definition of global scope for IPv4, as there is for IPv6. So the confusion I'm complaining about doesn't arise for IPv4. Brian > > The fact that two administrative domains can agree to route bits of address > space between each other does not mean that that address space is global or > even valid (it could be bogon space, for example). > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Jun 11 05:57:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C812D9AA for ; Sat, 11 Jun 2016 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 h6fwjpZfHffx for ; Sat, 11 Jun 2016 05:57:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FB312DA96 for <6man@ietf.org>; Sat, 11 Jun 2016 05:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1688; q=dns/txt; s=iport; t=1465649839; x=1466859439; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rSOj8+IgMqnv1QD3YZLty3JZyOv0gsQUR5RW88b2VxQ=; b=TbbbIpyoVUQw6QlOfr8lJN0owiHSAomo1rnGspaYJ9I7YPEwdZN3GPiS VB1IJ5fx8BvURqAdjkBKhkXMwTYm6jtiukj9Ur5X/BA/Hzfz4L21HpSdn r21k5OJ1XbCBWkkTb51CL2WVDW0Vav4maLZWLcLnShqzgYSwS38JqEYSe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgAvClxX/4sNJK1dgz5Wfa8ijACBe?= =?us-ascii?q?RcLhXUCHIELOBQBAQEBAQEBZSeESwEBAwEBAQEgEToLBQsCAQgaAiYCAgIfBgs?= =?us-ascii?q?VEAIEDgWIFgMPCA6tIYxYDYN+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUmg?= =?us-ascii?q?XcIgk6CQ4F9gwErgi8FiAyLNYRsNAGMLYF6Co8WiAGHbAEeNoNubooIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,456,1459814400"; d="scan'208";a="112243003" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jun 2016 12:57:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5BCvIFb021633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Jun 2016 12:57:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 11 Jun 2016 07:57:17 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Sat, 11 Jun 2016 07:57:17 -0500 From: "Pascal Thubert (pthubert)" To: Bob Hinden Subject: Re: Hop-by-hop options in 2460bis Thread-Topic: Hop-by-hop options in 2460bis Thread-Index: AQHRwzMOtgS5UsmaY0KD/CBXVqVOMJ/jRt8AgAAG+gCAABBWAIAAIm4AgAAB/wCAAAKrgIABB10A Date: Sat, 11 Jun 2016 12:57:17 +0000 Message-ID: References: <29CA3CB7-9019-4F69-8740-0B9E3B3128B8@employees.org> <11A6F569-E11E-4F27-A019-C4D33AD23F7E@employees.org> <1804FCD4-7D27-464D-B039-E322657B6B37@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <26D472195A277A46853E85F2804C001F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 12:57:21 -0000 SSBwcmVmZXJyZWQgT2xlJ3MgcHJvcG9zYWwgYnV0IHVuZGVyc3RhbmQgdGhlIHBvaW50LiBXaWxs IHN1cHBvcnQgdGhpcyBjbGFyaWZpY2F0aW9uIHRleHQuDQoNClRoYW5rcyBCb2IhDQoNClBhc2Nh bA0KDQo+IExlIDEwIGp1aW4gMjAxNiDDoCAyMzowNiwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBn bWFpbC5jb20+IGEgw6ljcml0IDoNCj4gDQo+IFRvbSwNCj4gDQo+Pj4gDQo+Pj4gSSB0aGluayB0 aGlzIGlzIGZpbmUsIGV4Y2VwdCBmb3IgdGhlIGxhc3Qgc2VudGVuY2UgdGhhdCBJIHRoaW5rIGl0 IHRvbyBwcmVzY3JpcHRpdmUgZm9yIHJmYzI0NjBiaXMuICBJdCBpcyByZXF1aXJpbmcgbmV3IGJl aGF2aW9yLiAgU2F5aW5nIHNvbWV0aGluZyBsaWtlOg0KPj4+IA0KPj4+IEl0IGlzIGV4cGVjdGVk IHRoYXQgbm9kZXMgdGhhdCBkbyBub3QgcHJvY2VzcyBvciBleGFtaW5lIHRoZSBIb3AtYnktSG9w IE9wdGlvbnMgaGVhZGVyIHdpbGwNCj4+PiBpZ25vcmUgaXQsIGFuZCBpdCB3aWxsIGJlIHBhc3Nl ZCBvbiB1bmNoYW5nZWQgaWYgZm9yd2FyZGVkDQo+PiBUaGlzIHNvdW5kcyBzb21ld2hhdCB3ZWFr IGFuZCBwYXNzaXZlIHRvIG1lLiBDYW4gd2Ugc2F5Og0KPj4gDQo+PiBOb2RlcyB0aGF0IGRvIG5v dCBwcm9jZXNzIG9yIGV4YW1pbmUgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXINCj4+IG11 c3QgaWdub3JlIGl0LCBhbmQgbXVzdCBwYXNzIGl0IG9uIHVuY2hhbmdlZCBpZiBmb3J3YXJkZWQu DQo+IA0KPiBQdXJwb3NlbHkgc28uICBUaGUgcmVhc29uIGlzIHRoYXQgd2UgY2FuJ3QgYWR2YW5j ZSB0aGlzIHRvIEludGVybmV0IFN0YW5kYXJkIGlmIHdlIGludHJvZHVjZSBuZXcgYmVoYXZpb3Iu ICBXZSBjYW4gcmVsYXggdGhlIHJlcXVpcmVtZW50cywgYXMgdGhlIHRleHQgcHJvcG9zZWQgYnkg T2xlIGRvZXMuICBIb3BlIHRoYXQgaGVscHMuDQo+IA0KPiBCb2INCj4gDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRm Lm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Sat Jun 11 08:31:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC612DB5E for ; Sat, 11 Jun 2016 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 0U98PSSI_er1 for ; Sat, 11 Jun 2016 08:31:13 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 4496912DB59 for ; Sat, 11 Jun 2016 08:31:13 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:b00:c500:8b41:e446:85f0:3bf0:bf29]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5BFV7o9000455 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 11 Jun 2016 15:31:08 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:b00:c500:8b41:e446:85f0:3bf0:bf29] claimed to be mb-2.local Subject: Re: Testing ULAness To: Lorenzo Colitti , Bob Hinden References: <20160610112331.5714F328081A@clairseach.fuaim.com> From: joel jaeggli Message-ID: Date: Sat, 11 Jun 2016 08:31:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hR3OfwxexX3gnuqxnSd8hKH7LtPT26h9G" Archived-At: Cc: Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 15:31:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hR3OfwxexX3gnuqxnSd8hKH7LtPT26h9G Content-Type: multipart/mixed; boundary="SvWuWL8DK3goWqhTvspGnptgQGxoHrm8X" From: joel jaeggli To: Lorenzo Colitti , Bob Hinden Cc: Brian Haberman , IPv6 List Message-ID: Subject: Re: Testing ULAness References: <20160610112331.5714F328081A@clairseach.fuaim.com> In-Reply-To: --SvWuWL8DK3goWqhTvspGnptgQGxoHrm8X Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/10/16 7:40 PM, Lorenzo Colitti wrote: > On Sat, Jun 11, 2016 at 12:37 AM, Bob Hinden > wrote: >=20 > > The key part of that definition is the last part about "beyon= d an administrative boundary", which is where the aspects of 4193 come in= =2E >=20 > I get that, but that can be achieved by two ASs sharing a route for= > a specific ULA prefix. >=20 >=20 > But that's also possible (and commonly done) for private IPv4 space, > which we all agree should have Global: false. >=20 > The fact that two administrative domains can agree to route bits of > address space between each other does not mean that that address space > is global or even valid (it could be bogon space, for example). Consenting adults can get together and do all sorts of things I wouldn't choose to do myself. unilateral action on the other hand would be met by best practice filters in most cases. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --SvWuWL8DK3goWqhTvspGnptgQGxoHrm8X-- --hR3OfwxexX3gnuqxnSd8hKH7LtPT26h9G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldcLrsACgkQ8AA1q7Z/VrK/RwCgg9h/rzDBWKqC4uc6Qd5S1S2G LAoAniagwvV6ltkO7+S5sbbKurG9TD/e =t4iT -----END PGP SIGNATURE----- --hR3OfwxexX3gnuqxnSd8hKH7LtPT26h9G-- From nobody Sun Jun 12 11:32:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA57312D123 for ; Sun, 12 Jun 2016 11:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 Q2eqrnrCtQ75 for ; Sun, 12 Jun 2016 11:32:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA8F12B056 for <6man@ietf.org>; Sun, 12 Jun 2016 11:32:42 -0700 (PDT) Received: from localhost ([::1]:58805 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bCABd-00045x-Ca; Sun, 12 Jun 2016 11:32:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: otroan@employees.org X-Trac-Project: 6man Date: Sun, 12 Jun 2016 18:32:41 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #10 (rfc2460bis): Update reference of I-D.hinden-6man-rfc4291bis. X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/10 Message-ID: <063.a3cab36e26a2a42ee6cd541706471c6e@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:32:44 -0000 #10: Update reference of I-D.hinden-6man-rfc4291bis. -- ----------------------------------+----------------- Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Keywords: ----------------------------------+----------------- Ticket URL: 6man From nobody Sun Jun 12 11:34:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B280012D1D2 for ; Sun, 12 Jun 2016 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 6kbTBOKmqpkG for ; Sun, 12 Jun 2016 11:34:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599CA12D0AA for <6man@ietf.org>; Sun, 12 Jun 2016 11:34:01 -0700 (PDT) Received: from localhost ([::1]:58893 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bCACv-0000E9-8S; Sun, 12 Jun 2016 11:34:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: otroan@employees.org X-Trac-Project: 6man Date: Sun, 12 Jun 2016 18:34:01 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #11 (rfc2460bis): HBH header handling X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/11 Message-ID: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:34:03 -0000 #11: HBH header handling 2460bis relaxes the must to a should. And incorporates a paragraph from 7045 giving performance considerations. The use of a _should_ process combined with a _may_ drop is not elegant. The second paragraph can also be read as a licence to drop. After having thought about the text in draft-ietf-6man-hbh-header- handling, I propose the following instead: OLD: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that should be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. It should be noted that due to performance restrictions nodes may ignore the Hop-by-Hop Option header, drop packets containing a hop- by-hop option header, or assign packets containing a hop-by-hop option header to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. NEW: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by nodes along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While RFC2460 required that all nodes must process the Hop-by- Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. In short replace the should we a may, making HBH options header purely optional. Note that section 4.8 in 2460bis already uses a may. I also suggest we remove the 7045 paragraph on performance considerations, that's highly subjective. 3. Section 4.3 HBH OLD: The Hop-by-Hop Options header is used to carry optional information that should be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, and has the following format: NEW: The Hop-by-Hop Options header is used to carry optional information that may be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, and has the following format: Same change as above. -- ----------------------------------+----------------- Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Keywords: ----------------------------------+----------------- Ticket URL: 6man From nobody Sun Jun 12 11:36:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615512D50C; Sun, 12 Jun 2016 11:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 Cq6CvZ1XqqZv; Sun, 12 Jun 2016 11:36:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1B212D0AA; Sun, 12 Jun 2016 11:36:19 -0700 (PDT) Received: from localhost ([::1]:59065 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bCAF9-000066-Dl; Sun, 12 Jun 2016 11:36:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Sun, 12 Jun 2016 18:36:19 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #12 (rfc1981bis): s/proper MTU/path MTU X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/12 Message-ID: <063.9ecc889b9160f99a7586db27dee3f693@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160612183622.9E1B212D0AA@ietfa.amsl.com> Resent-Date: Sun, 12 Jun 2016 11:36:19 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:36:24 -0000 #12: s/proper MTU/path MTU s/proper MTU/path MTU In the following paragraph: An extension to Path MTU Discovery defined in this document can be found in [RFC4821]. It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMP messages to a host is not assured. In this algorithm, the proper MTU is determined by starting with small packets and probing with successively larger packets. The bulk of the algorithm is implemented above IP, in the transport layer (e.g., TCP) or other "Packetization Protocol" that is responsible for determining packet boundaries. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc1981bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc1981bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Sun Jun 12 11:37:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBC212D51A; Sun, 12 Jun 2016 11:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 9oVG_cOI9YQo; Sun, 12 Jun 2016 11:37:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A3912D0AA; Sun, 12 Jun 2016 11:37:04 -0700 (PDT) Received: from localhost ([::1]:59108 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bCAFs-0002f3-7T; Sun, 12 Jun 2016 11:37:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Sun, 12 Jun 2016 18:37:04 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #13 (rfc1981bis): Regardless of whether it decrements the Hop Limit X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/13 Message-ID: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160612183704.75A3912D0AA@ietfa.amsl.com> Resent-Date: Sun, 12 Jun 2016 11:37:04 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:37:05 -0000 #13: Regardless of whether it decrements the Hop Limit .. forwarded by some node (regardless of whether it decrements the Hop Limit) along the path How can "regardless of whether it decrements the Hop Limit" be misunderstood? Should a bridge do PMTUD? ;-) If this is for RFC4389, it is already described there. I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me. Albeit correct in the ND proxy case. How did that experiment go btw? ;-) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc1981bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc1981bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Sun Jun 12 11:38:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3912D0C2 for ; Sun, 12 Jun 2016 11:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cwaensjjRWtU for ; Sun, 12 Jun 2016 11:38:46 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EE512D0AA for ; Sun, 12 Jun 2016 11:38:46 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 62so38751225pfd.1 for ; Sun, 12 Jun 2016 11:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=uQY/GDraHRRPfVMKeFWwQo1Q/uuJ57x4Weu7bS2aY0k=; b=0udfMmQaSrOmr4794Vo4Zm6LOym2Z2sYqUXswOa9XgNYG1wy9h+cCWT1vhRSTu9HXU ucM2pZJHrlkbpl7iUT7FsRvG+uEkVN2d4oS8KfUETmx5fpynpQTCkq8JRmljWA/9+rKs h/AlNoHM5tjOi2Ezvj4hwr0iaFhZnxp22Vooex7uIDE2H7qTwIi4Pl5TToESuCe+C8DK eG6MT+uYASKbRDsUs137x5ifLEv1ULDqRRSn/zSnyvN1uzMBqevuIZcLePqrFbPkCNnW Y98A10pnTPPymzpdZeDMPMoVqFo4ExX8L1N6TYUbQCE8qA2ZcuqVg+Wi2CU07p8RGmIt JDOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=uQY/GDraHRRPfVMKeFWwQo1Q/uuJ57x4Weu7bS2aY0k=; b=WD0hfelGmE2FmvB/QIQmjbaNamVxhDEPXEj9DLLHM6CJM9/4qfq8pXSfjvOAAMqw6n dMa4G+U/eNkepxX5vhaGm2zDArWY65eW4NN1P6+qm/tTvamiSOQwh+mT+0YuOQUiuI7X Tw3S8g1FLsMFvWdVXqwQtbTeNg0Ln+yXnudS/IAv8lCdQjueTZ1lwrVRxEYYQx4AiYUz tgHicKdX1GI4MVUq29FKxw91qoKpJ0mw4iTHiZ1vCXGKY1Jf08vzLi1CirMPVG2O1Ahq DY6LYGHW9TV3rLIgdMtWajjFwNlzhce+LMK+xArDhfQXhX500gfe0TIudB31Tn35VrjL Ivhw== X-Gm-Message-State: ALyK8tLhPsb7wMXNtu9XAiJbmqWtSZa+LPi9ebYWU/iPkWXXYMHQ1GMa7dIq07byeOLIMg== X-Received: by 10.98.98.6 with SMTP id w6mr17076909pfb.0.1465756726359; Sun, 12 Jun 2016 11:38:46 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:a463:7306:8127:3a13? ([2601:647:4d00:abf0:a463:7306:8127:3a13]) by smtp.gmail.com with ESMTPSA id n10sm31765724pax.18.2016.06.12.11.38.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Jun 2016 11:38:44 -0700 (PDT) Subject: Re: Testing ULAness Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_857FCC46-4CE9-49A2-8C35-ADC90B290198"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Sun, 12 Jun 2016 11:38:35 -0700 Message-Id: <566F37E2-47F7-49B8-9518-FC8551ED448A@gmail.com> References: <20160610112331.5714F328081A@clairseach.fuaim.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 18:38:48 -0000 --Apple-Mail=_857FCC46-4CE9-49A2-8C35-ADC90B290198 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lorenzo, > On Jun 10, 2016, at 7:40 PM, Lorenzo Colitti = wrote: >=20 > On Sat, Jun 11, 2016 at 12:37 AM, Bob Hinden = wrote: > > The key part of that definition is the last part about "beyond = an administrative boundary", which is where the aspects of 4193 come in. >=20 > I get that, but that can be achieved by two ASs sharing a route for a = specific ULA prefix. >=20 > But that's also possible (and commonly done) for private IPv4 space, = which we all agree should have Global: false. This is another example why the text in RFC6890 that defines = =E2=80=9Cglobal=E2=80=9D is not correct. IMHO, it should have a clear = definition. Bob >=20 > The fact that two administrative domains can agree to route bits of = address space between each other does not mean that that address space = is global or even valid (it could be bogon space, for example). --Apple-Mail=_857FCC46-4CE9-49A2-8C35-ADC90B290198 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 iQEcBAEBCgAGBQJXXawsAAoJEK7rdBF357uoYU0IALYHeO+8A54yqtla08yd+T55 XUyOhkUnrtXrntYp6XmrQX92tyL8qAq2UKMjzGbP+lRFYU2fw8F681J3tSoseb26 W0frr+KeiYinEEd3aIXA8HzDCEOqwOyjxbFZTRfOt/t6Rr+HJG6HR6v7Ov1B6geg W83+ReJmaGGY0gjAyTRtsffIoXyQ/SzcjipsMEOdcux6pHML8OHFqm0rqdYLWM4z V4wfeDsxM7Iz6Dc2NCQ9E2TjfEFvrFuOJYbPjxJ3SF7f0MoZ5cwpxnv5dK6Q9Mq1 6Xe7kc9zjv00AP1YXoPmVKWpHCRWMUvDMc0xmUIo18hs7pFJa0PlZkiAJ6xok5c= =iLfd -----END PGP SIGNATURE----- --Apple-Mail=_857FCC46-4CE9-49A2-8C35-ADC90B290198-- From nobody Mon Jun 13 20:28:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9084012D14D for ; Mon, 13 Jun 2016 20:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 r6-jtDbyMfmC for ; Mon, 13 Jun 2016 20:28:50 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4646312D105 for ; Mon, 13 Jun 2016 20:28:50 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id i6so13376781ith.0 for ; Mon, 13 Jun 2016 20:28:50 -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; bh=L+04spoklXJK80ea0PcCpqkU+9zQeI4iz6N/fL4t0rM=; b=k2j45zGouGnk6slxWIB46m8QdwRuPh/IQdNb8hK9oJCK2GszWXm0XLZulHDnmZKa3e SqsgVYLSYRtizbzjw/X1GlpsapzDEN3F0ot1/EU1DaiAaypMkPcMzf9LfQtIeRmHpKTJ XvfqKqgS6wU5+yDJVQTNVCDH0rK5MdyWBDjNZRYF3DHIbDMfIAn5IP6L9fWQ0W7nMWrI JpUdPCb9kk7kRl4x6PXJvN60zcdWxk6Urfq6mDA3LLA5SEb6D9RWHHlurYQP2meycZMg 04Vw6TDfQf1vumZf+Opek9oZMNQ031MVrxxkqNh1RsWLKxHiJ6sihW/Sul//Ap8U+GW9 is1g== 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; bh=L+04spoklXJK80ea0PcCpqkU+9zQeI4iz6N/fL4t0rM=; b=X37ZmLPPNCTc+JyvXSks2gkRN+8uUMWnry7ENV9fG7VYEYfBsCXODan4jVg6WP4Fdo TZxv+rW3S5PxYDzFxh4J5PprIlZRY10WS46mlo9xYkvv39shRFQtNKBhPUPE9YWsZ/Iw HjP2E+RkZeGQupxrM0gfqsiPtPJo8Upx3wvON4hlbceqmVCRYaQdKKEGXpBnI9Q2AiPS xibMKxttRQ5MppFoN4mzgDe2pRs/e3cVbilIMbc6wkRukKnn25rbT862R+TT/dY8l6hi EppYPfYXEULeTvBZOpWjWzem9BQiR0T9PIa9Nk3IbZomdikeWrgQHRSIEitErflH3I+t 8maQ== X-Gm-Message-State: ALyK8tJiGAP0Tsj0zDo9/SC2I0SThmsU5M2vB4qQD2t7K9tFIv52gc0vtI/at6ve8XiT08jnAVPeFeUaZfb8d8Ua X-Received: by 10.36.138.197 with SMTP id v188mr23756306itd.82.1465874929509; Mon, 13 Jun 2016 20:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.225.228 with HTTP; Mon, 13 Jun 2016 20:28:29 -0700 (PDT) In-Reply-To: <566F37E2-47F7-49B8-9518-FC8551ED448A@gmail.com> References: <20160610112331.5714F328081A@clairseach.fuaim.com> <566F37E2-47F7-49B8-9518-FC8551ED448A@gmail.com> From: Lorenzo Colitti Date: Mon, 13 Jun 2016 20:28:29 -0700 Message-ID: Subject: Re: Testing ULAness To: Bob Hinden Content-Type: multipart/alternative; boundary=94eb2c08e62675b7080535349ae3 Archived-At: Cc: Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 03:28:52 -0000 --94eb2c08e62675b7080535349ae3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jun 12, 2016 at 11:38 AM, Bob Hinden wrote: > > But that's also possible (and commonly done) for private IPv4 space, > which we all agree should have Global: false. > > This is another example why the text in RFC6890 that defines =E2=80=9Cglo= bal=E2=80=9D is > not correct. IMHO, it should have a clear definition. > It does have a clear definition. I think the problem here is that that definition does not match the definition of "global scope" used in the IPv6 standards. --94eb2c08e62675b7080535349ae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jun 12, 2016 at 11:38 AM, Bob Hinden <bob.hinden@gmail.com><= /span> wrote:
> But t= hat's also possible (and commonly done) for private IPv4 space, which w= e all agree should have Global: false.

This is another example why the text in RFC6890 that defines =E2=80= =9Cglobal=E2=80=9D is not correct.=C2=A0 IMHO, it should have a clear defin= ition.

It does have a clear definition.= I think the problem here is that that definition does not match the defini= tion of "global scope" used in the IPv6 standards.=C2=A0
--94eb2c08e62675b7080535349ae3-- From nobody Tue Jun 14 03:35:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5F12D50B for ; Tue, 14 Jun 2016 03:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 eBK0iw2LLefe for ; Tue, 14 Jun 2016 03:35:13 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D7812D1BE for ; Tue, 14 Jun 2016 03:35:12 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 10:35:11 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1DA879CC4F; Tue, 14 Jun 2016 03:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:date:cc:message-id :references:to; s=selector1; bh=vRprG5rpQNNiSLMe/v515ZmqozI=; b= VbpeSkgM0MoXwAPp68lfh0Oo2VZk/9+NSwWo7VdyphKw4T+JEKIn1sL69bltBImb iZZ1vU/AfwHoAf3FWVPtonSSBZygkU054dd5SduSx9JXp+uIHWxndUQpyky3Ur1C Un9nfzfGLDKdPyQGEs4s57xZn16X2nHCQLfx9IwIC3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:date:cc:message-id :references:to; q=dns; s=selector1; b=KcAlbhAuKOKwJv0gP6b1mupKNv ijF/3dWE5eO3faDkqnFdGic37ard4xfvOeXwX1ADQXs2YBLAGxKB6SOgjwjEf1RJ y7HVtW10+04qOYOCa8cEwolXv+shUAtugDh2SE4lmL6w+4vzgk20xvsJskuPZCT+ kN1oKwgl2a/6f5dU4= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id D0D159CC4E; Tue, 14 Jun 2016 03:35:09 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 40F791D54ACB; Tue, 14 Jun 2016 12:35:05 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_90A88A4B-3F72-4C62-968A-59DA30585AAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: [3rd]: 6MAN IETF96 Call for agenda items X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org Date: Tue, 14 Jun 2016 12:35:01 +0200 Message-Id: References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org, int-ads@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:35:15 -0000 --Apple-Mail=_90A88A4B-3F72-4C62-968A-59DA30585AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have only received one item for the 6MAN meeting in Berlin. The = likely outcome is that we will cancel the 6MAN session and do one or = more interim meetings to resolve 1981bis, 2460bis and 4291bis issues = when Bob is back. Best regards, Ole > Begin forwarded message: >=20 > From: otroan@employees.org > Subject: 6MAN IETF96 Call for agenda items > Date: 23 May 2016 at 10:56:21 GMT+2 > To: 6man WG >=20 > The 6MAN chairs are planning the meeting in Berlin at IETF96. >=20 > If you have a draft you would like to discuss, please send your = request for agenda time to the 6man chairs. Please include in the = request, the title of the presentation, file name of the draft, the = speaker's name (and email), and how much time you would like. >=20 > We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. >=20 > We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, > please plan your presentation accordingly. >=20 > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group = are unlikely to get time at the meeting. >=20 > Please have agenda items to us by 15 June 2016. >=20 > Note: Bob has chosen to prioritise sailing to Hawaii over being with = us in Berlin this time. >=20 > Regards, >=20 > Bob & Ole >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_90A88A4B-3F72-4C62-968A-59DA30585AAB 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 iQEcBAEBCgAGBQJXX93YAAoJED4aXnjSQuKWq+QH/RtaBEjb1O7w/4S4U4vsosBU 12hGx46zNQCijW5lMZXtlFch906XbDzJS5lD9rNuP83tePO62ZMrWLyU5qUtomoG b+OIYscFxAc3a5frh0FRwEyTd/LAIdssAFMxKVgbZZJLnh3c7IeKLibcOrgwBsCC ywLlQT3jsPtQNRq98MAQIIq+1/ur79C+8/cW5IwVkP1KgkCI9vJKrljDbfTswDl6 9wQctDTqi13u+B9j11mVUEEVtD9RsINzr3HiYhdeANkh+YOGL/YQ1PkCOEriqXIM dDNrPIP9+GDIukSpnpjWhdWh8hdFYYdPE6vzK5mcs5ku85s1c3/eZks0e3Kph2k= =6Iv3 -----END PGP SIGNATURE----- --Apple-Mail=_90A88A4B-3F72-4C62-968A-59DA30585AAB-- From nobody Tue Jun 14 09:14:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7C12D1D5 for ; Tue, 14 Jun 2016 09:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jxwc_HlrFS9d for ; Tue, 14 Jun 2016 09:14:31 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB612B068 for ; Tue, 14 Jun 2016 09:14:31 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id j2so51719855vkg.2 for ; Tue, 14 Jun 2016 09:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=L4NQ9ygaXmLQdL8JW8GSfJ1XDZ7XI3zu4EUw0cNuQjE=; b=CIy55/DExRfe9n45k8df2XE4n4RhWfiUuv3F42sh9T/SF6VDjRA8Uf6twwSpN9nUJu 0lq9mQhGhRN5VIqr2QzX+rE6J8lUS9P4xL+I6eaobf7kkc4i8MPwfCXknk1FIHZQFaSQ bFsZiTha0ijH1Hjf3c6l1RWELugKgJrjFoFXcW6iSKMfdmqD7nLZYTs4yXdEKwbenRek 3qNsCGu12fvyvIqcBdwBpFYQMVgAua5SI/cE7Vq98EARy20MYy9GeE4f/AHwTVEDxIh7 CgCEN9m5jWY/jyvB/OopvMCOd6Qm1f3AyiC7psBnJX5HgloMa11RFVofs3fl0/5HguY6 B5ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=L4NQ9ygaXmLQdL8JW8GSfJ1XDZ7XI3zu4EUw0cNuQjE=; b=gcyt3s4cd+ImOtDNcuQaWd0eVfnoCpeJES643uM6JuMEELPyAqhcWEc9aJYfU1UBjn SXCsEV0uUJ1nakeYhOEsJ3eZQVKmgmuFaHRpEwASwGs2R84YhDaxxc05budYAJK6Dfdw aSIswxiFPvj6MBApJi8hqQoQ/69yZ05ugTEmSlBh+s38C3ivVoa9yKKfnTO9KJQtFc9N tFO4zpSxlZKp1qo06IyZwP+Jf0AvE5VsFVTWwp6C45m94gSQq9l2M+oPPPOWFSRyOnzu YDzmNgZfenpEgEx2meWR/vhrfnyE8yzw4DfuKn4gWhhq1ssThq5MlWHjHR/0DsUWpB8+ cnXQ== X-Gm-Message-State: ALyK8tKIUOw1NEAOOOC8nUNNhdEhkBx1BGVl02pNaCHK/lyXqyGSnmlCLu5CwVR0kLbutTDM0OpmUE3v9pnXOQ== X-Received: by 10.176.3.202 with SMTP id 68mr8929032uau.78.1465920870837; Tue, 14 Jun 2016 09:14:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.168 with HTTP; Tue, 14 Jun 2016 09:14:30 -0700 (PDT) In-Reply-To: References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> From: Behcet Sarikaya Date: Tue, 14 Jun 2016 11:14:30 -0500 Message-ID: Subject: Re: [3rd]: 6MAN IETF96 Call for agenda items To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man Chairs <6man-chairs@tools.ietf.org>, int-ads@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:14:33 -0000 Ole, Dan and I may have one slot request. Regards, Behcet On Tue, Jun 14, 2016 at 5:35 AM, wrote: > We have only received one item for the 6MAN meeting in Berlin. The likel= y outcome is that we will cancel the 6MAN session and do one or more interi= m meetings to resolve 1981bis, 2460bis and 4291bis issues when Bob is back. > > Best regards, > Ole > >> Begin forwarded message: >> >> From: otroan@employees.org >> Subject: 6MAN IETF96 Call for agenda items >> Date: 23 May 2016 at 10:56:21 GMT+2 >> To: 6man WG >> >> The 6MAN chairs are planning the meeting in Berlin at IETF96. >> >> If you have a draft you would like to discuss, please send your request = for agenda time to the 6man chairs. Please include in the request, the ti= tle of the presentation, file name of the draft, the speaker's name (and em= ail), and how much time you would like. >> >> We will prioritise drafts that are working group items and drafts that h= ave been actively discussed on the list. >> >> We expect at least half of each talk=E2=80=99s presentation time to be u= sed for open discussion, >> please plan your presentation accordingly. >> >> New drafts not discussed on the mailing list prior to the meeting, >> or drafts that do not appear to have support from the working group are = unlikely to get time at the meeting. >> >> Please have agenda items to us by 15 June 2016. >> >> Note: Bob has chosen to prioritise sailing to Hawaii over being with us = in Berlin this time. >> >> Regards, >> >> Bob & Ole >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 14 13:36:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D49312D99E for ; Tue, 14 Jun 2016 13:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1ez4UiZaKW2n for ; Tue, 14 Jun 2016 13:36:44 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9713B12D93D for ; Tue, 14 Jun 2016 13:35:21 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 62so501715pfd.1 for ; Tue, 14 Jun 2016 13:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rIRrjL5YUm7jQwt+v7Bivc3r3r52tUVg39inW+6o6NM=; b=GwU9QvNcBTKNsl9oX06ciskIGtxvvfYvZCyWbEbYFVDAiP22AwhPlsV1GfM1lvT7CE vkR37t85PGbmblAlJNOzoFWb7yQNYy1qt3FEIBNfFqXh5NznfnW7htiKjRj/0I+8wAI1 m2xGL93alvbrbywDmpnMURwrEEkH49JwTzM7pqF63i/kyonnaypET5nJ9uRZR9d/+uhi Syc4FD8HiJPbfM0ZOpL6BWe00qXXomvZUz9eNfGjkX/bzNaRkkfCpnsjSskJRsfiZim9 VE+sLmtp3o01FMh9qyntWiOd1Vi4jMC3sisCkzHswh5rlMg15zRaFQRdnCum1CvCUOxH 8/FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rIRrjL5YUm7jQwt+v7Bivc3r3r52tUVg39inW+6o6NM=; b=e/8gWnoUAs9fL5u2fHaxMMxACn3EygKrtHZbvFycbw7bchfQzHht0RzPK2eurFBNWX 54ry7pia7MPYEv3ikLxJZzREuplZ73lZjUAGyhuaxJkc5bmV9wmHVo+TKqIrF5lt/mxI lKiSBhQj8Of/L5ndR6PtQhA1HdBAi7ZOR/HglDT7s8BMhuTjE8Av6zUJex7h7v9vEpZF N1nHWKvl1qWrHNk8PcNbZ8W1lTWjqLxhTtwHxeirVZS8dEvAQEw1EN1mLBNlf7oeDNuE ISoixWMaCYOP64SdL75bVWQsrSqdSFiCMCYBI6Kj5uhBIi4U9Su6TlgBgXGNO3dQSl3y xfnw== X-Gm-Message-State: ALyK8tIxfWd0bVRgRdNDRVEaCON8DRFRYgnj589WezmbBOpeZBXkAofL1mdeHuTzqL4QDw== X-Received: by 10.98.69.199 with SMTP id n68mr2526701pfi.160.1465936520859; Tue, 14 Jun 2016 13:35:20 -0700 (PDT) Received: from ?IPv6:2406:e007:6d1a:1:28cc:dc4c:9703:6781? ([2406:e007:6d1a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d8sm47405917pfg.72.2016.06.14.13.35.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 13:35:20 -0700 (PDT) Subject: Re: [3rd]: 6MAN IETF96 Call for agenda items To: sarikaya@ieee.org, Ole Troan References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 15 Jun 2016 08:35:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man Chairs <6man-chairs@tools.ietf.org>, int-ads@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 20:36:46 -0000 That's all not very informative... Ole, could you remind us what that one agenda item is? I have a feeling that we've had a lot of little unresolved arguments over recent months. Maybe we do need some face to face time even though none of the issues are big ones? It would take a little archive trawling to build a list. Regards Brian On 15/06/2016 04:14, Behcet Sarikaya wrote: > Ole, Dan and I may have one slot request. >=20 > Regards, >=20 > Behcet >=20 > On Tue, Jun 14, 2016 at 5:35 AM, wrote: >> We have only received one item for the 6MAN meeting in Berlin. The li= kely outcome is that we will cancel the 6MAN session and do one or more i= nterim meetings to resolve 1981bis, 2460bis and 4291bis issues when Bob i= s back. >> >> Best regards, >> Ole >> >>> Begin forwarded message: >>> >>> From: otroan@employees.org >>> Subject: 6MAN IETF96 Call for agenda items >>> Date: 23 May 2016 at 10:56:21 GMT+2 >>> To: 6man WG >>> >>> The 6MAN chairs are planning the meeting in Berlin at IETF96. >>> >>> If you have a draft you would like to discuss, please send your reque= st for agenda time to the 6man chairs. Please include in the request, t= he title of the presentation, file name of the draft, the speaker's name = (and email), and how much time you would like. >>> >>> We will prioritise drafts that are working group items and drafts tha= t have been actively discussed on the list. >>> >>> We expect at least half of each talk=E2=80=99s presentation time to b= e used for open discussion, >>> please plan your presentation accordingly. >>> >>> New drafts not discussed on the mailing list prior to the meeting, >>> or drafts that do not appear to have support from the working group a= re unlikely to get time at the meeting. >>> >>> Please have agenda items to us by 15 June 2016. >>> >>> Note: Bob has chosen to prioritise sailing to Hawaii over being with = us in Berlin this time. >>> >>> Regards, >>> >>> Bob & Ole >>> >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Jun 14 18:07:12 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7A12DA94; Tue, 14 Jun 2016 18:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rdnss-rfc6106bis-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615010706.31707.70230.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 18:07:06 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 01:07:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Router Advertisement Options for DNS Configuration Authors : Jaehoon Paul Jeong Soohong Daniel Park Luc Beloeil Syam Madanapalli Filename : draft-ietf-6man-rdnss-rfc6106bis-14.txt Pages : 17 Date : 2016-06-14 Abstract: This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document obsoletes RFC 6106 and allows a higher default value of the lifetime of the DNS RA options to avoid the frequent expiry of the options on links with a relatively high rate of packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rdnss-rfc6106bis-14 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 Tue Jun 14 23:14:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6873012B037 for ; Tue, 14 Jun 2016 23:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 4KsqJtQu8zEG for ; Tue, 14 Jun 2016 23:14:15 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A987F12B038 for ; Tue, 14 Jun 2016 23:14:15 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 06:14:14 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 637459CC4F; Tue, 14 Jun 2016 23:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=PvF7p8UxTiF0jrxGJhOXk/B9g0E=; b= PbK+BJv54KhhF/Yjz8AdN16l8FMnrC1lbC16mtNIebS0vvT/xvmGGnbLsQdN1DHG 9E6kIYNqdKJpRU1hcFRsGhrg8KXmjDosoSthVykDAbC0OhlwvexVTEi21QGIEjkR skj9xmc5RgNOO7bnOzF+rXasaSGr7QUvEY+qhOzE64E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=L0QFSZ7lIoFjYy7z26pV6eelGz EG7rgm3YJzAK4ccTs2d4UZYPu3+jKq55AuTGkf4bo5hPQuGgX2Mz+8M3tLoFaxUB KofvVB2UAcnq6dHJrfzP5Q0YKUO33FymnbwsosqJ6gR2kPkwbT+iI7S+K6B67Y2m STUBwUYFcoq42scJY= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 230F79CC4E; Tue, 14 Jun 2016 23:14:13 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E58361DF4ED6; Wed, 15 Jun 2016 08:14:10 +0200 (CEST) Subject: Re: [3rd]: 6MAN IETF96 Call for agenda items Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_51C93D41-5522-4164-8053-B38C27D29B1C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Wed, 15 Jun 2016 08:14:07 +0200 Message-Id: References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man Chairs <6man-chairs@tools.ietf.org>, int-ads@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 06:14:17 -0000 --Apple-Mail=_51C93D41-5522-4164-8053-B38C27D29B1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, > That's all not very informative... Ole, could you remind us > what that one agenda item is? draft-gont-6man-non-stable-iids and we just got a request for draft-ietf-6man-default-iids > I have a feeling that we've had a lot of little unresolved arguments > over recent months. Maybe we do need some face to face time even = though > none of the issues are big ones? It would take a little archive = trawling > to build a list. Yes, I think so too. A rough glance through the list since BA: - IANA IPv6 Special-Purpose Address Registry and unclear use of "global" (draft-carpenter-6man-whats-global) - default-iids, random MACs, stable IIDs, temporary addresses only - RFC2460bis header injection - RFC2460bis HBH header processing - RFC1981bis new text - draft-van-beijnum-multi-mtu - RFC6106bis It would be good if we close the open issues with RFC2460bis, RFC4291bis = and RFC1981bis. Ole --Apple-Mail=_51C93D41-5522-4164-8053-B38C27D29B1C 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 iQEcBAEBCgAGBQJXYPIyAAoJED4aXnjSQuKWRqgH/jSIAq021rNf1vIKQGoUIqjo LotEqJLP3aXxPueTu/Ztwk5ZiKnfVhbz3RRjAgbBseO0+28rOcygQrO9gQwAaNAh hpYB3Wh0Ioa4LfNfnI/WGBqwBXZBwMav/Sfygrm2FKeXYaNM9HlzG99D9sJ9sWUf TwW2VHXydIt/gL9Ei4olmXCq7IXokFuUmGYbnU/z/pm2M5fC2OCKvoo7sLW+Xicu P971SJH6cmQJ/135P8wgR+yhU6LjPP31DM/HciGKvirjtWvW4i2bmDxA2xryuURp PPXBit9Fj3Rfy+fZnh3Qu1itCW1MjUjoRHNiAlSrGBbOsgJp4wmGLT3mK/+Gpog= =TTZM -----END PGP SIGNATURE----- --Apple-Mail=_51C93D41-5522-4164-8053-B38C27D29B1C-- From nobody Wed Jun 15 13:31:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2567912D93C for ; Wed, 15 Jun 2016 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4tpRASRP_TmR for ; Wed, 15 Jun 2016 13:31:00 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F088212D93E for ; Wed, 15 Jun 2016 13:30:59 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id b13so10616555pat.0 for ; Wed, 15 Jun 2016 13:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MYP2pmkc5IVxXJg44UduAaeameYEFQJMYHf9MFS/sto=; b=el9c1Ut37x/zA7erZCacBok0SZx/K6yj97iRCsSAe3K/Wzx6zG/FxHeKq2R+DbO0Ah o2Jp8gN73lM5jHFOkRRM7HTHd5qYBp4hKzuTqRTDx1qiVOkR44bTuB3zfa4np3zEaDcq yP38GE74esp/nsBqUmnWtoApy8IvvaxpU+JrlUWrz8SwMY3RlS1cxYnA8roqLQWBPQx0 ohtWWMyJd3qh+gBBdEt9KacW1QK9BtfTHxPILS6gRLZ35L0M4lEMwuc11DAuIvqxY/Qd QZ1UKb2mzmb4jIuXnucDfPexbgwaE+dVsGIHd+MK9DOPNrlTRHBkoY4txdfi3rQj/jzq UEtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MYP2pmkc5IVxXJg44UduAaeameYEFQJMYHf9MFS/sto=; b=YQ+fhojbdbDaxoDegtxkdioVu1u8LB5t58UAseLVAEwyEudAde1I8On/zozE1AT2Ym W1hlKIceEYe9a/4kQ+u/Xned44WqmM/5xIZKb4SfqiFXqE8476Q8dEgHScG14YoHKd86 ppCW/b6Sj+z31xg8GdOmPXMLxajcJ0NpLBdvwk9Iece9IPuI4cAZd6Rl64zWYzhgUF/J 9OoZOXMt6U1NQg5t9BZLj1+chQCHE/7mba26VWq8UrOvmGbcU/1OqRRyxgg3Tmvk7qO/ GjaHmer03hATOnabpTjafrrjNZ0mY0+obi2b9mEfsABnJ6TgpOt/W1HAY9cLWMFUF0jS YPQw== X-Gm-Message-State: ALyK8tJmsblodmzUjpN0eVxDYacbw7zMAB3UC+F1ja7aMg+LuZo40btUjbfPdcvTw0Xkwg== X-Received: by 10.66.157.193 with SMTP id wo1mr682588pab.116.1466022659523; Wed, 15 Jun 2016 13:30:59 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z88sm27396755pfa.59.2016.06.15.13.30.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 13:30:58 -0700 (PDT) Subject: Re: [3rd]: 6MAN IETF96 Call for agenda items To: otroan@employees.org References: <961B1861-BC96-411F-A579-4BB3F4EE27E7@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <217cf612-115d-4273-b3fc-7470bf831560@gmail.com> Date: Thu, 16 Jun 2016 08:31:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man Chairs <6man-chairs@tools.ietf.org>, int-ads@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:31:01 -0000 So, that looks like an agenda to me. I can prepare a couple of slides on the 'global' terminology if needed. Regards Brian On 15/06/2016 18:14, otroan@employees.org wrote: > Brian, > >> That's all not very informative... Ole, could you remind us >> what that one agenda item is? > > draft-gont-6man-non-stable-iids > and we just got a request for draft-ietf-6man-default-iids > >> I have a feeling that we've had a lot of little unresolved arguments >> over recent months. Maybe we do need some face to face time even though >> none of the issues are big ones? It would take a little archive trawling >> to build a list. > > Yes, I think so too. A rough glance through the list since BA: > > - IANA IPv6 Special-Purpose Address Registry and unclear use of "global" > (draft-carpenter-6man-whats-global) > - default-iids, random MACs, stable IIDs, temporary addresses only > - RFC2460bis header injection > - RFC2460bis HBH header processing > - RFC1981bis new text > - draft-van-beijnum-multi-mtu > - RFC6106bis > > It would be good if we close the open issues with RFC2460bis, RFC4291bis and RFC1981bis. > > Ole > From nobody Wed Jun 15 16:01:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39D112DC1F for ; Wed, 15 Jun 2016 16:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I41h1m41tvNr for ; Wed, 15 Jun 2016 16:01:42 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C2E12D699 for ; Wed, 15 Jun 2016 16:01:42 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id b13so11623540pat.0 for ; Wed, 15 Jun 2016 16:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=h9JFEv2u+cg/jW6QcwccSs30Q+0MS0M39iWivbkrUC4=; b=H6YgLpIPM2RZQlUUH+QOVcuNL2rntHR8Ofakz09rTu2SV/4wMbSSXD+3gZa9W5vvJB PROBQBfk1R87CupZkhBFEQfOVJoatQwBKXaO59nMbvtOmXOT5csQ4hjvSLmelEg0nVWr jhYU1FBA2eUIXlGZ7MpHoqTaBetTp7YM//2721qtVZnHBTTa4Zanzaj/uEPLUl+hGOaM jwbWbKWlmA8Yq2ic3wwBo/EDW5sng6UVUM+rmBApj35zQRYe43MTWWdSfzASRhqu+OLd skMtIZjhDoorpRgJ9PKkPVS5FzDDCSWbjuMtke5Dn4ustTRkqjPkdBAC19cDSC4TjRAz s4mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=h9JFEv2u+cg/jW6QcwccSs30Q+0MS0M39iWivbkrUC4=; b=T/OKuV1As8aoEwDCByhfE3q8O4ZAPRYQaWnW22RiguiwO6kTmLUt4krUmsfSG53Udw uv2CQUGKqgs2dvbthSgUpxikxlTmha5wyF6aK3KREJ3AtahXhNWZKbNC30ZPjEz/yIZH fH3xdgY+1L3u7WWCl8mqbmJZHEofyHMrVQ36z1R6Wc9DcEWFOlH2w9jEKc8VcoXkyi53 Vjbi4r/XNWsQs9SkySW6oVnoqwJcY0VcFQYQcOrCv/TsC0B/n1xCtjFU6C1KGvifrYOJ xKAp1d+DNbOh+gSDg5v8qEJ8SD31f8ZFEZVTG7lNZPqBgQU5mhjoT+junIM3V1A3luSH pG0w== X-Gm-Message-State: ALyK8tLzUGxkxlWmExl2qHA4j2hbrFZUii1J+Z50rR3cD8l0OtjBvG/qHn/yxaxMrHAQBA== X-Received: by 10.66.245.111 with SMTP id xn15mr1342761pac.76.1466031701812; Wed, 15 Jun 2016 16:01:41 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z29sm50339120pff.0.2016.06.15.16.01.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 16:01:40 -0700 (PDT) Subject: Re: 6MAN: Working group last call on RFC2460bis, RFC1981bis and RFC4291bis To: otroan@employees.org, 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Jun 2016 11:01:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:01:44 -0000 Hi, On 30/05/2016 20:15, otroan@employees.org wrote: > This message starts a two week 6MAN Working Group Last Call on advancing: Slightly late, here are my comments after re-reading these drafts. I have systematically reviewed the changes in each version since this exercise started. Most of my issues have been dealt with in previous versions, so I don't have much new to say. One general comment: the authors have chosen to avoid upper case normative keywords. I understand this choice, but I expect it will be brought up at IETF Last Call or IESG review by somebody. It will be worth justifying this choice in the writeup, I think. ... > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-04 I'm happy with this version. I think it expresses the parts of RFC2460 that have been confirmed to be interoperable by years of running code. There are still some subtle changes being discussed around extension header insertion and HbH option processing, however. I think we are very close to consensus now, but one more release of the I-D is needed for those points. ... > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-02 I'm happy with this version. I think that the reference to PLPMTUD is correctly formulated for use in an Internet Standard. ... > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02 I'm happy with this version. I think it correctly treads a narrow line about IIDs in a way that is suitable for an Internet Standard. (I have raised a definitional issue about 'global' scope, but I don't think the text in 4291bis needs changing because of this.) However, I believe that we need to get draft-ietf-6man-default-iids to the IESG at the same time. Having it referenced as a draft in 4291bis is inappropriate, even though it's informational. If that isn't possible, I think the reference should be removed. > as Internet Standards. Substantive comments and statements of support > for publishing these document should be directed to the mailing > list. So, consider this a statement of support once the minor points mentioned above have been resolved. Regards Brian Carpenter From nobody Wed Jun 15 16:06:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189AB12D828 for ; Wed, 15 Jun 2016 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E96vqUcuj1yY for ; Wed, 15 Jun 2016 16:06:27 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB17412D511 for ; Wed, 15 Jun 2016 16:06:26 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c2so13172703pfa.2 for ; Wed, 15 Jun 2016 16:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=x0wNX4/nHsEtMJqXRm/BSPUfyaETx7o0wivjW8gbbvk=; b=QTGToHpOgWnZuKvkOWR51BLNr9aVWsgeGflhFlrvdndty8HqmZpqpViho4DY2t0sxR 0CQ9k1cOXsIKc/a+1QXwV3phRmhkOkC5dqERRBuMLRdmfEqwVa5pkAOCoti4XMfCOgn+ 50RwfF7JfEVa0UiHoSTqcrKU5S1ZC6rAqf0ebkpNX3MYw47D7QljbdLj3eA20Y+8QxHk 96xp2nW2DmcdUjpzVnzrWXoKhq3JjOSIUp/GgEylaOQIJpuyIsAK2eewNgFA4TDWobxr fEi3worCLGQbI8Nc+XrhaQxD/ExuH0c6m+sX/h/5gZQ1mlRRcn1sI0rfrnxoLYCuScdl GiAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=x0wNX4/nHsEtMJqXRm/BSPUfyaETx7o0wivjW8gbbvk=; b=RzBSnt6zCQbyKWpdo7L/IYfZqbwMdh3H75LI6zz1w56KwySjdeBhIdW2B0RD2Aq6R5 kF+QklpsMYOHQjxqNEuW6bPuZmd+vMObqQ1UmjU9zkkg4ZtKURip8eR1/qL4p2KzwliW c5urvnyXwz/GB6iqOIPMtbH6bqikDR3A8rALIRSn6GLoYQ2555hHkGjWwKt0Leltgh32 oLMfJzPH/TT8AEelbUqIx6b41ITVau+hq/FTa5Udfh2iDfhWUREO48VjT+XN9GVh2g8P Hvuj6zYKxaTIDR8z1UYQszrQolTP76mnuLiD1bZE3I3DPf4vDtB5NuO1R99IwV2Mm/b3 4jEw== X-Gm-Message-State: ALyK8tKDGLKsVMaTLMoMHSQRS/oq1pJ3uNLVS0JLpTQ/hKJ5qQI6X93Qm+5nB+DqIBI6PA== X-Received: by 10.98.46.70 with SMTP id u67mr1312153pfu.134.1466031986315; Wed, 15 Jun 2016 16:06:26 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i89sm35213583pfi.22.2016.06.15.16.06.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 16:06:25 -0700 (PDT) Subject: Re: RFC2460bis WGLC comments To: otroan@employees.org, 6man WG References: <3900E424-C491-45FD-BD10-4F8E3943A352@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Jun 2016 11:06:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3900E424-C491-45FD-BD10-4F8E3943A352@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:06:28 -0000 Very brief comments in line... On 08/06/2016 23:43, otroan@employees.org wrote: > I have read through the change set and have the following comments: > > 1. Update reference to working group document: > [I-D.hinden-6man-rfc4291bis]. > > 2. HBH header handling. > > 2460bis relaxes the must to a should. And incorporates a paragraph from 7045 giving performance considerations. > The use of a _should_ process combined with a _may_ drop is not elegant. > The second paragraph can also be read as a licence to drop. > > After having thought about the text in draft-ietf-6man-hbh-header-handling, I propose the following instead: > > OLD: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that should be examined > and processed by every node along a packet's delivery path, including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. > > It should be noted that due to performance restrictions nodes may > ignore the Hop-by-Hop Option header, drop packets containing a hop- > by-hop option header, or assign packets containing a hop-by-hop > option header to a slow processing path. Designers planning to use a > hop-by-hop option need to be aware of this likely behaviour. > > NEW: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by nodes along a packet's delivery path, including the > source and destination nodes. The Hop-by-Hop Options header, when > present, must immediately follow the IPv6 header. Its presence is > indicated by the value zero in the Next Header field of the IPv6 > header. > > NOTE: While RFC2460 required that all nodes must process the Hop-by- > Hop Options header, it is now expected that nodes only process the > Hop-by-Hop Options header if explicitly configured to do so. wfm > > > In short replace the should we a may, making HBH options header purely optional. Note that section 4.8 in 2460bis already uses a may. > I also suggest we remove the 7045 paragraph on performance considerations, that's highly subjective. > > 3. Section 4.3 HBH > OLD: > The Hop-by-Hop Options header is used to carry optional information > that should be examined by every node along a packet's delivery path. > The Hop-by-Hop Options header is identified by a Next Header value of > 0 in the IPv6 header, and has the following format: > > NEW: > The Hop-by-Hop Options header is used to carry optional information > that may be examined by every node along a packet's delivery path. > The Hop-by-Hop Options header is identified by a Next Header value of > 0 in the IPv6 header, and has the following format: wfm > > Same change as above. > > 4. Fragmentation. > > We need more people to review the rewritten fragmentation section. > > Are people comfortable with these new names on the parts? > > +------------------+-------------------------+---//----------------+ > | Per-Fragment | Extension & Upper-Layer | Fragmentable | > | Headers | Headers | Part | > ------------------+-------------------------+---//----------------+ > > I kind of think the old terms where clearer, but it might just be what I'm used to. I'm OK with it. Or with the old terms. Brian From nobody Wed Jun 15 16:18:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77012D9A3 for ; Wed, 15 Jun 2016 16:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vNJDccxyoy-T for ; Wed, 15 Jun 2016 16:18:30 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A6712D7EA for ; Wed, 15 Jun 2016 16:18:30 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c2so13258432pfa.2 for ; Wed, 15 Jun 2016 16:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=URa1nMbeF3gcyJSvChFOI5ONNpDutAtm5T6UVfpLGGw=; b=VO7jhnTAKtpLJmCmqv7PAb5OTDqqQcULYauF+kWUUs2OjAolCHtg516u1651e7ujwj u8RbDgFYPNwgZGEHDqvkSyP0IiLEVDvhAr87mm+/VpV6hgfdF1kyQaR3CSUBXj3Lix5X bFE8VYT9UpFzq2NMdhl5OmXBTfycTure1gZDdVFzgaknwp/TpU/dSbcYOmrqktPeEiPR l5uKaw/ZIhJUlojphIXy5zx7h5CB2zdmrULJWABxTBTy7icv45lIxSXh7uW+8/R0Kx1N A5K39i5knIN6Jlav7/j/rmWe0I2XW3Z4sSKxvcynVZyiOyvkw4RQqDq1mWGfCfmw8tN9 qMyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=URa1nMbeF3gcyJSvChFOI5ONNpDutAtm5T6UVfpLGGw=; b=WTGO4B9KzEfVb38fRkQxVHsbvGKFCt9rW37W/TPGQ7fi9yxDsBJTu4APr/6+ElZMcR 03z1JIu9RaRwtb1asIcDiMfbbj7OProwklFl95onUxmvNVjpu3NRYhsBAnJQ/e+M6TqR zkpRAJlBihENe9MVrUgubRVCMWare5d34FxLmFWYUR4XflZTRvQ6GXp42GL+J+t+bmq+ PDuinl8yLWLM/GgnJubZ/knTFxkthIjnrOwF0Kd5c5UTyuN/DJS/+VnwLvJ+hnnmMIoP cim55KuP1V/dfB/hF0nJl6EbZqXceI/qkWJcoLPPA8QQq1MyDbc1khkb48G9i0eXIfUY yFgA== X-Gm-Message-State: ALyK8tLER4DVqSpJUn/IAVslxxj+MLBJ8g4RLPTIsJxzzdc4z9pZcFfczPrFYgbchd7ulg== X-Received: by 10.98.8.156 with SMTP id 28mr1389947pfi.89.1466032710042; Wed, 15 Jun 2016 16:18:30 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h77sm23298327pfj.86.2016.06.15.16.18.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 16:18:29 -0700 (PDT) Subject: Re: RFC1981bis WCLC comments To: otroan@employees.org, 6man WG References: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Jun 2016 11:18:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:18:32 -0000 On 09/06/2016 00:01, otroan@employees.org wrote: > I have read through the change set and have the following comments: > > 1. s/proper MTU/path MTU > In the following paragraph: > > An extension to Path MTU Discovery defined in this document can be > found in [RFC4821]. It defines a method for Packetization Layer Path > MTU Discovery (PLPMTUD) designed for use over paths where delivery of > ICMP messages to a host is not assured. In this algorithm, the > proper MTU is determined by starting with small packets and probing > with successively larger packets. The bulk of the algorithm is > implemented above IP, in the transport layer (e.g., TCP) or other > "Packetization Protocol" that is responsible for determining packet > boundaries. This use of 'proper' (for 'correct' or 'appropriate') seems natural to a native English speaker but if it isn't clear, sure, change it. > > > 2. ... forwarded by some node (regardless of whether it decrements the Hop Limit) along the path > > How can "regardless of whether it decrements the Hop Limit" be misunderstood? > Should a bridge do PMTUD? ;-) Well, if it's bridging a packet from a jumbo frame Ethernet to a 1500 byte Ethernet, maybe it should? If it's an encapsulator sending to a low-MTU tunnel, without a suitable adaptation layer, then surely it should. In both cases, it probably won't decrement the Hop Limit. (Cue Fred Templin.) > If this is for RFC4389, it is already described there. I think that's a corner case. > I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me. Not to me. Brian > Albeit correct in the ND proxy case. How did that experiment go btw? ;-) > > Ole > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 16 04:28:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1612D189 for ; Thu, 16 Jun 2016 04:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 0ESC4Uwi2DcL for ; Thu, 16 Jun 2016 04:28:27 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CBB12D119 for ; Thu, 16 Jun 2016 04:28:27 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 11:28:26 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 37E4E9CC51; Thu, 16 Jun 2016 04:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=p1cOpQ8Rfe6L05oZdaDauw7ayLg=; b= SWDaXBvbHttAYJ5aNWwh2JRKZdSAiJqlmU5wsSNjWhomAb8vHKy6lS9Ktmc1zMt6 3kl2v1Ooiss6e/qNrUDlLHFTRCaA/wVXJkLhsgq4a6elVb7gV55DYk4+ysP5z8gD izOEZoy6Y/xz4OuWwrNovkIlSZmyWidiw8WfcgHv+48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=hOF6o0WiHOKtUQNICB5rO/2pzI rsqba50nHrKflISoxs5y4aPYVWIbn68m3XmLcR6NSww671aZueXr2Vq9GKeVliOq gKTo1Vw2q/2JpuHL/2NZPOKAM6u+cV5MLMBzl7YnQAdue5TfEgcxZ3XvOtVXhYHe drdXagV+oBhDZgXRM= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id EA5099CC4F; Thu, 16 Jun 2016 04:28:24 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 996591EE12A5; Thu, 16 Jun 2016 13:28:19 +0200 (CEST) Subject: Re: RFC1981bis WCLC comments Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_708AAC14-E99F-400D-9BBB-2F072C3B4E2D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Thu, 16 Jun 2016 13:28:16 +0200 Message-Id: <848AAE8D-F9EF-4697-A030-73178FDFAD04@employees.org> References: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:28:29 -0000 --Apple-Mail=_708AAC14-E99F-400D-9BBB-2F072C3B4E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >> I have read through the change set and have the following comments: >>=20 >> 1. s/proper MTU/path MTU >> In the following paragraph: >>=20 >> An extension to Path MTU Discovery defined in this document = can be >> found in [RFC4821]. It defines a method for Packetization = Layer Path >> MTU Discovery (PLPMTUD) designed for use over paths where = delivery of >> ICMP messages to a host is not assured. In this algorithm, = the >> proper MTU is determined by starting with small packets and = probing >> with successively larger packets. The bulk of the algorithm = is >> implemented above IP, in the transport layer (e.g., TCP) or = other >> "Packetization Protocol" that is responsible for determining = packet >> boundaries. >=20 > This use of 'proper' (for 'correct' or 'appropriate') seems natural to > a native English speaker but if it isn't clear, sure, change it. OK, thanks. >> 2. ... forwarded by some node (regardless of whether it decrements = the Hop Limit) along the path >>=20 >> How can "regardless of whether it decrements the Hop Limit" be = misunderstood? >> Should a bridge do PMTUD? ;-) >=20 > Well, if it's bridging a packet from a jumbo frame Ethernet to a 1500 = byte Ethernet, > maybe it should? If it's an encapsulator sending to a low-MTU tunnel, = without a > suitable adaptation layer, then surely it should. In both cases, it = probably won't > decrement the Hop Limit. (Cue Fred Templin.) aren't we quite far into layer violations and unspecified behaviour = here? an Ethernet bridge doesn't necessarily even have an IP stack. in the normal encapsulator case it decrements the hop limit. I'm still confused exactly what case we're talking about and why this = should go into an IS document. >> If this is for RFC4389, it is already described there. >=20 > I think that's a corner case. well, it is for this corner case we're making the change, no? >=20 >> I do wonder if we should drop this "clarification" from 1981bis as it = seems a little 'disclarifying' to me. >=20 > Not to me. cheers, Ole --Apple-Mail=_708AAC14-E99F-400D-9BBB-2F072C3B4E2D 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 iQEcBAEBCgAGBQJXYo1TAAoJED4aXnjSQuKWisIH/15LqTbdBfSEv23nZdqHFpj9 vE5NufidX4HjNXHxeIhEVJYEDTVfAbVrMgzVY3ccfLm40DTztXAkcsEce0vOJD5s 4H254by5K0hJeErxQnpc1vrEvNMjlTuV9mRC+tpFLpGwqI/hD5K7TBKSWknbAKCP OHGJqnvHFEhjvXyUattNIaIpjFZJ6bz4tt0zndVEWblDeKkZgmvWrYuGs7suMVxP 3py/UStAZvrye6AQtxbhvqQBb1mHOcddcEo0I7MYAhFajqkTqXX08+FVmmuExWyG 5qR/XVQ5zk59drvrdo8+9gz3w0qb4V7AApkJ4XwuFMmJWDPOiEGwzJbOEeLF17U= =2a33 -----END PGP SIGNATURE----- --Apple-Mail=_708AAC14-E99F-400D-9BBB-2F072C3B4E2D-- From nobody Thu Jun 16 04:30:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31B912D1A4 for ; Thu, 16 Jun 2016 04:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 x2oSIniuOKcZ for ; Thu, 16 Jun 2016 04:30:12 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F065F12D189 for ; Thu, 16 Jun 2016 04:30:11 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 11:30:11 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 338049CC4F; Thu, 16 Jun 2016 04:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=+M6nCkQjjziL4TKR5iZTpw+2h5g=; b= i6pQZehtnQNspUwaBr5tvMistZRGimX4C9K4pBRSXifSEz+NTelN53blVLiqvfWy 2GVymbGMYw2PfcPs/ukppwKyC6GB2cLTcq23Ye5B7Cu8k3y085HF+8mifDO6C42w oA5KjVi4qb/P6o7Q09krZYk5+FRzyP7fhR57XyUn9Do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=n7V9si7rxpXN21DiesZ92dy+J6 IUX6k84AXYuG5tQuhCYygujKzESABDoxj7A3TU3I0rEcvVxb7CqwEwHk84Zs5Nhd p13rdN2yaGaZ98nOoLGCXZyc4iADiT6ERyPyeU0lw1UpWlWr66Os8tEeFLwIofS5 A2LrwdoUgFvg4EoMQ= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id EAEFE9CC4E; Thu, 16 Jun 2016 04:30:09 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CA74B1EE1F75; Thu, 16 Jun 2016 13:30:04 +0200 (CEST) Subject: Re: RFC2460bis WGLC comments Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8C6749F3-14C5-491F-898C-B444C80F55EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Thu, 16 Jun 2016 13:30:04 +0200 Message-Id: References: <3900E424-C491-45FD-BD10-4F8E3943A352@employees.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:30:13 -0000 --Apple-Mail=_8C6749F3-14C5-491F-898C-B444C80F55EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> 4. Fragmentation. >>=20 >> We need more people to review the rewritten fragmentation section. >>=20 >> Are people comfortable with these new names on the parts? >>=20 >> +------------------+-------------------------+---//----------------+ >> | Per-Fragment | Extension & Upper-Layer | Fragmentable | >> | Headers | Headers | Part | >> ------------------+-------------------------+---//----------------+ >>=20 >> I kind of think the old terms where clearer, but it might just be = what I'm used to. >=20 > I'm OK with it. Or with the old terms. splendid! compiling that text with the updating RFCs was apparently quite tedious. let's stick with the current terms. Best regards, Ole --Apple-Mail=_8C6749F3-14C5-491F-898C-B444C80F55EB 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 iQEcBAEBCgAGBQJXYo28AAoJED4aXnjSQuKW52sH/AtKo9Z1XaA9RuvCy60K4nKe yaxsXEOVrD6PBPoARICuULGgSnLSTLTQytuqY0D0g/54maDUTGS+tNRNJeRa1IQv tmEhepNIa8tgfewSNNo63M/N99ieEGCeaPiBSxhvYWIS4+npBoY9JpoNqQvFclGN Xr96PaLe4enmuWXN+u7WM3A25soS/OlY2Di/l53bagXzV7YVvhtoEwvPmYDCmAw9 Gd4sKZRqfDhHCkkNRb5REZuHTY6Ow1KkR01bR0S9SMSWgj5VdsDUbLrT1sZ9hhMd iWOhkrDS7FdoKiS9Kq2nmQKo+Cf5uiC1YJ5Spk0es72msRMO0dgsfd+KtTvU1RE= =D0Ij -----END PGP SIGNATURE----- --Apple-Mail=_8C6749F3-14C5-491F-898C-B444C80F55EB-- From nobody Thu Jun 16 05:57:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75312D5CD for ; Thu, 16 Jun 2016 05:57:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 Zc5yfOq6AHwi for ; Thu, 16 Jun 2016 05:57:43 -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 2942812D5BC for ; Thu, 16 Jun 2016 05:57:42 -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 F2AAC880E2 for ; Thu, 16 Jun 2016 05:57:41 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AA859328081A for ; Thu, 16 Jun 2016 05:57:41 -0700 (PDT) Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt To: ipv6@ietf.org References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> From: Brian Haberman Message-ID: Date: Thu, 16 Jun 2016 08:57:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TmhvB01obFadfhHQJUaedvpfhdx2EcwVB" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:57:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TmhvB01obFadfhHQJUaedvpfhdx2EcwVB Content-Type: multipart/mixed; boundary="LCI7aCDtF32LbEOuE2P3Mo70FOkuUlEj5" From: Brian Haberman To: ipv6@ietf.org Message-ID: Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> In-Reply-To: --LCI7aCDtF32LbEOuE2P3Mo70FOkuUlEj5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/9/16 3:08 AM, otroan@employees.org wrote: >>>> Comments and suggestions welcome, and if there is enough >>>> interest we could perhaps discuss this in Berlin. >>>=20 >>> Thanks for writing this up! >>>=20 >>> I believe if we go back and look at what we tried to achieve it >>> might become easier. >>>=20 >>> ULAs are globally scoped addresses to ensure that NAT is not >>> needed. If ULAs were not globally scoped, then connecting to >>> networks together using ULAs could require the use of NAT. We >>> have "defined" ourselves out of that by declaring them to be >>> globally scoped. Reality might be different, but that's the >>> political direction we wanted. >>>=20 >>> We did not want ULAs to be globally reachable. Which is why there >>> is the by default boundary checks on routing advertisements for >>> example. Using ULAs it would be extremely unlikely that one could >>> engineer global reachability, although among a set of consenting >>> administrative domains they can be routed. >>>=20 >>> Global scope =3D We don't need NAT Not global reachability =3D >>> Affects SAS/DAS selection, use in DNS and so on. >>>=20 >>> 5. Rename the registry column from 'Global' to 'Globally >>> reachable' (and update text and RFC 6890 accordingly). >>>=20 >>> Seems to clarify the meaning of "Global". Wonder if that could be >>> done just with an Errata. >>=20 >> As long as the registry could then include words like: >>=20 >> Note that 'globally reachable' is a practical statement about >> recommended routing practices. It is different from the formal >> 'global unicast' scope defined by [RFC4291bis]. In particular, >> Unique Local Addresses [RFC4193] have global unicast scope but are >> not globally reachable. >=20 > I'm fine with that. >=20 > in practice the statement about global unicast scope is also a > practical statement about recommended practice. I think the change in the column name and a footnote differentiating between globally reachable and globally routable is a reasonable clarification. I think this is a bit more complex than an erratum. Let me coordinate with the other authors of 6890 to see how quickly something can be spun. Regards, Brian --LCI7aCDtF32LbEOuE2P3Mo70FOkuUlEj5-- --TmhvB01obFadfhHQJUaedvpfhdx2EcwVB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXYqJEAAoJEBOZRqCi7goq9ggH/j9Lq5sBOAB82Aam30+z39Co Uhc82qwY0Rz/Lip8xWu5NkbSBwHvAiIVMC3otJDWd0qI8zXWfLvHguk8XcyJKo6T CfT3Sjx0e38zwYwSVKgkNnbYQPP86ZIfpgm+xslVtBf6REslTQwh5Oy4waoHUZGl clmBq/MfZOBuk4G2w4X4SgMq0s7M3+00xucI6yT3YC18Htrwj5qrXHyBLGNKi/z+ Ru2SonIZ1xYgx9CihPp9l+RhpQkfmrzKwD22n/R10zwmgXHN3RtotEsm30A/Wp3f M1H+AKlMv0PV/YxfTI84lfFSgrDnBqIpRME8Xn16GTQEjHaWYF39M7VKpuVybYM= =37rE -----END PGP SIGNATURE----- --TmhvB01obFadfhHQJUaedvpfhdx2EcwVB-- From nobody Thu Jun 16 12:54:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A550E12D630 for ; Thu, 16 Jun 2016 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 L0Lb1RC_vv5f for ; Thu, 16 Jun 2016 12:54:23 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 8918912D14B for ; Thu, 16 Jun 2016 12:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5GJj4JI006759; Thu, 16 Jun 2016 12:45:05 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5GJiriB006450 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2016 12:44:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Jun 2016 12:44:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 16 Jun 2016 12:44:53 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "otroan@employees.org" , 6man WG Subject: RE: RFC1981bis WCLC comments Thread-Topic: RFC1981bis WCLC comments Thread-Index: AQHRx1xHqZnv10RLLEyLNiOMcW4Z15/sf8lg Date: Thu, 16 Jun 2016 19:44:52 +0000 Message-ID: <1086793f43f04c3a9607418c0e30cc2e@XCH15-05-05.nw.nos.boeing.com> References: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 19:54:25 -0000 Hi, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Wednesday, June 15, 2016 4:19 PM > To: otroan@employees.org; 6man WG > Cc: 6man-chairs@tools.ietf.org > Subject: Re: RFC1981bis WCLC comments >=20 > On 09/06/2016 00:01, otroan@employees.org wrote: > > I have read through the change set and have the following comments: > > > > 1. s/proper MTU/path MTU > > In the following paragraph: > > > > An extension to Path MTU Discovery defined in this document = can be > > found in [RFC4821]. It defines a method for Packetization Layer P= ath > > MTU Discovery (PLPMTUD) designed for use over paths where delivery= of > > ICMP messages to a host is not assured. In this algorithm, the > > proper MTU is determined by starting with small packets and probin= g > > with successively larger packets. The bulk of the algorithm is > > implemented above IP, in the transport layer (e.g., TCP) or other > > "Packetization Protocol" that is responsible for determining packe= t > > boundaries. >=20 > This use of 'proper' (for 'correct' or 'appropriate') seems natural to > a native English speaker but if it isn't clear, sure, change it. >=20 > > > > > > 2. ... forwarded by some node (regardless of whether it decrements the = Hop Limit) along the path > > > > How can "regardless of whether it decrements the Hop Limit" be misunder= stood? > > Should a bridge do PMTUD? ;-) >=20 > Well, if it's bridging a packet from a jumbo frame Ethernet to a 1500 byt= e Ethernet, > maybe it should? If it's an encapsulator sending to a low-MTU tunnel, wit= hout a > suitable adaptation layer, then surely it should. In both cases, it proba= bly won't > decrement the Hop Limit. (Cue Fred Templin.) I am OK with the final paragraph of RFC1981bis, Section 3 in this regard. I= also don't mind adding "regardless of whether it decrements the Hop Limit". Thanks - Fred fred.l.templin@boeing.com > > If this is for RFC4389, it is already described there. >=20 > I think that's a corner case. >=20 > > I do wonder if we should drop this "clarification" from 1981bis as it s= eems a little 'disclarifying' to me. >=20 > Not to me. >=20 > Brian >=20 > > Albeit correct in the ND proxy case. How did that experiment go btw? ;-= ) > > > > Ole > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jun 16 18:31:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C44A12DE55 for ; Thu, 16 Jun 2016 18:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2zoN1NjJVOWz for ; Thu, 16 Jun 2016 18:31:44 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE6812DC2A for ; Thu, 16 Jun 2016 18:31:44 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id t190so25238694pfb.3 for ; Thu, 16 Jun 2016 18:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UZ6I4WQKNcTwuil8GxkzZLPes+nMJbSZUKUjpzGVTcw=; b=Qz7nVrz0HHkziUl6q+oYn3gxHwYU0qbYfX+fWpI8IoSm6V4oqYQgL81OOXCujLjchM R+kyYgCf6A8w+m/yKNXCNfYUvYwzD6eQdQl4zMINNxb+NP3JGTp65+zo0HaOXCPuVLLb u5OgS8hYIBrro8bV321dJg0FUHzqM8K183zfa2uQ7E3C3+1s1IaVbN7QpsKfvi3zFOeD eXGuUcH9NuVCyez/hARSDKQfc++c6ysNDQXfOynWMYccE1SkTgqVFMSm5vtAG3IBuHsJ H58hM+M91ajB9ozv6whsFfaaVPq9eAvgpSe0i4WywU+FsrYGmIsrFxzw6hxpfpoyF3mt 4G2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=UZ6I4WQKNcTwuil8GxkzZLPes+nMJbSZUKUjpzGVTcw=; b=E9pxYUSCPoAHUxtpTNAv/L6lLF408vGZqUfk1D6J3lKVycbbbk6FOUeG7MQW9y21yV p8S3H/8XF2L465UBFnl2KF6Ndw5aK2uOS3vaXiFfpPyxyAUncuN/ICU+ciDfBy6DbQiM ZhXFIlxZkMa8RWLGIFZ1tf+rUCs3DQeq8xBrClaWHtU9boyaLD/j5ydnv0Hz3GcjoOqg t1NL9R0z+G/pQl9vw8SzlK+1kf3k3UQUvknAv3vmAZdhMHeAMbhpSeaOX0yTrNDGJjbA SiKtIcouMrfF+qpNPfoQF5WH440KvVXJfvc6uVZ0mnJNw3vwdIP0XJq9IqIbX4FPHyZ1 u3kg== X-Gm-Message-State: ALyK8tJ1XlEKZ0i5zajDnJ5boRU3iL0++aitYA4wMlAdVgmxRLU5fWSuA9CnJbWhl5ULkQ== X-Received: by 10.98.12.22 with SMTP id u22mr3736381pfi.80.1466127104097; Thu, 16 Jun 2016 18:31:44 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id h77sm31350005pfj.86.2016.06.16.18.31.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:31:43 -0700 (PDT) Subject: Re: RFC1981bis WCLC comments To: otroan@employees.org References: <2055953D-CFB0-4793-B214-5A523F8AB215@employees.org> <848AAE8D-F9EF-4697-A030-73178FDFAD04@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <41f6b1e5-fe94-832f-577d-5145d0ceaad0@gmail.com> Date: Fri, 17 Jun 2016 13:31:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <848AAE8D-F9EF-4697-A030-73178FDFAD04@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man-chairs@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:31:46 -0000 On 16/06/2016 23:28, otroan@employees.org wrote: > Brian, > >>> I have read through the change set and have the following comments: >>> >>> 1. s/proper MTU/path MTU >>> In the following paragraph: >>> >>> An extension to Path MTU Discovery defined in this document can be >>> found in [RFC4821]. It defines a method for Packetization Layer Path >>> MTU Discovery (PLPMTUD) designed for use over paths where delivery of >>> ICMP messages to a host is not assured. In this algorithm, the >>> proper MTU is determined by starting with small packets and probing >>> with successively larger packets. The bulk of the algorithm is >>> implemented above IP, in the transport layer (e.g., TCP) or other >>> "Packetization Protocol" that is responsible for determining packet >>> boundaries. >> >> This use of 'proper' (for 'correct' or 'appropriate') seems natural to >> a native English speaker but if it isn't clear, sure, change it. > > OK, thanks. > >>> 2. ... forwarded by some node (regardless of whether it decrements the Hop Limit) along the path >>> >>> How can "regardless of whether it decrements the Hop Limit" be misunderstood? >>> Should a bridge do PMTUD? ;-) >> >> Well, if it's bridging a packet from a jumbo frame Ethernet to a 1500 byte Ethernet, >> maybe it should? If it's an encapsulator sending to a low-MTU tunnel, without a >> suitable adaptation layer, then surely it should. In both cases, it probably won't >> decrement the Hop Limit. (Cue Fred Templin.) > > aren't we quite far into layer violations and unspecified behaviour here? > an Ethernet bridge doesn't necessarily even have an IP stack. Indeed. Having the parenthesis invites that discussion. Maybe you're right and these are unnecessary words. I would be 'no objection' either way. Brian > > in the normal encapsulator case it decrements the hop limit. > > I'm still confused exactly what case we're talking about and why this should go into an IS document. > >>> If this is for RFC4389, it is already described there. >> >> I think that's a corner case. > > well, it is for this corner case we're making the change, no? > >> >>> I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me. >> >> Not to me. > > cheers, > Ole > From nobody Thu Jun 16 18:33:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B5F12DE56 for ; Thu, 16 Jun 2016 18:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5g_jWgzHcJPQ for ; Thu, 16 Jun 2016 18:33:00 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6038D12DC2A for ; Thu, 16 Jun 2016 18:33:00 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id i123so21455306pfg.0 for ; Thu, 16 Jun 2016 18:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IO3VsH73gYq2y3gKrXD/NmAbcNEnmRV0DPc84J5VTVg=; b=TnYXawfsZSgtAyLEDFYdll2X5HeEUvfF7hxiyRG0x1AkKC792gA+KFJUovE6QvDO6E zC4g8PentP+1gqdEXayEgzAu89zaB6NSoQb6rGUN3s0Zsme7u9pHLz1bcQhvbufWRho8 tJp4e7zlE0u/B5lTZoIW3sjb8rr6LwjQ9VHg+RwdVKTyml9AB6sV5jhOtUJwIZ2aokq5 ccLYDhTpXT104is53udLf/e2GHkImdURttONq66Lfi4E/bjzF2l9lsYb1O6CLtmrbr22 gfwN41gyxBEidn8B9ulERseoydQZ3gZVgE4JKkupAXcGLx5wlJCThy1l4axx63ntM3ye Gc/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IO3VsH73gYq2y3gKrXD/NmAbcNEnmRV0DPc84J5VTVg=; b=PGLibXAei7YypAKEJV2ExWuIYR8EgGSbx6FH+LjyDaB31R/uPAzp3qkkvd/l65GJgB MVX+xzRydpwS1PmjQrxuAHVxKBehiEA9GPq/rRPzeQISlgFIDmywa7Ft3ItaRmj5ckve OHiSmL5Lip5g8BtUd0IafViAfl8pY+sMmPjzkqJM4vqBQsEhTZA98tXA3iEWMr2RoPuT i836FWSHMliPRHespXKs0CAGI7Bd9QxiYT2eErZ1E8thJURgCyrS0opIbPdTQe0RjXEY h+eYIeDpIzNGM7DDjYpCn/Ohwb95BzHooSmBQiKuYdHTho7vcfszR6TJslM48hEgmd+Q 7fnw== X-Gm-Message-State: ALyK8tJAScUxi/XIBowr6XWb5mq2SQ8YypUplDST4WSs8VQMIqNFh3QRFC+HVdvnIrDC+w== X-Received: by 10.98.158.206 with SMTP id f75mr8622727pfk.164.1466127179900; Thu, 16 Jun 2016 18:32:59 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id 78sm52307715pfm.43.2016.06.16.18.32.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:32:59 -0700 (PDT) Subject: Re: I-D Action: draft-carpenter-6man-whats-global-00.txt To: Brian Haberman , ipv6@ietf.org References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> <46e67f36-7cb5-8640-a29c-5b58418e28b8@gmail.com> <6B6F680E-F096-4236-961B-2AF9676ACDAD@employees.org> <6acf94a9-b0d1-589e-45fd-6b450914dac2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 17 Jun 2016 13:33:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:33:02 -0000 On 17/06/2016 00:57, Brian Haberman wrote: > > > On 6/9/16 3:08 AM, otroan@employees.org wrote: >>>>> Comments and suggestions welcome, and if there is enough >>>>> interest we could perhaps discuss this in Berlin. >>>> >>>> Thanks for writing this up! >>>> >>>> I believe if we go back and look at what we tried to achieve it >>>> might become easier. >>>> >>>> ULAs are globally scoped addresses to ensure that NAT is not >>>> needed. If ULAs were not globally scoped, then connecting to >>>> networks together using ULAs could require the use of NAT. We >>>> have "defined" ourselves out of that by declaring them to be >>>> globally scoped. Reality might be different, but that's the >>>> political direction we wanted. >>>> >>>> We did not want ULAs to be globally reachable. Which is why there >>>> is the by default boundary checks on routing advertisements for >>>> example. Using ULAs it would be extremely unlikely that one could >>>> engineer global reachability, although among a set of consenting >>>> administrative domains they can be routed. >>>> >>>> Global scope = We don't need NAT Not global reachability = >>>> Affects SAS/DAS selection, use in DNS and so on. >>>> >>>> 5. Rename the registry column from 'Global' to 'Globally >>>> reachable' (and update text and RFC 6890 accordingly). >>>> >>>> Seems to clarify the meaning of "Global". Wonder if that could be >>>> done just with an Errata. >>> >>> As long as the registry could then include words like: >>> >>> Note that 'globally reachable' is a practical statement about >>> recommended routing practices. It is different from the formal >>> 'global unicast' scope defined by [RFC4291bis]. In particular, >>> Unique Local Addresses [RFC4193] have global unicast scope but are >>> not globally reachable. >> >> I'm fine with that. >> >> in practice the statement about global unicast scope is also a >> practical statement about recommended practice. > > I think the change in the column name and a footnote differentiating > between globally reachable and globally routable is a reasonable > clarification. I think this is a bit more complex than an erratum. > > Let me coordinate with the other authors of 6890 to see how quickly > something can be spun. That would be excellent. I won't update my little draft unless somebody requests me to do so. Thanks Brian From nobody Sat Jun 18 14:51:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71812D178 for ; Sat, 18 Jun 2016 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xut8Mpb90GSS for ; Sat, 18 Jun 2016 14:51:40 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC6A12D9F7 for ; Sat, 18 Jun 2016 14:51:40 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id w195so14345834ywd.0 for ; Sat, 18 Jun 2016 14:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=AuDGBpgavn5nRwRI/MxTyxcqo1+3EzccmAYD+ectq7g=; b=Pt6y1iNHJhO6SfFAFIS755WmYF/ilbfq23Vlvmt/l1E7CCxIMq1QMgBkM8Hp0PPYpx YeBcxVhhXVtuKZ9ZJ4talognjRUN/juZ4Tos3j+yoxS+zkp82lktqM6NHhPGOyKjlb+R AovxZ8J4DcnwRl6byrm4zwdJfBmV3WuzcmIb+rpUAYvy273+5y30atI1g5W/nuJP92UY Swai8wojt7srd94jc6hbNDNjQvQWUt5Gr5EJhWb63A3RKnO1qJ6ec7qlHphqRN967aL+ Ymyi1lkLlVX78Kx4ZcjN4nyV0SiaC4ENMDAkU+f7jVgbK4NuBU07qEP3XFerCw5GBcgs 0rFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=AuDGBpgavn5nRwRI/MxTyxcqo1+3EzccmAYD+ectq7g=; b=cRFb/upXKyvLzgQLbQMK9DYlPu/jgyZWGlMcQ1BZfCCnUKC9TXvhzC4fFLu+m5rQFl F3rDJhBrFo4MKvICQK/Pu46u+AcIKw/IC0uN7bHQnSffwAyjwRsKXeVPnaOZP+sWfH2c HvUSwP7KWVuDwGkcIGT2hxNpMM7AmcP1r3+SjhrQhblhfQmQK6jFamiT2TJAZAF+YVN9 O9WVG8BraXvBkrRzztoa+M39TqVbhNWPyddZBLkUynp7hVnOkcvgb3rFUn5K0uV5OYdv yZbJ9VgGGVArjpHr0oNV6Ys5hhsinxvXQn/sl/SeemGz2+azlebjqNqVEybIGwR/NBki YN4w== X-Gm-Message-State: ALyK8tJRsJbWSDNWOqhYwsm7kcYOsLcHh1bS7sczLZOKUBe2awiN6k3TII8xAAplTJ93GQ== X-Received: by 10.37.68.198 with SMTP id r189mr4478861yba.99.1466286698943; Sat, 18 Jun 2016 14:51:38 -0700 (PDT) Received: from [172.22.1.126] ([189.206.2.34]) by smtp.gmail.com with ESMTPSA id i125sm22149513ywc.19.2016.06.18.14.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Jun 2016 14:51:37 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_03193652-FEC7-46FC-99A1-DE24A362DD8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Sat, 18 Jun 2016 16:51:35 -0500 Message-Id: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> References: To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 21:51:42 -0000 --Apple-Mail=_03193652-FEC7-46FC-99A1-DE24A362DD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Stefano, Brian, Ole and I have been discussion the =93header injection=94 = issue off list and have some text to propose. The text in -04 is: Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]. The proposed new text is: The insertion of Extension Headers by any node other than the source of the packet breaks PMTU-discovery and can result in ICMP error messages being sent to the source of the packet that did not insert the header. One approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473]. We think this better describes the issue, and then describes one = approach to how to insert headers without breaking PMTUD. I think this represents a good compromise from both sides of the = discussion. Comments please. Thanks, Bob --Apple-Mail=_03193652-FEC7-46FC-99A1-DE24A362DD8A 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 iQEcBAEBCgAGBQJXZcJnAAoJEK7rdBF357uo/28IAKicIQCTZBsYZEnpkxz6hclN tV3HoIM/pwRTT8o7Jw6teKxsvrWZWEynZ5VyrJr4j7u/noKN7ZELuUcD4367zYZN 46f/P7zFuZLb7LnoSGKgCj/uMO8b5ZXG5mZb7k17eDYGaN901mKfiPQVD5/Be+/R Woq9+engiYugdxtcO3Vj9VrTZ9MYmy6r9nWoYM1aoTPMwdvWpw7R2Ek38GIKBnTD /Tkg9eYMH41+L7eFaLoLa3OukVrE47I+83T0l05WZeFcpMDvxAklCLlE0t9TDwHu WKKk+pv/NlVcSyNIrym7Kdc7q/c4PGybI6d18Q9sAoKkh/QN3v38khxSaNdzPlc= =niKi -----END PGP SIGNATURE----- --Apple-Mail=_03193652-FEC7-46FC-99A1-DE24A362DD8A-- From nobody Sat Jun 18 19:22:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0612DB88 for ; Sat, 18 Jun 2016 19:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[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.626, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7bN5iAzDYeTs for ; Sat, 18 Jun 2016 19:21:56 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622D212DA3D for ; Sat, 18 Jun 2016 19:21:56 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u64so159253796vkf.3 for ; Sat, 18 Jun 2016 19:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1SXoMxRquKZU0RWur6UMIWDTeg25IDNlDPdT8OslIkM=; b=FKabTeEig+bbY5hUd9gSmXnrf/zt0frzx1ozNCnrLnJljyRw15pan3Y90vfxpXrkAq Kc2QKw9Wdb/TPN4tqt1yTksAF9xCxmnpA7JLqtDOqjKX6HuO0EsOCqdk8rkmxd03FA+C lCsUg4XOcnKMIC3OTt/QteGHUqPqFjWZQb95yYqrarylG9brzkWVrwLp3xaTQUuBWrMv DRWG0CqEhczMmN3JOMWe62bR4Q0YO+3f3TxMwbhExeMsEdol2EtJilB3dbTZsjbUtXUG KrlYJtZDtaa1iofXKXacsobbAmzptvLk9PDEAStdX0ygSZ9nBxZzIwVqFz4xnBhJnatM jc6g== 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:date :message-id:subject:from:to:cc; bh=1SXoMxRquKZU0RWur6UMIWDTeg25IDNlDPdT8OslIkM=; b=Eud91mHk/QFocrCwq9L4wW7rPUTAVQKBKczwJ1/UAzRI5fFoSTGy4OV1/z3tMQ5eKv YHixnJvCQZt7IncIwpmeop4S3FJa8GBKXuShyr6DanORScBEnfe0+0Zxp8WOps0gkaJf 4PTgfzH7P8ukBmxUCiQPNcJLjPj10/599W0RG/OriBJRqjikouXa71pILi1fuH3bGvro NIkL1EGqY9rXB/ku62qJ20eusBdRmJPuFfHCj6Cy5klh2RwEDMKu/kFQS36YR1gC7dgJ MqZIJctYqR4aQTdVT2hSGU9U91IFiWp0eWPxnAUO5Ezlpc0Avht0IRUYv3gX2X4itaEG sjYw== X-Gm-Message-State: ALyK8tLBXnOzzHZwa7vBkA66Rakdi5W1/faYtAehVxsZrXyzO8QWHorLY41K+yT4Z7xCNYxnL0Sq+734oHMTuA== MIME-Version: 1.0 X-Received: by 10.159.32.131 with SMTP id 3mr4056743uaa.75.1466302915205; Sat, 18 Jun 2016 19:21:55 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Sat, 18 Jun 2016 19:21:54 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Sat, 18 Jun 2016 19:21:54 -0700 (PDT) In-Reply-To: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> Date: Sun, 19 Jun 2016 12:21:54 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue From: Mark Smith To: Bob Hinden Content-Type: multipart/alternative; boundary=94eb2c0b672664e02505359840ea Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 02:21:59 -0000 --94eb2c0b672664e02505359840ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 19 Jun 2016 07:51, "Bob Hinden" wrote: > > Hi, > > Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inject= ion=E2=80=9D issue off list and have some text to propose. The text in -04 is: > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > The proposed new text is: > > The insertion of Extension Headers by any node other than the source > of the packet breaks PMTU-discovery It breaks anything that believes the source address reported in the packet is the originator of the packet, which includes more than PMTUD. PMTUD is one of the obvious cases where this causes problems. There could be others, has complete analysis been done? Where is it? I think the approach to slip in this exception to RFC2460bis might indicate it hasn't been done. This is a fundamental change to the semantics of the source address field. Currently, the source address field describes the device that created the entire structure of the packet and set the immutable values, and in many cases, most or all of the mutable field values. Allowing EH headers to be inserted means the source address may now not describe the originator of the entire packet's structure and most if not all of its field values. Most importantly, there is no way to tell if the source address still has its RFC2460 meaning - there is no indication the packet has been modified in flight. Any packets that travel though an EH insertion domain may or will become multi-source packets, because multiple layer 3 devices could be the sources of parts if the packet. Multicast addresses are not allowed as source addresses, nor should a single unicast address be allowed in the source address field when the packet has multiple sources for its structure and contents. So the definition of the source address field needs to be changed, because allowing in-flight packet insertions makes its definition wrong too. In all this discussion I have not seen an explanation as to why EH insertion is the best way to solve the particular problem. We are being expected to accept that it is, and to then allow updates to RFC2460 to allow it, despite knowing it causes problems. (I suspect it is because of the tunnelling overhead, but that is my thought, not those of the people wanting to insert EHs. If that is the case, I proposed some ideas in draft-smith-enhance-vne-with-ipv6 which can simply reduce IPv6 tunnelling overhead. If the real problem is tunnelling overhead, then the solution that doesn't require making changes to RFC2460bis is to work on methods of reducing IPv6 over IPv6 tunnelling overhead.) Standards are not set in stone, I think the barrier to change them is just higher. In this case, if people want to allow EH insertion, I think the process to follow, which I would accept, is to prohibit EH insertion in RFC2460bis, because it is such a fundamental change. Then the EH insertion people need to write up a RFC that explains why EH insertion is the better approach over tunnelling (and/or any other reasons they've taken that approach), identifies all the issues that it will cause to anything that currently believes the current definition of the source address field, describes either how those issues will not cause fatal errors or describes why and when these fatal errors are able to be overcome. That RFC can then update RFC2460bis (after it is an RFC), which would include updating the definition of the source address field to describe what it actually now represents (something like "first creator of some or all of the contents of the packet at the point in time along the forwarding path or at the final destination the source address is processed") Regards, Mark. P.S., An analogy I've been using to remember and realise how significant this change is is thinking about the sender field on letters I receive in the (physical) post. I believe (and know it is illegal in .au) for the postal system to modify the contents of letters and postcards, so I can always attribute the contents to the reported sender. If the postal system was allowed to modify contents without attribution, I can never attribute any of the contents entirety or possibly at all to the reported sender. Legal prohibition of in flight modifications, backing the statement that they say they won't do it, means I don't have to pay the price of encryption and authentication of all of my letter contents. > and can result in ICMP error > messages being sent to the source of the packet that did not insert > the header. > > One approach to allowing a header to be inserted is to encapsulate > the packet using another IPv6 header and including the additional > extension header after the first IPv6 header, for example, as defined > in [RFC2473]. > > We think this better describes the issue, and then describes one approach to how to insert headers without breaking PMTUD. > > I think this represents a good compromise from both sides of the discussion. > > Comments please. > > Thanks, > Bob > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c0b672664e02505359840ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 19 Jun 2016 07:51, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
> Hi,
>
> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inj= ection=E2=80=9D issue off list and have some text to propose.=C2=A0 The tex= t in -04 is:
>
> =C2=A0 =C2=A0Extension headers must never be inserted by any node othe= r than the
> =C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must be used= to meet any
> =C2=A0 =C2=A0requirement for inserting headers, for example, as define= d in
> =C2=A0 =C2=A0[RFC2473].
>
> The proposed new text is:
>
> =C2=A0 =C2=A0The insertion of Extension Headers by any node other than= the source
> =C2=A0 =C2=A0of the packet breaks PMTU-discovery

It breaks anything that believes the source address reported= in the packet is the originator of the packet, which includes more than PM= TUD.

PMTUD is one of the obvious cases where this causes problems= . There could be others, has complete analysis been done? Where is it? I th= ink the approach to slip in this exception to RFC2460bis might indicate it = hasn't been done.

This is a fundamental change to the semantics of the source = address field. Currently, the source address field describes the device tha= t created the entire structure of the packet and set the immutable values, = and in many cases, most or all of the mutable field values.

Allowing EH headers to be inserted means the source address = may now not describe the originator of the entire packet's structure an= d most if not all of its field values. Most importantly, there is no way to= tell if the source address still has its RFC2460 meaning - there is no ind= ication the packet has been modified in flight.

Any packets that travel though an EH insertion domain may or= will become multi-source packets, because multiple layer 3 devices could b= e the sources of parts if the packet. Multicast addresses are not allowed a= s source addresses, nor should a single unicast address be allowed in the s= ource address field when the packet has multiple sources for its structure = and contents.

So the definition of the source address field needs to be ch= anged, because allowing in-flight packet insertions makes its definition wr= ong too.

In all this discussion I have not seen an explanation as to = why EH insertion is the best way to solve the particular problem. We are be= ing expected to accept that it is, and to then allow updates to RFC2460 to = allow it, despite knowing it causes problems.

(I suspect it is because of the tunnelling overhead, but th= at is my thought, not those of the people wanting to insert EHs. If that is= the case, I proposed some ideas in draft-smith-enhance-vne-with-ipv6 which= can simply reduce IPv6 tunnelling overhead. If the real problem is tunnell= ing overhead, then the solution that doesn't require making changes to = RFC2460bis is to work on methods of reducing IPv6 over IPv6 tunnelling over= head.)

Standards are not set in stone, I think the barrier to chang= e them is just higher.

In this case, if people want to allow EH insertion, I think = the process to follow, which I would accept, is to prohibit EH insertion in= RFC2460bis, because it is such a fundamental change.

Then the EH insertion people need to write up a RFC that exp= lains why EH insertion is the better approach over tunnelling (and/or any o= ther reasons they've taken that approach), identifies all the issues th= at it will cause to anything that currently believes the current definition= of the source address field, describes either how those issues will not ca= use fatal errors or describes why and when these fatal errors are able to b= e overcome. That RFC can then update RFC2460bis (after it is an RFC), which= would include updating the definition of the source address field to descr= ibe what it actually now represents (something like "first creator of = some or all of the contents of the packet at the point in time along the fo= rwarding path or at the final destination the source address is processed&q= uot;)

Regards,
Mark.

P.S., An analogy I've been using to remember and realise= how significant this change is is thinking about the sender field on lette= rs I receive in the (physical) post. I believe (and know it is illegal in .= au) for the postal system to modify the contents of letters and postcards, = so I can always attribute the contents to the reported sender. If the posta= l system was allowed to modify contents without attribution,=C2=A0 I can ne= ver attribute any of the contents entirety or possibly at all to the report= ed sender. Legal prohibition of in flight modifications, backing the statem= ent that they say they won't do it, means I don't have to pay the p= rice of encryption and authentication of all of my letter contents.

> and can result in ICMP error
> =C2=A0 =C2=A0messages being sent to the source of the packet that did = not insert
> =C2=A0 =C2=A0the header.
>
> =C2=A0 =C2=A0One approach to allowing a header to be inserted is to en= capsulate
> =C2=A0 =C2=A0the packet using another IPv6 header and including the ad= ditional
> =C2=A0 =C2=A0extension header after the first IPv6 header, for example= , as defined
> =C2=A0 =C2=A0in [RFC2473].
>
> We think this better describes the issue, and then describes one appro= ach to how to insert headers without breaking PMTUD.
>
> I think this represents a good compromise from both sides of the discu= ssion.
>
> Comments please.
>
> Thanks,
> Bob
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--94eb2c0b672664e02505359840ea-- From nobody Sat Jun 18 20:57:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A833112D7E7 for ; Sat, 18 Jun 2016 20:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0Qv8881q5e16 for ; Sat, 18 Jun 2016 20:57:25 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A80612D68A for ; Sat, 18 Jun 2016 20:57:25 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id bz2so40206350pad.1 for ; Sat, 18 Jun 2016 20:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WvGhOjovy2ygW5iBi9HiWhFd7j7vTt5SLJy+wdwAL2s=; b=QmdN+V0eAONYNIKM+MaBaT5ysiVzbocrJExyoK8Z5H4QvenFt/J3MvwKha0Alxuw3J sqeZfTUhGUYLnWHYKov1Q9jafnZJRqcPFaIinwj4Pj9JQjPJrzKUOyAgsMle1QB7M3BP 96P12XNDSUokUzGEHUldC+T0S/jMCHSG5Tgip79GfYtgdrUI7hoGddhtXG71ViTKQ8VL mPwbiMei+FhR7KR6+etgLyCK7W1LtLHD931uAIHobFbY5SDbJyorSpnXJQJxPR2/Q8cB qRYxRBQ8xuBvEObQDmXwZxQ26f1PbecK6XgVuOTERMmfSnqWzajoRHynxxnpWAi9E8Bt iUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=WvGhOjovy2ygW5iBi9HiWhFd7j7vTt5SLJy+wdwAL2s=; b=Oi78BDgp+MVsq1PzHRkQgayNPwLNZg58xF1y1hRm0kR8noMxH+aA6ZK0guq40Y6nta WdQB3Eaksjhc3c/WGDH8K7LRv1UWsjSSWHU/z6p311C+Zv/77GmLCXgAeeH+R22X0bFX Z/6V6YIMEBOOS/e7YO79X8LZ2bMlN2cFUWGXpFaibvZf2HREgZVtN1XLg8mA7GvCTEdY pl0naNo5aRT64GgBhEDfpq+1uBcxN+so1W4cJr0tFcJKPdF5eZuE9te1QyQU45MwRf3u OdxlpFHLg5RkI6tHV+dJJOJI0SX4P1VH4mUBMTHApv35Zjf/Y+qowYwSL9qFa7tOC64G Rtqw== X-Gm-Message-State: ALyK8tIn/nwOufFoAe4FkNuKCxRCdY42urXO+2f/4nE2xSAJIP1QDhBHZvdMpJnXl4XJNw== X-Received: by 10.66.161.201 with SMTP id xu9mr12576884pab.140.1466308644560; Sat, 18 Jun 2016 20:57:24 -0700 (PDT) Received: from ?IPv6:2406:e007:7673:1:28cc:dc4c:9703:6781? ([2406:e007:7673:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 203sm44731170pfz.35.2016.06.18.20.57.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Jun 2016 20:57:24 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Mark Smith , Bob Hinden References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3191edc0-c327-f68d-a3ae-5d6305a6dedf@gmail.com> Date: Sun, 19 Jun 2016 15:57:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 03:57:27 -0000 Mark, But are you in a 'no objection' state for the proposed text? Getting 2460bis published is the primary goal here. After that, we can di= scuss next steps. Regards Brian On 19/06/2016 14:21, Mark Smith wrote: > Hi, >=20 > On 19 Jun 2016 07:51, "Bob Hinden" wrote: >> >> Hi, >> >> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inj= ection=E2=80=9D > issue off list and have some text to propose. The text in -04 is: >> >> Extension headers must never be inserted by any node other than the= >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >> >> The proposed new text is: >> >> The insertion of Extension Headers by any node other than the sourc= e >> of the packet breaks PMTU-discovery >=20 > It breaks anything that believes the source address reported in the pac= ket > is the originator of the packet, which includes more than PMTUD. >=20 > PMTUD is one of the obvious cases where this causes problems. There cou= ld > be others, has complete analysis been done? Where is it? I think the > approach to slip in this exception to RFC2460bis might indicate it hasn= 't > been done. >=20 > This is a fundamental change to the semantics of the source address fie= ld. > Currently, the source address field describes the device that created t= he > entire structure of the packet and set the immutable values, and in man= y > cases, most or all of the mutable field values. >=20 > Allowing EH headers to be inserted means the source address may now not= > describe the originator of the entire packet's structure and most if no= t > all of its field values. Most importantly, there is no way to tell if t= he > source address still has its RFC2460 meaning - there is no indication t= he > packet has been modified in flight. >=20 > Any packets that travel though an EH insertion domain may or will becom= e > multi-source packets, because multiple layer 3 devices could be the sou= rces > of parts if the packet. Multicast addresses are not allowed as source > addresses, nor should a single unicast address be allowed in the source= > address field when the packet has multiple sources for its structure an= d > contents. >=20 > So the definition of the source address field needs to be changed, beca= use > allowing in-flight packet insertions makes its definition wrong too. >=20 > In all this discussion I have not seen an explanation as to why EH > insertion is the best way to solve the particular problem. We are being= > expected to accept that it is, and to then allow updates to RFC2460 to > allow it, despite knowing it causes problems. >=20 > (I suspect it is because of the tunnelling overhead, but that is my > thought, not those of the people wanting to insert EHs. If that is the > case, I proposed some ideas in draft-smith-enhance-vne-with-ipv6 which = can > simply reduce IPv6 tunnelling overhead. If the real problem is tunnelli= ng > overhead, then the solution that doesn't require making changes to > RFC2460bis is to work on methods of reducing IPv6 over IPv6 tunnelling > overhead.) >=20 > Standards are not set in stone, I think the barrier to change them is j= ust > higher. >=20 > In this case, if people want to allow EH insertion, I think the process= to > follow, which I would accept, is to prohibit EH insertion in RFC2460bis= , > because it is such a fundamental change. >=20 > Then the EH insertion people need to write up a RFC that explains why E= H > insertion is the better approach over tunnelling (and/or any other reas= ons > they've taken that approach), identifies all the issues that it will ca= use > to anything that currently believes the current definition of the sourc= e > address field, describes either how those issues will not cause fatal > errors or describes why and when these fatal errors are able to be > overcome. That RFC can then update RFC2460bis (after it is an RFC), whi= ch > would include updating the definition of the source address field to > describe what it actually now represents (something like "first creator= of > some or all of the contents of the packet at the point in time along th= e > forwarding path or at the final destination the source address is > processed") >=20 > Regards, > Mark. >=20 > P.S., An analogy I've been using to remember and realise how significan= t > this change is is thinking about the sender field on letters I receive = in > the (physical) post. I believe (and know it is illegal in .au) for the > postal system to modify the contents of letters and postcards, so I can= > always attribute the contents to the reported sender. If the postal sys= tem > was allowed to modify contents without attribution, I can never attrib= ute > any of the contents entirety or possibly at all to the reported sender.= > Legal prohibition of in flight modifications, backing the statement tha= t > they say they won't do it, means I don't have to pay the price of > encryption and authentication of all of my letter contents. >=20 >> and can result in ICMP error >> messages being sent to the source of the packet that did not insert= >> the header. >> >> One approach to allowing a header to be inserted is to encapsulate >> the packet using another IPv6 header and including the additional >> extension header after the first IPv6 header, for example, as defin= ed >> in [RFC2473]. >> >> We think this better describes the issue, and then describes one appro= ach > to how to insert headers without breaking PMTUD. >> >> I think this represents a good compromise from both sides of the > discussion. >> >> Comments please. >> >> Thanks, >> Bob >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sat Jun 18 21:55:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A04912D0A2 for ; Sat, 18 Jun 2016 21:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AI5Rb3jr-TeE for ; Sat, 18 Jun 2016 21:55:19 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6F312D9A2 for ; Sat, 18 Jun 2016 21:55:19 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id u64so160994318vkf.3 for ; Sat, 18 Jun 2016 21:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CSkKwu2uu2qTWHPdW2BjhGptdqvIrpihlxcIKBMx/qI=; b=WUtem8AW1AxPLB3GrGp44sREEpnZrCPFyWXYZ3a9nLpHwIRDJ8YBA+3yLXXMbVoDYk AMlC47H+EAR2sQcHacb8sX2/ZDVwRAW3CnXff4eaSxeMnkCqOK1F8V9VGsnsW8CoAPy2 Y0D/yGiyi8Am9UhS/2FkE7HnMFjhJvtSMIEgaRgDr7kiuR1/RKWF4gHaRyHRf1ujk2m1 fHI0H3L0/8UXFsmDLjkhbnsz9iTE8RJMUPBMB5R50E33zGLoLu04w5+FNqt+CwTIMc8N jyAymiA88kC6kF5cFFn+Hvm35Hb4xJ44CS1J8l4Hjg3YVhazc+lNYLvZYzRn7H07aRSR lKCw== 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-transfer-encoding; bh=CSkKwu2uu2qTWHPdW2BjhGptdqvIrpihlxcIKBMx/qI=; b=EbeI72bzJ3+41dgM4BYdwg4juKIWco2AkxtobPaiDDw0C8vTWsL0twmVA5uWgx71Qh hE+vs1cWxar+Kay03+T6PUKLZifIf37sJDcW7RN3+2oxgESh2FI71CPcMR7wdjjpyFxf VVLrYWCD4GeU+u6Djl0b4Z3e2blOuvfABSoFVcFuFIOg67vRQjzLxBtakOLDK3R8x22V G+aDJtu5R3xDv/oLkAsgGACQ4EHeOTMRlbftU/H6aUR1QiP1W2T9g3l+CAjUleQsjo1p trV8ZOFhUUbVGSwKbl1KSZa/hD+4mowkc2fEZZMT/HZcdHHkm1/NIZbvf2ONM0OhQgGV OPOA== X-Gm-Message-State: ALyK8tL1in7Rg/tyRQoGi2Kj4fTk1tiar5XL0CqNTa+hbvdFIGXLXsRuoLUA63MiirNY4FGBe58LhJj4r/7RPg== X-Received: by 10.31.167.10 with SMTP id q10mr3528975vke.44.1466312118090; Sat, 18 Jun 2016 21:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Sat, 18 Jun 2016 21:54:48 -0700 (PDT) In-Reply-To: <3191edc0-c327-f68d-a3ae-5d6305a6dedf@gmail.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <3191edc0-c327-f68d-a3ae-5d6305a6dedf@gmail.com> From: Mark Smith Date: Sun, 19 Jun 2016 14:54:48 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 04:55:21 -0000 Hi, On 19 June 2016 at 13:57, Brian E Carpenter w= rote: > Mark, > > But are you in a 'no objection' state for the proposed text? > For ref: "One approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473]." I think the terminology "one approach" is not definitive enough. I'm not against other methods that might be developed to insert EHs, however I think they at a minimum they should not break deployed existing mechanisms and existing field semantics, which inserting EHs into an existing packet does. I'd prefer text something like: "The recommended approach to allowing a header to be inserted is to encapsu= late the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473]. Alternate methods to add EHs to an existing packets may developed in the future. They are expected to successfully interoperate with existing IPv6 methods and mechanisms, and to preserve the semantic meanings of this specification's IPv6 packet fields and field values." Regards, Mark. > Getting 2460bis published is the primary goal here. > After that, we can discuss next steps. > > Regards > Brian > > > On 19/06/2016 14:21, Mark Smith wrote: >> Hi, >> >> On 19 Jun 2016 07:51, "Bob Hinden" wrote: >>> >>> Hi, >>> >>> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inje= ction=E2=80=9D >> issue off list and have some text to propose. The text in -04 is: >>> >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >>> >>> The proposed new text is: >>> >>> The insertion of Extension Headers by any node other than the source >>> of the packet breaks PMTU-discovery >> >> It breaks anything that believes the source address reported in the pack= et >> is the originator of the packet, which includes more than PMTUD. >> >> PMTUD is one of the obvious cases where this causes problems. There coul= d >> be others, has complete analysis been done? Where is it? I think the >> approach to slip in this exception to RFC2460bis might indicate it hasn'= t >> been done. >> >> This is a fundamental change to the semantics of the source address fiel= d. >> Currently, the source address field describes the device that created th= e >> entire structure of the packet and set the immutable values, and in many >> cases, most or all of the mutable field values. >> >> Allowing EH headers to be inserted means the source address may now not >> describe the originator of the entire packet's structure and most if not >> all of its field values. Most importantly, there is no way to tell if th= e >> source address still has its RFC2460 meaning - there is no indication th= e >> packet has been modified in flight. >> >> Any packets that travel though an EH insertion domain may or will become >> multi-source packets, because multiple layer 3 devices could be the sour= ces >> of parts if the packet. Multicast addresses are not allowed as source >> addresses, nor should a single unicast address be allowed in the source >> address field when the packet has multiple sources for its structure and >> contents. >> >> So the definition of the source address field needs to be changed, becau= se >> allowing in-flight packet insertions makes its definition wrong too. >> >> In all this discussion I have not seen an explanation as to why EH >> insertion is the best way to solve the particular problem. We are being >> expected to accept that it is, and to then allow updates to RFC2460 to >> allow it, despite knowing it causes problems. >> >> (I suspect it is because of the tunnelling overhead, but that is my >> thought, not those of the people wanting to insert EHs. If that is the >> case, I proposed some ideas in draft-smith-enhance-vne-with-ipv6 which c= an >> simply reduce IPv6 tunnelling overhead. If the real problem is tunnellin= g >> overhead, then the solution that doesn't require making changes to >> RFC2460bis is to work on methods of reducing IPv6 over IPv6 tunnelling >> overhead.) >> >> Standards are not set in stone, I think the barrier to change them is ju= st >> higher. >> >> In this case, if people want to allow EH insertion, I think the process = to >> follow, which I would accept, is to prohibit EH insertion in RFC2460bis, >> because it is such a fundamental change. >> >> Then the EH insertion people need to write up a RFC that explains why EH >> insertion is the better approach over tunnelling (and/or any other reaso= ns >> they've taken that approach), identifies all the issues that it will cau= se >> to anything that currently believes the current definition of the source >> address field, describes either how those issues will not cause fatal >> errors or describes why and when these fatal errors are able to be >> overcome. That RFC can then update RFC2460bis (after it is an RFC), whic= h >> would include updating the definition of the source address field to >> describe what it actually now represents (something like "first creator = of >> some or all of the contents of the packet at the point in time along the >> forwarding path or at the final destination the source address is >> processed") >> >> Regards, >> Mark. >> >> P.S., An analogy I've been using to remember and realise how significant >> this change is is thinking about the sender field on letters I receive i= n >> the (physical) post. I believe (and know it is illegal in .au) for the >> postal system to modify the contents of letters and postcards, so I can >> always attribute the contents to the reported sender. If the postal syst= em >> was allowed to modify contents without attribution, I can never attribu= te >> any of the contents entirety or possibly at all to the reported sender. >> Legal prohibition of in flight modifications, backing the statement that >> they say they won't do it, means I don't have to pay the price of >> encryption and authentication of all of my letter contents. >> >>> and can result in ICMP error >>> messages being sent to the source of the packet that did not insert >>> the header. >>> >>> One approach to allowing a header to be inserted is to encapsulate >>> the packet using another IPv6 header and including the additional >>> extension header after the first IPv6 header, for example, as define= d >>> in [RFC2473]. >>> >>> We think this better describes the issue, and then describes one approa= ch >> to how to insert headers without breaking PMTUD. >>> >>> I think this represents a good compromise from both sides of the >> discussion. >>> >>> Comments please. >>> >>> Thanks, >>> Bob >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From nobody Sun Jun 19 06:57:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091A012D0CB for ; Sun, 19 Jun 2016 06:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 Ulh2xdlp1E3Q for ; Sun, 19 Jun 2016 06:57:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A6612D15A for ; Sun, 19 Jun 2016 06:49:30 -0700 (PDT) Received: from [192.168.1.102] (BSN-95-241-32.static.siol.net [193.95.241.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5455D800B0; Sun, 19 Jun 2016 15:49:11 +0200 (CEST) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Bob Hinden , IPv6 List References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <576688E0.1010303@si6networks.com> Date: Sun, 19 Jun 2016 13:58:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 13:57:46 -0000 On 06/18/2016 11:51 PM, Bob Hinden wrote: > Hi, > > Stefano, Brian, Ole and I have been discussion the “header injection” issue off list and have some text to propose. The text in -04 is: > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > The proposed new text is: > > The insertion of Extension Headers by any node other than the source > of the packet breaks PMTU-discovery and can result in ICMP error > messages being sent to the source of the packet that did not insert > the header. > > One approach to allowing a header to be inserted is to encapsulate > the packet using another IPv6 header and including the additional > extension header after the first IPv6 header, for example, as defined > in [RFC2473]. > > We think this better describes the issue, and then describes one approach to how to insert headers without breaking PMTUD. > > I think this represents a good compromise from both sides of the discussion. IMO, the reason for including the original text you quote above was to remove the ambiguity in the text. The new text fails to respond the question: is header insertion allowed? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jun 19 13:04:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656A012D7C6 for ; Sun, 19 Jun 2016 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jy779cEE1W39 for ; Sun, 19 Jun 2016 13:04:37 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0184612D7A9 for ; Sun, 19 Jun 2016 13:04:36 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id hl6so43819373pac.2 for ; Sun, 19 Jun 2016 13:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7ZxvssfH0hdE4CdOjqIyfDGuf99b4QUlVs/KWWA20rg=; b=AIC83Frsu9qwvdumIjV0cNnQl+y6KHAJQJ6P0r/WxQ3snQqSCZpiv9Yi1p8GFIUUev A6JZs4C6yxHPh5u1zPJrrQ+kvEDflIryeU69OgYAyzkjDZqNNkbY/bRHbuKxdv++7YfW 5mDfE73hp8y8HB/3PFbhE4AjHniU4IcdryQZMGGc3RYgaAujQXh9xyiP+3ZAEWWEtKJg ZvBydzbKp9SikCJv3T1TlzfQ6z8CkZNPDxhEHPwsnFj3A64fDNLLlTE361tm/zIE2NS2 wgeyi5Qkut9+j4fnRosSYr3tlMz37GNXSLaHUOkJ6uUeZ2fL3vf2odNRThKUwp1lzCx+ QjZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=7ZxvssfH0hdE4CdOjqIyfDGuf99b4QUlVs/KWWA20rg=; b=T5WktjdVABr0+3IbbjOwSO8xlMx3TiCx6PAf5A2LRkvUevsx9RyLDGKxgHdhJXtcbc qh6ewMld2KZJdw5OtKu/ttdd8K3xTcbhF3qiEWdsRlWlpCcP3nVwqTuv1E9VkGAIF0hQ n5cmEEpFqLPFMku1jaIosu/ggZnL33R2UUWW/vAPeuiNe9zrMNhIEG1+yorBs+NIZ1KI HsWT1fUVSNTu39ddQfdr61sXmjmJ0cwSsWkdc5ngcKz1UrMqUNegQdetvkyTwUFuylvW v2bRpdIE2E6yIm6kQmIQ/BQce5Agz5NCl57mWDeNqx2MUc1PBDub50z6uxtmyekA/5vx qLVw== X-Gm-Message-State: ALyK8tLuVLaSHjBO1r/hDKCPHyRKBj6lr2Toi0kxQYU29OijRDgHORKiAhezy6YS5nDcrQ== X-Received: by 10.66.165.145 with SMTP id yy17mr7110494pab.116.1466366676515; Sun, 19 Jun 2016 13:04:36 -0700 (PDT) Received: from ?IPv6:2406:e007:52a0:1:28cc:dc4c:9703:6781? ([2406:e007:52a0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x66sm69293742pfi.84.2016.06.19.13.04.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2016 13:04:35 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Fernando Gont , Bob Hinden , IPv6 List References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 20 Jun 2016 08:04:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <576688E0.1010303@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 20:04:38 -0000 Hi Fernando, On 19/06/2016 23:58, Fernando Gont wrote: > On 06/18/2016 11:51 PM, Bob Hinden wrote: >> Hi, >> >> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inj= ection=E2=80=9D issue off list and have some text to propose. The text i= n -04 is: >> >> Extension headers must never be inserted by any node other than the= >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >> >> The proposed new text is: >> >> The insertion of Extension Headers by any node other than the sourc= e >> of the packet breaks PMTU-discovery and can result in ICMP error >> messages being sent to the source of the packet that did not insert= >> the header. >> >> One approach to allowing a header to be inserted is to encapsulate >> the packet using another IPv6 header and including the additional >> extension header after the first IPv6 header, for example, as defin= ed >> in [RFC2473]. >> >> We think this better describes the issue, and then describes one appro= ach to how to insert headers without breaking PMTUD. >> >> I think this represents a good compromise from both sides of the discu= ssion. >=20 > IMO, the reason for including the original text you quote above was to > remove the ambiguity in the text. The new text fails to respond the > question: is header insertion allowed? You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. The suggested compromise leaves it ambiguous. According to Merriam-Webster on-line, the first meaning of "compromise" i= s "a way of reaching agreement in which each person or group gives up somet= hing that was wanted in order to end an argument or dispute" Brian From nobody Sun Jun 19 15:48:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB7712D861 for ; Sun, 19 Jun 2016 15:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZkfAix8HVLjD for ; Sun, 19 Jun 2016 15:48:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A5212D860 for ; Sun, 19 Jun 2016 15:48:46 -0700 (PDT) Received: from [192.168.1.102] (BSN-95-241-32.static.siol.net [193.95.241.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 906148013E; Mon, 20 Jun 2016 00:48:43 +0200 (CEST) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Brian E Carpenter , Bob Hinden , IPv6 List References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57671C97.1040409@si6networks.com> Date: Mon, 20 Jun 2016 00:28:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 22:48:49 -0000 On 06/19/2016 10:04 PM, Brian E Carpenter wrote: > Hi Fernando, > On 19/06/2016 23:58, Fernando Gont wrote: >> On 06/18/2016 11:51 PM, Bob Hinden wrote: >>> Hi, >>> >>> Stefano, Brian, Ole and I have been discussion the “header injection†issue off list and have some text to propose. The text in -04 is: >>> >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >>> >>> The proposed new text is: >>> >>> The insertion of Extension Headers by any node other than the source >>> of the packet breaks PMTU-discovery and can result in ICMP error >>> messages being sent to the source of the packet that did not insert >>> the header. >>> >>> One approach to allowing a header to be inserted is to encapsulate >>> the packet using another IPv6 header and including the additional >>> extension header after the first IPv6 header, for example, as defined >>> in [RFC2473]. >>> >>> We think this better describes the issue, and then describes one approach to how to insert headers without breaking PMTUD. >>> >>> I think this represents a good compromise from both sides of the discussion. >> >> IMO, the reason for including the original text you quote above was to >> remove the ambiguity in the text. The new text fails to respond the >> question: is header insertion allowed? > > You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. > The suggested compromise leaves it ambiguous. > > According to Merriam-Webster on-line, the first meaning of "compromise" is > "a way of reaching agreement in which each person or group gives up something > that was wanted in order to end an argument or dispute" IMO, publish a spec that we agree and know beforehand that is ambiguos is not a good thing. I don't mind if EH-insertion is allowed, or explicitly forbidden. But leaving it unspecified is not a good thing. Besides, the text notes that EH insertion breaks PMTUD... so not sure how that is acceptable. And, if you encapsulate (as noted in the updated text), you're not really allowing EH insertion -- you're simply encapsulating (creating another layer of IPv6). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jun 19 20:49:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA0412D932 for ; Sun, 19 Jun 2016 20:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nSCFIbsMqNDh for ; Sun, 19 Jun 2016 20:49:40 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542BF12D92C for ; Sun, 19 Jun 2016 20:49:40 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d185so180747674vkg.0 for ; Sun, 19 Jun 2016 20:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JR5L9JAxN8nCu6Y4NCR0c5YCWrtM2mN8obh28n3369U=; b=MSAjw56DMRyXHVZBFqk92J2V5CN/b+Sn2NK9qR4oTbnJyJQjofb5A84NBjH2VDzdBL wflwSWbNw3sBjYgmPfHHgYIfS8+M5p+tq55JS73O09b/gwUJzBNrGgkV5/u9RlHuOpfH wi+L1dgTxxAAwbw62IFpPdbrzyLZNNdHwgk7VJA9+L1YcwWsq+AzXvw1KcdCUHXS2h3Z tmp3jwgu8YHqUS5VhYKJPRmzvYZ4d2Aa95ahoy3CC7Jdp/mIz6Td0HFHFl1RnAVU5mfp 1mYWr0rf3O14ilkXxInzl/F1bHShiyc8Nz5Qsn8tldHo3ZpZ0Fz1Tj7oljdPZAznFcSQ f5BA== 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-transfer-encoding; bh=JR5L9JAxN8nCu6Y4NCR0c5YCWrtM2mN8obh28n3369U=; b=FbyRZLJ3YW6f1Pnzi+IMmIht2GC1BfDoj+EPkumoqWt53T7HB5qiCcIOC2qiaqHqOT oSv4QrO12RqRWtJcp+0bBa9oIgxTYgqGPQl8l9QPNNgfD9bkclKvFWl71/jtTmS792uW 2octCvMkxK3cByQt21zh/oTp5Z1E51yp3B/HFYzdbsCCkU+y7fRiJCD7lRUZo6tOfvST VujAVGSNmUzvQXoP+UecL/Sx5kGxyBhsrYAKZcdD87d8wTYUDywxmqSuWBpnRstN0ZLa 4yZFd5YVFsvFM9rfywB2BdtQg66cm9Tk1lLAsd1w1dqrEIAjVpt1mVFvQ3S4LualQFmv LeZA== X-Gm-Message-State: ALyK8tI2+n041PDiGX9B+m/X49ZRK8w1itcZICeo4psS/GsHaXonxKtuNXUd/SsrATnSsiImF1Tbz0QvHoEJsQ== X-Received: by 10.31.136.194 with SMTP id k185mr5789874vkd.2.1466394579353; Sun, 19 Jun 2016 20:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Sun, 19 Jun 2016 20:49:09 -0700 (PDT) In-Reply-To: <57671C97.1040409@si6networks.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: Mark Smith Date: Mon, 20 Jun 2016 13:49:09 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 03:49:42 -0000 On 20 June 2016 at 08:28, Fernando Gont wrote: > On 06/19/2016 10:04 PM, Brian E Carpenter wrote: >> Hi Fernando, >> On 19/06/2016 23:58, Fernando Gont wrote: >>> On 06/18/2016 11:51 PM, Bob Hinden wrote: >>>> Hi, >>>> >>>> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader inj= ection=E2=80=9D issue off list and have some text to propose. The text in = -04 is: >>>> >>>> Extension headers must never be inserted by any node other than the >>>> source of the packet. IP Encapsulation must be used to meet any >>>> requirement for inserting headers, for example, as defined in >>>> [RFC2473]. >>>> >>>> The proposed new text is: >>>> >>>> The insertion of Extension Headers by any node other than the sourc= e >>>> of the packet breaks PMTU-discovery and can result in ICMP error >>>> messages being sent to the source of the packet that did not insert >>>> the header. >>>> >>>> One approach to allowing a header to be inserted is to encapsulate >>>> the packet using another IPv6 header and including the additional >>>> extension header after the first IPv6 header, for example, as defin= ed >>>> in [RFC2473]. >>>> >>>> We think this better describes the issue, and then describes one appro= ach to how to insert headers without breaking PMTUD. >>>> >>>> I think this represents a good compromise from both sides of the discu= ssion. >>> >>> IMO, the reason for including the original text you quote above was to >>> remove the ambiguity in the text. The new text fails to respond the >>> question: is header insertion allowed? >> >> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. >> The suggested compromise leaves it ambiguous. >> >> According to Merriam-Webster on-line, the first meaning of "compromise" = is >> "a way of reaching agreement in which each person or group gives up some= thing >> that was wanted in order to end an argument or dispute" > > IMO, publish a spec that we agree and know beforehand that is ambiguos > is not a good thing. I don't mind if EH-insertion is allowed, or > explicitly forbidden. But leaving it unspecified is not a good thing. > > Besides, the text notes that EH insertion breaks PMTUD... so not sure > how that is acceptable. And, if you encapsulate (as noted in the updated > text), you're not really allowing EH insertion -- you're simply > encapsulating (creating another layer of IPv6). > True, however I think the same end-result is achieved - EH encoded information added to an existing packet as it is forwarded through the network - without confusing what is the original packet and what EH(s) was/were added, and attributing the EH addition to the device with the outer source IPv6 address, rather than creating ambiguity about whether or not it was the packet origin host that created respective EHs in the packet. Another advantage is that the outer header destination IPv6 address very clearly specifies which device the tunnel header EH(s) is intended to be processed by, and it could be a unicast, anycast or multicast destination address. Other forwarding devices remain oblivious to the EHs, performing standard IPv6 forwarding to get the packet to the EH target device. The alternative is for devices that might be interested in the EH inserted into the original packet to have to follow the EH chain of every packet they forward, just to see if the EH they're interested in might be there. That's going to be more work per packet than standard destination IP address forwarding/matching for EH processing that encapsulation + encap. hdr. EH requires. Regards, Mark. > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jun 20 00:35:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDA12B03E for ; Mon, 20 Jun 2016 00:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 qKQY-MMFRqo8 for ; Mon, 20 Jun 2016 00:35:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9031412B02E for ; Mon, 20 Jun 2016 00:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3590; q=dns/txt; s=iport; t=1466408124; x=1467617724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2wkkqqNM1rchIgh7g+zye7fEYBAppWuWjgeQ5oaknrg=; b=kuQ7wQN2azWx7Im8oWm2M1iWPaUu2QENmdMi4LtQV+GVn+ZnAYmEfWCb D1oReM6c7+UJiC5ZeYdZ3Nw1DTNpo1G5xupoTQ5HhxnLmTzUYM8jpP+Ev bndmXlUj8iW/h7m0j0+YM28BQ2zh5pk4wvLKLT3eS8qStempNnfyRTyQW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgCRm2dX/4kNJK1cgz5WfbplgXoXC?= =?us-ascii?q?4V1AoEqOBQBAQEBAQEBZSeESwEBAQMBAQEBawsFCwIBCA4KLicLJQIEDgWIKAg?= =?us-ascii?q?Ovz4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYngXeCVoE5AYJ2EIMsgi8FiBKQZ?= =?us-ascii?q?AGIfYUsjyKPdgEeNoIIDQ+BTG6KSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,497,1459814400"; d="scan'208";a="115027572" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 07:35:23 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5K7ZNDC019578 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 07:35:23 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 02:35:22 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 02:35:22 -0500 From: "Pascal Thubert (pthubert)" To: Fernando Gont Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRyauiBKzFjfzcVUab3aAronMwhp/xBD0AgACH1gCAAChBgIAARPDy Date: Mon, 20 Jun 2016 07:35:22 +0000 Message-ID: <2FCE0E48-C59D-49FF-BDE7-C8E5D0B7540D@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> , <57671C97.1040409@si6networks.com> In-Reply-To: <57671C97.1040409@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 07:35:26 -0000 Hello Fernando; Why are you reopening the dispute? You know it's an infinite loop and all you get is a delay in the publicatio= n. Note the if that group finally work on the right ways of inserting headers,= it will also have to fix. PMTUD. Which is a good idea on its own because t= he concept of a (golden?) path to a destination is just unrealistic anyway.= The proposed text is useful just to point this out. Both are out of scope for 2460bis. So is changing the rules by banning what= is not banned today. The proposed text is fair to the original mandate. Regards, Pascal > Le 20 juin 2016 =E0 00:49, Fernando Gont a =E9cri= t : >=20 >> On 06/19/2016 10:04 PM, Brian E Carpenter wrote: >> Hi Fernando, >>> On 19/06/2016 23:58, Fernando Gont wrote: >>>> On 06/18/2016 11:51 PM, Bob Hinden wrote: >>>> Hi, >>>>=20 >>>> Stefano, Brian, Ole and I have been discussion the =93header injection= =94 issue off list and have some text to propose. The text in -04 is: >>>>=20 >>>> Extension headers must never be inserted by any node other than the >>>> source of the packet. IP Encapsulation must be used to meet any >>>> requirement for inserting headers, for example, as defined in >>>> [RFC2473]. >>>>=20 >>>> The proposed new text is: >>>>=20 >>>> The insertion of Extension Headers by any node other than the source >>>> of the packet breaks PMTU-discovery and can result in ICMP error >>>> messages being sent to the source of the packet that did not insert >>>> the header. >>>>=20 >>>> One approach to allowing a header to be inserted is to encapsulate >>>> the packet using another IPv6 header and including the additional >>>> extension header after the first IPv6 header, for example, as define= d >>>> in [RFC2473]. >>>>=20 >>>> We think this better describes the issue, and then describes one appro= ach to how to insert headers without breaking PMTUD. >>>>=20 >>>> I think this represents a good compromise from both sides of the discu= ssion. >>>=20 >>> IMO, the reason for including the original text you quote above was to >>> remove the ambiguity in the text. The new text fails to respond the >>> question: is header insertion allowed? >>=20 >> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. >> The suggested compromise leaves it ambiguous. >>=20 >> According to Merriam-Webster on-line, the first meaning of "compromise" = is >> "a way of reaching agreement in which each person or group gives up some= thing >> that was wanted in order to end an argument or dispute" >=20 > IMO, publish a spec that we agree and know beforehand that is ambiguos > is not a good thing. I don't mind if EH-insertion is allowed, or > explicitly forbidden. But leaving it unspecified is not a good thing. >=20 > Besides, the text notes that EH insertion breaks PMTUD... so not sure > how that is acceptable. And, if you encapsulate (as noted in the updated > text), you're not really allowing EH insertion -- you're simply > encapsulating (creating another layer of IPv6). >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jun 20 01:36:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403AB12B036 for ; Mon, 20 Jun 2016 01:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3osh02GE-Oji for ; Mon, 20 Jun 2016 01:36:14 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFCB12B026 for ; Mon, 20 Jun 2016 01:36:13 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id j2so186781331vkg.2 for ; Mon, 20 Jun 2016 01:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f7DNmPU4bt3zNkCM6yp8aCThs94qN+HnXqqLXU3WzGI=; b=D9binOQBb4+jryLSxbBtNNtpbusk8pIzczhicuUfaLNP/lgAsS72BJXlNmuBDCXKlf kOvrAAOAxQUGMx2CVXGEu7Jmjf2AvQBKWRbmAcY0DpM+LHS3TtUySe+ogcrIC56eo43G +KoFkZtsqHwWLWcHtN/o3lezOjtsLbaQZo8oeebvjPkCWhgG16APg+sLFzI9w99D/snc r/KaOZxxvwtbq840iy64Z4vvOaaBdelr1gWY5TFruTKHO4hHCHdi1dtNBfwg+9fpBQp9 clso7Xi6+icWK0J8zdG2Cl2p0Gkz0vGXWiOo+Qc5WVhiA6xp5si5cZsEDJEs++ILk3wy tFxQ== 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-transfer-encoding; bh=f7DNmPU4bt3zNkCM6yp8aCThs94qN+HnXqqLXU3WzGI=; b=eutPAECN7HiJy6Zi1n0l0MrEun+ajMSv03xF7MC/ux1fZnHJLVDzn7AJjip0VZCQZ+ HGKWu8qg6gfNU7+BABvSiryMavnHH77n2BjIkqeyL6mcks2L2BcKlN2bAgiqvSuICvoa 0B0eb8SY8y3j2AORbOxhnpe3dR2seXCAJLPkOpDgcWotyyFDHbMmJAPP1EtQOTgXQe4c GBC/+tohLNr+CNo4xS3ecZopkzDwImSAJ117/ahvk71iDezFFG7Cua0ZOUqr3loQSY43 ydSzTe/094R+eMLWgCIRHdYVuNaQnMGGgFBZIrs0hw5hEQGm3Seu8w9g0r0LhCW2zJvM gEgg== X-Gm-Message-State: ALyK8tJNpWH2uMclq2CKyLGUnBEIHJGFeCi2sWpzYy+gXqxGujBz6+XhRD1OLGjkv8DSgKwt3AOXpzrN4CjqHA== X-Received: by 10.31.167.10 with SMTP id q10mr5074715vke.44.1466411772849; Mon, 20 Jun 2016 01:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Mon, 20 Jun 2016 01:35:43 -0700 (PDT) In-Reply-To: <2FCE0E48-C59D-49FF-BDE7-C8E5D0B7540D@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <2FCE0E48-C59D-49FF-BDE7-C8E5D0B7540D@cisco.com> From: Mark Smith Date: Mon, 20 Jun 2016 18:35:43 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 08:36:16 -0000 On 20 June 2016 at 17:35, Pascal Thubert (pthubert) wr= ote: > Hello Fernando; > > Why are you reopening the dispute? > > You know it's an infinite loop and all you get is a delay in the publicat= ion. > > Note the if that group finally work on the right ways of inserting header= s, it will also have to fix. PMTUD. Which is a good idea on its own because= the concept of a (golden?) path to a destination is just unrealistic anywa= y. The proposed text is useful just to point this out. > > Both are out of scope for 2460bis. So is changing the rules by banning wh= at is not banned today. This from text RFC2460 that banned doing it: "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." The one exception being the Hop-by-Hop options header that needs to be the first EH if present. It was also in RFC1883 as quoted. Similar text was also in RFC1710, "Simple Internet Protocol Plus White Paper", with SIPP being what became IPv6. "Most SIPP option headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4 the presence of any options requires the router to examine all options." The proposed text is fair to the original mandate. > > Regards, > > Pascal > >> Le 20 juin 2016 =C3=A0 00:49, Fernando Gont a = =C3=A9crit : >> >>> On 06/19/2016 10:04 PM, Brian E Carpenter wrote: >>> Hi Fernando, >>>> On 19/06/2016 23:58, Fernando Gont wrote: >>>>> On 06/18/2016 11:51 PM, Bob Hinden wrote: >>>>> Hi, >>>>> >>>>> Stefano, Brian, Ole and I have been discussion the =E2=80=9Cheader in= jection=E2=80=9D issue off list and have some text to propose. The text in= -04 is: >>>>> >>>>> Extension headers must never be inserted by any node other than the >>>>> source of the packet. IP Encapsulation must be used to meet any >>>>> requirement for inserting headers, for example, as defined in >>>>> [RFC2473]. >>>>> >>>>> The proposed new text is: >>>>> >>>>> The insertion of Extension Headers by any node other than the sourc= e >>>>> of the packet breaks PMTU-discovery and can result in ICMP error >>>>> messages being sent to the source of the packet that did not insert >>>>> the header. >>>>> >>>>> One approach to allowing a header to be inserted is to encapsulate >>>>> the packet using another IPv6 header and including the additional >>>>> extension header after the first IPv6 header, for example, as defin= ed >>>>> in [RFC2473]. >>>>> >>>>> We think this better describes the issue, and then describes one appr= oach to how to insert headers without breaking PMTUD. >>>>> >>>>> I think this represents a good compromise from both sides of the disc= ussion. >>>> >>>> IMO, the reason for including the original text you quote above was to >>>> remove the ambiguity in the text. The new text fails to respond the >>>> question: is header insertion allowed? >>> >>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. >>> The suggested compromise leaves it ambiguous. >>> >>> According to Merriam-Webster on-line, the first meaning of "compromise"= is >>> "a way of reaching agreement in which each person or group gives up som= ething >>> that was wanted in order to end an argument or dispute" >> >> IMO, publish a spec that we agree and know beforehand that is ambiguos >> is not a good thing. I don't mind if EH-insertion is allowed, or >> explicitly forbidden. But leaving it unspecified is not a good thing. >> >> Besides, the text notes that EH insertion breaks PMTUD... so not sure >> how that is acceptable. And, if you encapsulate (as noted in the updated >> text), you're not really allowing EH insertion -- you're simply >> encapsulating (creating another layer of IPv6). >> >> Cheers, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jun 20 11:15:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED512D625 for ; Mon, 20 Jun 2016 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xOq86hFgJvyW for ; Mon, 20 Jun 2016 11:15:33 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EB912D0A9 for ; Mon, 20 Jun 2016 11:15:33 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id c73so173223669qkg.2 for ; Mon, 20 Jun 2016 11:15:33 -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:from:date:message-id :subject:to:cc; bh=KY+9pojorQfHjRuXTcB/5h4I4lylMERYg7d8YwzdpkM=; b=kQ7EZ7hLvHe3YZK/Zk0hAhTh+deywDxUvd4TF6tc35JnMz6MsRPr0580KoTrZdYNWY dqRwIeBuNrdGInC2BvQUDrYb5WM0jaqswaQGhzHFDSygEKGJmI9GUI7K4QxAhSxCu9Wi Z0wtSOcYSQK7O6r8T2qFnCNEysm+gOpFNhDmoymF484k4yvK3RV7/7nRfsG0tcz6MCAN mH8OknZwiWC50isUisqzzJjxou/byGLIPPe6tpp0A8BfHZu2bHh8PixO2Aj+98peCInn y1JQNpE69ufAPTD024YhLekO6cLkCFyIMKVQliBB/3ZEvsmbHYb1FDgd/bCUUMlvU+O8 yI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KY+9pojorQfHjRuXTcB/5h4I4lylMERYg7d8YwzdpkM=; b=CJV69ihP+5VY/8xRx+xWO4OR60NTAjU2jxC1ezZcRXcGA5se2MonDyMkfJUne3qC0H FsZ6F2rhZ1sJ3Sp4kGDgFBtStRSxjDAgqY5sQTPlbRTCpp07Kmgkvc1HJUVvSeEe1aKo VCY/c0YNNQ7VnQNsC6yeesG79N/4zUZi+l6GlObWfaMOtlCWG3CTYooVumzOo47e09pQ XzKfneVfQYdTQY/rao0QE5Ql5ibwl1lreMvr9og2g1xkgJGFu9v+GcncEQzbIIdO43Wo 4p1s2bv0+EHdgQGhTq8fcMVkX6pQpfiX293oHDKPC2xZSYhfpVoSWDVaikE4P6+FqCgZ H6iw== X-Gm-Message-State: ALyK8tIidabU1UDptOKe/kWyPCqdIApmHV2b+25zrjchUKOCDhNJPYnwQWt2Wn1VQ6WtEEkWTAReWWvq+f45gw== X-Received: by 10.55.40.150 with SMTP id o22mr23888809qko.195.1466446531161; Mon, 20 Jun 2016 11:15:31 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.166 with HTTP; Mon, 20 Jun 2016 11:15:29 -0700 (PDT) In-Reply-To: <57671C97.1040409@si6networks.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 20 Jun 2016 11:15:29 -0700 X-Google-Sender-Auth: a9e9oyBmgSPu6SiBsbyl_bDmqHI Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:15:35 -0000 At Mon, 20 Jun 2016 00:28:39 +0200, Fernando Gont wrote: > >> IMO, the reason for including the original text you quote above was to > >> remove the ambiguity in the text. The new text fails to respond the > >> question: is header insertion allowed? > > > > You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. > > The suggested compromise leaves it ambiguous. > > > > According to Merriam-Webster on-line, the first meaning of "compromise" is > > "a way of reaching agreement in which each person or group gives up something > > that was wanted in order to end an argument or dispute" > > IMO, publish a spec that we agree and know beforehand that is ambiguos > is not a good thing. I don't mind if EH-insertion is allowed, or > explicitly forbidden. But leaving it unspecified is not a good thing. I agree with Fernando here. In my understanding, while the RFC2460 text was certainly ambiguous and some people actually interpreted it as it allowed EH-insertion (or deletion for that matter), it's never been the intent of the original authors or most of the wg members. We also know there are interoperability issues that can happen due to the insertion/deletion. Also in my understanding, although we have some level of sense that we might revisit the original intent so we can make it a bit more flexible under some specific conditions, we don't know precisely in which condition we can allow the insertion/deletion of EHs. Given these situations, leaving the original text ambiguous can lead to more careless attempts of allowing the insertion/deletion without thinking about the implication. The more we have such attempts and deployments, the more it will be difficult to fix the harm they cause. That's the main reason why I believe we should remove the ambiguity at this opportunity. Now, I'm not sure what kind of compromise was considered necessary (to me the "compromise" and the revised text somehow suddenly emerged - maybe I missed some intermediate discussions and consensus?), but if it's to address the concern that the previously proposed text: Extension headers must never be inserted by any node other than the source of the packet. could invalidate the currently developed attempts of allowing the insertion/deletion of EHs, I believe the right compromise is to still eliminate the ambiguity about the original intent but to note this may be loosened in future developments. Such a compromise could read like this: In the original design of IPv6 extension headers at the time RFC2460, extension headers are not supposed to be inserted (or deleted for that matter) by any node other than the source of the packet. [Related issues with the insertion/deletion such as PMTUD may be inserted here] But some recently developed attempts have sought to loosen the restriction under some particular set of conditions. A future update to the protocol may allow such flexible behavior. But, until the conditions that allow it are figured out, it is prudent for newer protocols to assume the originally intended restrictions. -- JINMEI, Tatuya From nobody Mon Jun 20 11:33:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A4C12D62A; Mon, 20 Jun 2016 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 rMrCDx13ACvR; Mon, 20 Jun 2016 11:33:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4DE12D15A; Mon, 20 Jun 2016 11:33:27 -0700 (PDT) Received: from localhost ([::1]:56257 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bF40k-0000FC-NC; Mon, 20 Jun 2016 11:33:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Mon, 20 Jun 2016 18:33:26 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #14 (rfc4291bis): Reference to default-iid X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/14 Message-ID: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc4291bis@ietf.org Resent-Message-Id: <20160620183330.DE4DE12D15A@ietfa.amsl.com> Resent-Date: Mon, 20 Jun 2016 11:33:27 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:33:32 -0000 #14: Reference to default-iid However, I believe that we need to get draft-ietf-6man-default-iids to the IESG at the same time. Having it referenced as a draft in 4291bis is inappropriate, even though it's informational. If that isn't possible, I think the reference should be removed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc4291bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc4291bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Mon Jun 20 11:34:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A86112D65E for ; Mon, 20 Jun 2016 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 vpVrj9xAxaPo for ; Mon, 20 Jun 2016 11:34:38 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41C112D63C for ; Mon, 20 Jun 2016 11:34:37 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 18:34:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BBE5B9CC4F; Mon, 20 Jun 2016 11:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=58AYMpKdP80avTyrYm42EexhJy8=; b= dfJFrF215lzFzKJ5VndX+OJlf/TN7HzGZrTMf5ySGrY4rKAXAQnhYfxTerVg9n+w tZ/ATqbooGzKNZKFv4FgTMigzAEkA1k32EZTPHeVC8WJRA7mJdGb6nJmrt5IU4ha podlzU3UUAuTSNL4DYg04emTBT37BYb3XHaqxrGCgtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=owDeMFJ2c4J/BUuDiSC3FLPHby zQ5jPh1Xebx37ckpPPc3hCzJ8DP1yVsLnmdkHN1Oz+Z4BDrGAoO1ibNgEPqggnaB vuX013CRLeLsxn6SBS9MhnmiY6Gl0KwW+vpPubD52U6Ufc9i2oErp3H0avmsZP6C 9FgkfA4gZGHGwC5Jo= Received: from h.hanazo.no (unknown [62.214.2.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 403AB9CC4E; Mon, 20 Jun 2016 11:34:35 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 51C082087439; Mon, 20 Jun 2016 20:34:33 +0200 (CEST) Subject: Re: 6MAN: Working group last call on RFC2460bis, RFC1981bis and RFC4291bis Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FC16B212-65DF-4DB4-8091-916B9BEAF00F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Mon, 20 Jun 2016 20:34:30 +0200 Message-Id: <6CBE1844-6136-4F0A-BBAE-E72F26823A01@employees.org> References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:34:39 -0000 --Apple-Mail=_FC16B212-65DF-4DB4-8091-916B9BEAF00F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks a lot Brian. I have added the reference to default-iid issue to the tracker. The current list is here: https://trac.tools.ietf.org/wg/6man/trac/report/1 Let me know if you think there are other outstanding issues that I = missed. Best regards, Ole > On 16 Jun 2016, at 01:01, Brian E Carpenter = wrote: >=20 > Hi, >=20 > On 30/05/2016 20:15, otroan@employees.org wrote: >> This message starts a two week 6MAN Working Group Last Call on = advancing: >=20 > Slightly late, here are my comments after re-reading these drafts. > I have systematically reviewed the changes in each version since > this exercise started. Most of my issues have been dealt with in > previous versions, so I don't have much new to say. >=20 > One general comment: the authors have chosen to avoid upper case > normative keywords. I understand this choice, but I expect it will be > brought up at IETF Last Call or IESG review by somebody. It will be > worth justifying this choice in the writeup, I think. >=20 > ... >> Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-04 >=20 > I'm happy with this version. I think it expresses the parts of RFC2460 = that > have been confirmed to be interoperable by years of running code. = There are > still some subtle changes being discussed around extension header = insertion and > HbH option processing, however. I think we are very close to consensus = now, > but one more release of the I-D is needed for those points. >=20 > ... >> Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-02 >=20 > I'm happy with this version. I think that the reference to PLPMTUD is > correctly formulated for use in an Internet Standard. >=20 > ... >> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02 >=20 > I'm happy with this version. I think it correctly treads a narrow line = about > IIDs in a way that is suitable for an Internet Standard. >=20 > (I have raised a definitional issue about 'global' scope, but I don't > think the text in 4291bis needs changing because of this.) >=20 > However, I believe that we need to get draft-ietf-6man-default-iids > to the IESG at the same time. Having it referenced as a draft in = 4291bis > is inappropriate, even though it's informational. If that isn't = possible, > I think the reference should be removed. >=20 >> as Internet Standards. Substantive comments and statements of support >> for publishing these document should be directed to the mailing >> list. >=20 > So, consider this a statement of support once the minor points = mentioned > above have been resolved. >=20 > Regards > Brian Carpenter --Apple-Mail=_FC16B212-65DF-4DB4-8091-916B9BEAF00F 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 iQEcBAEBCgAGBQJXaDc5AAoJED4aXnjSQuKWZXAH/jqbMDmmwB9EfLy8ogsAx13V cmN8yI4VjRdit6flzP3cKf8Cp5aDBH6ZgTV1p6AVlHQ6qcdUo4w9Rgte8nYocPov sTofnlNn0Tt2EGhLCKLOZEKnuk2RM3Iro3NZGIg56Kekvu+rvbzDb6xkXB3HlbGl J5NgTbdBCdJTnxKT0/ggqgOyzerRClX6kFH8BBv9GmkEbawtRVYbGRr+lhbhrMf3 oh3H8rVF6uLLUwoaL2mAnOTcDGBgp32upQW58PkeejzFETn1xGr5qkgQM87p9eYj 3aF+3yP6TVjUg9xF98pFcCk/IfxlXoNQTmQmuEgzX+SjYBmqHoRQt8U/mn3bjOU= =0pTH -----END PGP SIGNATURE----- --Apple-Mail=_FC16B212-65DF-4DB4-8091-916B9BEAF00F-- From nobody Mon Jun 20 18:48:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9311712DAF5 for ; Mon, 20 Jun 2016 18:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PD9i8d-bF5-d for ; Mon, 20 Jun 2016 18:48:01 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F3012D878 for ; Mon, 20 Jun 2016 18:47:55 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u64so2362031vkf.3 for ; Mon, 20 Jun 2016 18:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q3QKtQytZwqkWOgWsT00TrVdM2wNG6M8mc403NgOEKo=; b=OYPiYXjPv4G4bP+hEPR5dAzmW21EJ3SFILAPEupC+Y7EXVHo72O40yY2VYF9q3L5Hj V4zhC1f53WnfelBblPReBR/op4EMqIqqJLiGVX2weZW13B9AU74glsmqllokOqTdS37T qLqkaFlzkQalE5AkJl69SqhQfjVzD4d18q7WKYyqPDQ0MApT6iT3Berts2VAj9UIsDcc OmWO0Cw+4IvQX+99To2T24tSzmY587y+N88VhyWRYDbqcoJiZsdS2H3os7w3GqHag4+k qqvxklUH2+UOo+iCopzz3wZfxVbJUOu+NwHu7nVvvDA7hm7/sMI8lz8WXAn/iIitzFYx n0Cg== 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-transfer-encoding; bh=q3QKtQytZwqkWOgWsT00TrVdM2wNG6M8mc403NgOEKo=; b=h03lWk2CAcVdlxWl8XOgJSJLLHnxc23wrWAQ7oWIQ2QRUWbmHdiPfhKP85kewSTLnn +uiYtdZxTVAfODmse4N1Fz063Uj3HNZZ2qdaywcrTN6X1OOHdcmOV5tVZEEDvxC7/Y0D Hw2KrPUAytfeoEG5eqNJ/FYwnlpquZzTQVVFNT6KrCJFQ3fLCGKejoSt6K0x70683i2Q zKgXMpQY6ICdrfyYLFExWpjDLBvqeLnEFHlNckXDrkdl+GLF0XnY8rfYzJpX1wHAoW3n UFeNZMxxWaxwP0Jf35f6zrJKJrY5zxpPtMk6xetBJmbC5viTWT6Ic53111QLFR3aDFeC 7mvw== X-Gm-Message-State: ALyK8tKvSlJf1jFeS+425yY9Tim5Vr//05KMrzfaBRUhyGgU5qPyR/4wuWc///rszqqZVCIHQ3mqTuyIkhW6eA== X-Received: by 10.31.232.67 with SMTP id f64mr989761vkh.44.1466473674451; Mon, 20 Jun 2016 18:47:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Mon, 20 Jun 2016 18:47:24 -0700 (PDT) In-Reply-To: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: Mark Smith Date: Tue, 21 Jun 2016 11:47:24 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 01:48:04 -0000 On 21 June 2016 at 04:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 20 Jun 2016 00:28:39 +0200, > Fernando Gont wrote: > >> >> IMO, the reason for including the original text you quote above was t= o >> >> remove the ambiguity in the text. The new text fails to respond the >> >> question: is header insertion allowed? >> > >> > You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too= . >> > The suggested compromise leaves it ambiguous. >> > >> > According to Merriam-Webster on-line, the first meaning of "compromise= " is >> > "a way of reaching agreement in which each person or group gives up so= mething >> > that was wanted in order to end an argument or dispute" >> >> IMO, publish a spec that we agree and know beforehand that is ambiguos >> is not a good thing. I don't mind if EH-insertion is allowed, or >> explicitly forbidden. But leaving it unspecified is not a good thing. > > I agree with Fernando here. > > In my understanding, while the RFC2460 text was certainly ambiguous I don't find the RFC2460 text ambiguous. I think "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." is clear. I don't think it is possible to insert an EH into a packet without looking at (examining) the existing EHs and moving (processing) the existing EHs to insert the EH. (I think the only way you could "insert" an EH into a packet without examining or processing the existing EHs is to blindly write an EH directly after the IPv6 fixed header, regardless of what already exists there. Of course, what ever was in that position originally was probably pretty important to the sending and receiving hosts.) > and > some people actually interpreted it as it allowed EH-insertion (or > deletion for that matter), it's never been the intent of the original > authors or most of the wg members. We also know there are > interoperability issues that can happen due to the insertion/deletion. > Such a compromise could read like > this: > > In the original design of IPv6 extension headers at the time > RFC2460, extension headers are not supposed to be inserted (or > deleted for that matter) by any node other than the source of the > packet. [Related issues with the insertion/deletion such as PMTUD > may be inserted here] But some recently developed attempts have > sought to loosen the restriction under some particular set of > conditions. A future update to the protocol may allow such > flexible behavior. But, until the conditions that allow it are > figured out, it is prudent for newer protocols to assume the > originally intended restrictions. > I think this is pretty good text as an alternative or as a compliment to what I suggested the other day. I would suggest changing the last sentence to something like: "However, until the conditions that allow it are determined, newer protocols should assume the originally intended restrictions." Regards, Mark. From nobody Tue Jun 21 01:27:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C070712B050 for ; Tue, 21 Jun 2016 01:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 K8gTQ4UjOr4t for ; Tue, 21 Jun 2016 01:27:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90AA12D0E6 for ; Tue, 21 Jun 2016 01:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5370; q=dns/txt; s=iport; t=1466497633; x=1467707233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y5Q3GPvEINetBQakm4F0XSbCbGndU3hiUJF8zQnS6lw=; b=lV1tolAka+Gf2HYzDmyJzzGllVdi6wHcEw91zwuZFXJSo0B4g7WInHzM n+nqmMA+/YUTO9njSnsfo31ob2GfbNgBriXYuVRSMlYY2vFEbJB9vubNw LjdXmQ8FKgwA+nEBdLvYGMW1hirGoMaPl2/ykwnhFR2k7qwc/uhyRdxRk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6BQB7+WhX/4QNJK1dgz5WLk8Grm+MA?= =?us-ascii?q?oF6FwuFdQIcgRY6EgEBAQEBAQFlJ4RLAQEBAwEBAQEgEToLBQsCAQYCGAICJgI?= =?us-ascii?q?CAh8GCxUQAgQOBYgWAw8IDpMbnR2MVQ2DeAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RcFgQGFJoF3CIJOgTkBgQmBTSAQF4JqK4IvBYgSkDM0AYh/gzKBeoFpiACFOoZ?= =?us-ascii?q?RgTqHbAElCSaCFYFbbokERX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,502,1459814400"; d="scan'208";a="287992028" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2016 08:27:12 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5L8RCBA009948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 08:27:12 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 21 Jun 2016 04:27:11 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 21 Jun 2016 04:27:11 -0400 From: "Stefano Previdi (sprevidi)" To: Mark Smith Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRy5a11jTlOfsDB0C3jDSNl1dSDg== Date: Tue, 21 Jun 2016 08:27:11 +0000 Message-ID: <8D4027B1-3223-44C7-BB08-67B76DCBB1F3@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.252.208] Content-Type: text/plain; charset="utf-8" Content-ID: <7039A2DA636165469160E1604EE6D80B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:27:18 -0000 DQo+IE9uIEp1biAyMSwgMjAxNiwgYXQgMzo0NyBBTSwgTWFyayBTbWl0aCA8bWFya3p6enNtaXRo QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAyMSBKdW5lIDIwMTYgYXQgMDQ6MTUsIOelnuaY jumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+IHdyb3RlOg0KPj4gQXQgTW9uLCAyMCBKdW4gMjAx NiAwMDoyODozOSArMDIwMCwNCj4+IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNv bT4gd3JvdGU6DQo+PiANCj4+Pj4+IElNTywgdGhlIHJlYXNvbiBmb3IgaW5jbHVkaW5nIHRoZSBv cmlnaW5hbCB0ZXh0IHlvdSBxdW90ZSBhYm92ZSB3YXMgdG8NCj4+Pj4+IHJlbW92ZSB0aGUgYW1i aWd1aXR5IGluIHRoZSB0ZXh0LiBUaGUgbmV3IHRleHQgZmFpbHMgdG8gcmVzcG9uZCB0aGUNCj4+ Pj4+IHF1ZXN0aW9uOiBpcyBoZWFkZXIgaW5zZXJ0aW9uIGFsbG93ZWQ/DQo+Pj4+IA0KPj4+PiBZ b3UncmUgY29ycmVjdC4gUkZDIDI0NjAgYW5kIFJGQyAxODgzIHdlcmUgYW1iaWd1b3VzIG9uIHRo aXMgcG9pbnQgdG9vLg0KPj4+PiBUaGUgc3VnZ2VzdGVkIGNvbXByb21pc2UgbGVhdmVzIGl0IGFt YmlndW91cy4NCj4+Pj4gDQo+Pj4+IEFjY29yZGluZyB0byBNZXJyaWFtLVdlYnN0ZXIgb24tbGlu ZSwgdGhlIGZpcnN0IG1lYW5pbmcgb2YgImNvbXByb21pc2UiIGlzDQo+Pj4+ICJhIHdheSBvZiBy ZWFjaGluZyBhZ3JlZW1lbnQgaW4gd2hpY2ggZWFjaCBwZXJzb24gb3IgZ3JvdXAgZ2l2ZXMgdXAg c29tZXRoaW5nDQo+Pj4+IHRoYXQgd2FzIHdhbnRlZCBpbiBvcmRlciB0byBlbmQgYW4gYXJndW1l bnQgb3IgZGlzcHV0ZSINCj4+PiANCj4+PiBJTU8sIHB1Ymxpc2ggYSBzcGVjIHRoYXQgd2UgYWdy ZWUgYW5kIGtub3cgYmVmb3JlaGFuZCB0aGF0IGlzIGFtYmlndW9zDQo+Pj4gaXMgbm90IGEgZ29v ZCB0aGluZy4gSSBkb24ndCBtaW5kIGlmIEVILWluc2VydGlvbiBpcyBhbGxvd2VkLCBvcg0KPj4+ IGV4cGxpY2l0bHkgZm9yYmlkZGVuLiBCdXQgbGVhdmluZyBpdCB1bnNwZWNpZmllZCBpcyBub3Qg YSBnb29kIHRoaW5nLg0KPj4gDQo+PiBJIGFncmVlIHdpdGggRmVybmFuZG8gaGVyZS4NCj4+IA0K Pj4gSW4gbXkgdW5kZXJzdGFuZGluZywgd2hpbGUgdGhlIFJGQzI0NjAgdGV4dCB3YXMgY2VydGFp bmx5IGFtYmlndW91cw0KPiANCj4gSSBkb24ndCBmaW5kIHRoZSBSRkMyNDYwIHRleHQgYW1iaWd1 b3VzLiBJIHRoaW5rDQo+IA0KPiAiV2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVy cyBhcmUgbm90IGV4YW1pbmVkIG9yIHByb2Nlc3NlZA0KPiAgIGJ5IGFueSBub2RlIGFsb25nIGEg cGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzDQo+ICAgdGhl IG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4gdGhlIGNhc2Ugb2YgbXVsdGlj YXN0KQ0KPiAgIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2Yg dGhlIElQdjYgaGVhZGVyLiINCj4gDQo+IGlzIGNsZWFyLg0KDQoNCmlmIHlvdSB0aGluayB0aGF0 IHJmYzI0NjAgaXMgY2xlYXIgYW5kIHVuYW1iaWd1b3VzLCB0aGVuIEkgZG9u4oCZdCBzZWUgd2h5 IHdlIHNob3VsZCB0cnkgdG8gYW1lbmQgaXQuDQoNCkFueXdheSwgd2l0aG91dCBjb25zZW5zdXMg b24gYW55IG5ldyB0ZXh0LCBpdOKAmXMgdGhlIGRpcmVjdGlvbiB3ZeKAmWxsIGhhdmUgdG8gdGFr ZS4NCg0Kcy4NCg0KDQo+IEkgZG9uJ3QgdGhpbmsgaXQgaXMgcG9zc2libGUgdG8gaW5zZXJ0IGFu IEVIIGludG8gYSBwYWNrZXQgd2l0aG91dA0KPiBsb29raW5nIGF0IChleGFtaW5pbmcpIHRoZSBl eGlzdGluZyBFSHMgYW5kIG1vdmluZyAocHJvY2Vzc2luZykgdGhlDQo+IGV4aXN0aW5nIEVIcyB0 byBpbnNlcnQgdGhlIEVILg0KPiANCj4gKEkgdGhpbmsgdGhlIG9ubHkgd2F5IHlvdSBjb3VsZCAi aW5zZXJ0IiBhbiBFSCBpbnRvIGEgcGFja2V0IHdpdGhvdXQNCj4gZXhhbWluaW5nIG9yIHByb2Nl c3NpbmcgdGhlIGV4aXN0aW5nIEVIcyBpcyB0byBibGluZGx5IHdyaXRlIGFuIEVIDQo+IGRpcmVj dGx5IGFmdGVyIHRoZSBJUHY2IGZpeGVkIGhlYWRlciwgcmVnYXJkbGVzcyBvZiB3aGF0IGFscmVh ZHkNCj4gZXhpc3RzIHRoZXJlLiBPZiBjb3Vyc2UsIHdoYXQgZXZlciB3YXMgaW4gdGhhdCBwb3Np dGlvbiBvcmlnaW5hbGx5IHdhcw0KPiBwcm9iYWJseSBwcmV0dHkgaW1wb3J0YW50IHRvIHRoZSBz ZW5kaW5nIGFuZCByZWNlaXZpbmcgaG9zdHMuKQ0KPiANCj4+IGFuZA0KPj4gc29tZSBwZW9wbGUg YWN0dWFsbHkgaW50ZXJwcmV0ZWQgaXQgYXMgaXQgYWxsb3dlZCBFSC1pbnNlcnRpb24gKG9yDQo+ PiBkZWxldGlvbiBmb3IgdGhhdCBtYXR0ZXIpLCBpdCdzIG5ldmVyIGJlZW4gdGhlIGludGVudCBv ZiB0aGUgb3JpZ2luYWwNCj4+IGF1dGhvcnMgb3IgbW9zdCBvZiB0aGUgd2cgbWVtYmVycy4gIFdl IGFsc28ga25vdyB0aGVyZSBhcmUNCj4+IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHRoYXQgY2Fu IGhhcHBlbiBkdWUgdG8gdGhlIGluc2VydGlvbi9kZWxldGlvbi4NCj4+IA0KPiANCj4gPHNuaXA+ DQo+IA0KPiAgU3VjaCBhIGNvbXByb21pc2UgY291bGQgcmVhZCBsaWtlDQo+PiB0aGlzOg0KPj4g DQo+PiAgIEluIHRoZSBvcmlnaW5hbCBkZXNpZ24gb2YgSVB2NiBleHRlbnNpb24gaGVhZGVycyBh dCB0aGUgdGltZQ0KPj4gICBSRkMyNDYwLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IHN1cHBv c2VkIHRvIGJlIGluc2VydGVkIChvcg0KPj4gICBkZWxldGVkIGZvciB0aGF0IG1hdHRlcikgYnkg YW55IG5vZGUgb3RoZXIgdGhhbiB0aGUgc291cmNlIG9mIHRoZQ0KPj4gICBwYWNrZXQuICBbUmVs YXRlZCBpc3N1ZXMgd2l0aCB0aGUgaW5zZXJ0aW9uL2RlbGV0aW9uIHN1Y2ggYXMgUE1UVUQNCj4+ ICAgbWF5IGJlIGluc2VydGVkIGhlcmVdICBCdXQgc29tZSByZWNlbnRseSBkZXZlbG9wZWQgYXR0 ZW1wdHMgaGF2ZQ0KPj4gICBzb3VnaHQgdG8gbG9vc2VuIHRoZSByZXN0cmljdGlvbiB1bmRlciBz b21lIHBhcnRpY3VsYXIgc2V0IG9mDQo+PiAgIGNvbmRpdGlvbnMuICBBIGZ1dHVyZSB1cGRhdGUg dG8gdGhlIHByb3RvY29sIG1heSBhbGxvdyBzdWNoDQo+PiAgIGZsZXhpYmxlIGJlaGF2aW9yLiAg QnV0LCB1bnRpbCB0aGUgY29uZGl0aW9ucyB0aGF0IGFsbG93IGl0IGFyZQ0KPj4gICBmaWd1cmVk IG91dCwgaXQgaXMgcHJ1ZGVudCBmb3IgbmV3ZXIgcHJvdG9jb2xzIHRvIGFzc3VtZSB0aGUNCj4+ ICAgb3JpZ2luYWxseSBpbnRlbmRlZCByZXN0cmljdGlvbnMuDQo+PiANCj4gDQo+IEkgdGhpbmsg dGhpcyBpcyBwcmV0dHkgZ29vZCB0ZXh0IGFzIGFuIGFsdGVybmF0aXZlIG9yIGFzIGEgY29tcGxp bWVudA0KPiB0byB3aGF0IEkgc3VnZ2VzdGVkIHRoZSBvdGhlciBkYXkuDQo+IA0KPiBJIHdvdWxk IHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGxhc3Qgc2VudGVuY2UgdG8gc29tZXRoaW5nIGxpa2U6DQo+ IA0KPiAiSG93ZXZlciwgdW50aWwgdGhlIGNvbmRpdGlvbnMgdGhhdCBhbGxvdyBpdCBhcmUgZGV0 ZXJtaW5lZCwgbmV3ZXINCj4gcHJvdG9jb2xzIHNob3VsZCBhc3N1bWUgdGhlIG9yaWdpbmFsbHkg aW50ZW5kZWQgcmVzdHJpY3Rpb25zLiINCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Tue Jun 21 03:24:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A018412B017 for ; Tue, 21 Jun 2016 03:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tO3SG6BcBDqH for ; Tue, 21 Jun 2016 03:24:18 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE1B1200A0 for ; Tue, 21 Jun 2016 03:24:18 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j2so14297955vkg.2 for ; Tue, 21 Jun 2016 03:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tgTWvELjqcrDuBdDwp3tVEMsZJ6zHGvqDj25J8xtLDc=; b=rtgfgCH4nJyUhj9N0Swy2IjJI5PnE8Myd8NUxQWnsIodLGz5Xxox8xSygrGF8LxPn+ V7ygUmZHZKQTyAyRpeJ2jO0R5PI2ZjSj0D4IcPzxbZeZhY5MSBEvKgV0sQlpAWJ1JDoM +oqVTtAXlFkRbtqm0ElnqP7CTNdXUjC5UXLAm4TaljeTOgcn8tLA9blYjYPmtia9FPCi aO4H72hLsT+AETFPz5J/VdqJUsQPCgwQPOE0ldlMw0lRWuS30vVAZy5WxEgIZBLBpsUO 2yxn5SEBrzY5K+DncXNLK0e3fZC1poHmlWheacCSogTnQvFw1CP/oUQ5xfpe2ONvaR/p 41QA== 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-transfer-encoding; bh=tgTWvELjqcrDuBdDwp3tVEMsZJ6zHGvqDj25J8xtLDc=; b=RrjhFO74DTnNZV/PO3UAz3sdgIQv2GOhUXGs6KuoIKO0NZOnS29oNZcaStO2T5Nx1R A5Oy7d9Iu/H3ucfHSjWPKNK9ajF6ck/EeDd/Cp18EyyTPu4PTSDq2KaI4wjw4Y7BW5ym ODTVq3m6xAz2J+Kr9iEn5I2CffNZUDp/i8bSvW/QjrcrPbrIQ6wx0XGLyYZfcLI+gMH5 8GeSqpCG+yOJlHn0zG90bBgSPocu5ioFmd2YfjDqcD1/fkaR6TlCnNSvnOrz+JB48CEl xdAtKuu1WXaAgiWO2vAYEXs+vnO0lMr8kzTAw+FFGmYaC2ZihCaAS8LKyxR5sVTEi/1Y 9HmA== X-Gm-Message-State: ALyK8tIombSh5Lk4n90pprs+6YzNVhQFfGHtutDjZCR92tSKW0MJZ0CuoMhVbJ93rkYQcsMtPr5gozuzFFTAZQ== X-Received: by 10.159.37.9 with SMTP id 9mr7119921uaz.25.1466504656998; Tue, 21 Jun 2016 03:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Tue, 21 Jun 2016 03:23:47 -0700 (PDT) In-Reply-To: <8D4027B1-3223-44C7-BB08-67B76DCBB1F3@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <8D4027B1-3223-44C7-BB08-67B76DCBB1F3@cisco.com> From: Mark Smith Date: Tue, 21 Jun 2016 20:23:47 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Stefano Previdi (sprevidi)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:24:19 -0000 On 21 June 2016 at 18:27, Stefano Previdi (sprevidi) w= rote: > >> On Jun 21, 2016, at 3:47 AM, Mark Smith wrote: >> >> On 21 June 2016 at 04:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> At Mon, 20 Jun 2016 00:28:39 +0200, >>> Fernando Gont wrote: >>> >>>>>> IMO, the reason for including the original text you quote above was = to >>>>>> remove the ambiguity in the text. The new text fails to respond the >>>>>> question: is header insertion allowed? >>>>> >>>>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point to= o. >>>>> The suggested compromise leaves it ambiguous. >>>>> >>>>> According to Merriam-Webster on-line, the first meaning of "compromis= e" is >>>>> "a way of reaching agreement in which each person or group gives up s= omething >>>>> that was wanted in order to end an argument or dispute" >>>> >>>> IMO, publish a spec that we agree and know beforehand that is ambiguos >>>> is not a good thing. I don't mind if EH-insertion is allowed, or >>>> explicitly forbidden. But leaving it unspecified is not a good thing. >>> >>> I agree with Fernando here. >>> >>> In my understanding, while the RFC2460 text was certainly ambiguous >> >> I don't find the RFC2460 text ambiguous. I think >> >> "With one exception, extension headers are not examined or processed >> by any node along a packet's delivery path, until the packet reaches >> the node (or each of the set of nodes, in the case of multicast) >> identified in the Destination Address field of the IPv6 header." >> >> is clear. > > > if you think that rfc2460 is clear and unambiguous, then I don=E2=80=99t = see why we should try to amend it. > I'm fine with what it says. Apparently it has been misunderstood, so being more definitive can only make it clearer. Regards, Mark. > Anyway, without consensus on any new text, it=E2=80=99s the direction we= =E2=80=99ll have to take. > > s. > > From nobody Tue Jun 21 03:45:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7550612D17E for ; Tue, 21 Jun 2016 03:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8BljOZ3Ua48b for ; Tue, 21 Jun 2016 03:45:18 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2162E126D74 for ; Tue, 21 Jun 2016 03:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3724; q=dns/txt; s=iport; t=1466505918; x=1467715518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/KikPTm6DWdtrIPaJdzD7l8GqEcUzSBfKtXycaiPHXc=; b=GRozYaD427EJw8fFWKroRDUJdQoIwxu2fGfWkWQA4BQvKDjLdheuH2bJ OFa+EPwm8UsMtV7v/9fVlLefNCjWJSyhn4AVmyKTBW5wMy3monZjNhjYG M6/h6PZSQ1ldxwYZE9xy63sWDaZ5uFON1hm1DbKZHX934m74kWKM/d/RL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgBDGmlX/5FdJa1dgz6BUwaub4wCg?= =?us-ascii?q?XqGFwIcgRY4FAEBAQEBAQFlJ4RLAQEBAwEjEUUFCwIBBgIYAgImAgICHxEVEAI?= =?us-ascii?q?EDgWIFgMPCJNBnR2MVg2DeAEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUmgXcIg?= =?us-ascii?q?k6BOQGBCYFtEBeCaiuCLwEEmEU0AYh/gzKBeo8jiAuHbAEeNoIVgVtuiUl/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.26,503,1459814400"; d="scan'208";a="287436518" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 10:45:17 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5LAjG11005448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 10:45:17 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 21 Jun 2016 06:45:15 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 21 Jun 2016 06:45:15 -0400 From: "Stefano Previdi (sprevidi)" To: Mark Smith Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRy6n/HZnQCzqiCkm0p4SPc0kr3w== Date: Tue, 21 Jun 2016 10:45:15 +0000 Message-ID: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <8D4027B1-3223-44C7-BB08-67B76DCBB1F3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.252.208] Content-Type: text/plain; charset="utf-8" Content-ID: <060A1C67B8A85440BC80126B1ADE4473@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:45:19 -0000 DQo+IE9uIEp1biAyMSwgMjAxNiwgYXQgMTI6MjMgUE0sIE1hcmsgU21pdGggPG1hcmt6enpzbWl0 aEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMjEgSnVuZSAyMDE2IGF0IDE4OjI3LCBTdGVm YW5vIFByZXZpZGkgKHNwcmV2aWRpKSA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCj4+IA0K Pj4+IE9uIEp1biAyMSwgMjAxNiwgYXQgMzo0NyBBTSwgTWFyayBTbWl0aCA8bWFya3p6enNtaXRo QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gT24gMjEgSnVuZSAyMDE2IGF0IDA0OjE1LCDn pZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPiB3cm90ZToNCj4+Pj4gQXQgTW9uLCAyMCBK dW4gMjAxNiAwMDoyODozOSArMDIwMCwNCj4+Pj4gRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0 d29ya3MuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+Pj4+IElNTywgdGhlIHJlYXNvbiBmb3IgaW5j bHVkaW5nIHRoZSBvcmlnaW5hbCB0ZXh0IHlvdSBxdW90ZSBhYm92ZSB3YXMgdG8NCj4+Pj4+Pj4g cmVtb3ZlIHRoZSBhbWJpZ3VpdHkgaW4gdGhlIHRleHQuIFRoZSBuZXcgdGV4dCBmYWlscyB0byBy ZXNwb25kIHRoZQ0KPj4+Pj4+PiBxdWVzdGlvbjogaXMgaGVhZGVyIGluc2VydGlvbiBhbGxvd2Vk Pw0KPj4+Pj4+IA0KPj4+Pj4+IFlvdSdyZSBjb3JyZWN0LiBSRkMgMjQ2MCBhbmQgUkZDIDE4ODMg d2VyZSBhbWJpZ3VvdXMgb24gdGhpcyBwb2ludCB0b28uDQo+Pj4+Pj4gVGhlIHN1Z2dlc3RlZCBj b21wcm9taXNlIGxlYXZlcyBpdCBhbWJpZ3VvdXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWNjb3JkaW5n IHRvIE1lcnJpYW0tV2Vic3RlciBvbi1saW5lLCB0aGUgZmlyc3QgbWVhbmluZyBvZiAiY29tcHJv bWlzZSIgaXMNCj4+Pj4+PiAiYSB3YXkgb2YgcmVhY2hpbmcgYWdyZWVtZW50IGluIHdoaWNoIGVh Y2ggcGVyc29uIG9yIGdyb3VwIGdpdmVzIHVwIHNvbWV0aGluZw0KPj4+Pj4+IHRoYXQgd2FzIHdh bnRlZCBpbiBvcmRlciB0byBlbmQgYW4gYXJndW1lbnQgb3IgZGlzcHV0ZSINCj4+Pj4+IA0KPj4+ Pj4gSU1PLCBwdWJsaXNoIGEgc3BlYyB0aGF0IHdlIGFncmVlIGFuZCBrbm93IGJlZm9yZWhhbmQg dGhhdCBpcyBhbWJpZ3Vvcw0KPj4+Pj4gaXMgbm90IGEgZ29vZCB0aGluZy4gSSBkb24ndCBtaW5k IGlmIEVILWluc2VydGlvbiBpcyBhbGxvd2VkLCBvcg0KPj4+Pj4gZXhwbGljaXRseSBmb3JiaWRk ZW4uIEJ1dCBsZWF2aW5nIGl0IHVuc3BlY2lmaWVkIGlzIG5vdCBhIGdvb2QgdGhpbmcuDQo+Pj4+ IA0KPj4+PiBJIGFncmVlIHdpdGggRmVybmFuZG8gaGVyZS4NCj4+Pj4gDQo+Pj4+IEluIG15IHVu ZGVyc3RhbmRpbmcsIHdoaWxlIHRoZSBSRkMyNDYwIHRleHQgd2FzIGNlcnRhaW5seSBhbWJpZ3Vv dXMNCj4+PiANCj4+PiBJIGRvbid0IGZpbmQgdGhlIFJGQzI0NjAgdGV4dCBhbWJpZ3VvdXMuIEkg dGhpbmsNCj4+PiANCj4+PiAiV2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBh cmUgbm90IGV4YW1pbmVkIG9yIHByb2Nlc3NlZA0KPj4+ICBieSBhbnkgbm9kZSBhbG9uZyBhIHBh Y2tldCdzIGRlbGl2ZXJ5IHBhdGgsIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcw0KPj4+ICB0aGUg bm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbiB0aGUgY2FzZSBvZiBtdWx0aWNh c3QpDQo+Pj4gIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2Yg dGhlIElQdjYgaGVhZGVyLiINCj4+PiANCj4+PiBpcyBjbGVhci4NCj4+IA0KPj4gDQo+PiBpZiB5 b3UgdGhpbmsgdGhhdCByZmMyNDYwIGlzIGNsZWFyIGFuZCB1bmFtYmlndW91cywgdGhlbiBJIGRv buKAmXQgc2VlIHdoeSB3ZSBzaG91bGQgdHJ5IHRvIGFtZW5kIGl0Lg0KPj4gDQo+IA0KPiBJJ20g ZmluZSB3aXRoIHdoYXQgaXQgc2F5cy4NCg0KDQptZXQgdG9vIGFuZCB0aGlzIGlzIHdoYXQgaGFz IGJlZW4gYWxyZWFkeSBwb2ludGVkIG91dCBhIGxpdHRsZSB3aGlsZSBhZ28gKGluIEJ1ZW5vcyBB aXJlcykuDQoNCg0KPiBBcHBhcmVudGx5IGl0IGhhcyBiZWVuIG1pc3VuZGVyc3Rvb2QsIHNvDQo+ IGJlaW5nIG1vcmUgZGVmaW5pdGl2ZSBjYW4gb25seSBtYWtlIGl0IGNsZWFyZXIuDQoNCg0KSXTi gJlzIF9vbmVfIG9mIHRoZSB0d28gb3B0aW9uczoNCg0KMS4geW914oCZcmUgc2F0aXNmaWVkIHdp dGggY3VycmVudCB0ZXh0IG9mIHJmYzI0NjAuIEluIHN1Y2ggY2FzZSwgbm90aGluZyBuZWVkcyB0 byBiZSBjaGFuZ2VkLg0KDQoyLiB5b3XigJlyZSBub3Qgc2F0aXNmaWVkIHdpdGggY3VycmVudCB0 ZXh0IG9mIHJmYzI0NjAuIEkgc3VjaCBjYXNlLCB5b3XigJlkIGxpa2UgdG8gc2VlIHRoZSB0ZXh0 IGFtZW5kZWQvbW9kaWZpZWQgaW4gcmZjMjQ2MGJpcy4NCg0KKDEpIGRvZXMgbm90IHJlcXVpcmUg YW55IGRpc2N1c3Npb24sIGFueSBhY3Rpb24sIHdlIGNhbiBjbG9zZSB0aGUgaXNzdWUuDQooMikg cmVxdWlyZXMgY29uc2Vuc3VzIGJlZm9yZSBwcm9jZWVkaW5nIHdpdGggcHVibGljYXRpb24uDQoN Ckl0IGFwcGVhciB0aGF0ICgyKSBpcyBmYXIgZnJvbSBiZWluZyBpbiByZWFjaC4NCg0Kcy4NCg0K DQo+IA0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiANCj4+IEFueXdheSwgd2l0aG91dCBjb25zZW5z dXMgb24gYW55IG5ldyB0ZXh0LCBpdOKAmXMgdGhlIGRpcmVjdGlvbiB3ZeKAmWxsIGhhdmUgdG8g dGFrZS4NCj4+IA0KPj4gcy4NCj4+IA0KPj4gDQo+IDxzbmlwPg0KDQo= From nobody Tue Jun 21 07:14:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7D012B028 for ; Tue, 21 Jun 2016 07:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 eBxAGPpEqqD3 for ; Tue, 21 Jun 2016 07:14:41 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ABF12B027 for ; Tue, 21 Jun 2016 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oRNZF+Le58UIREgwWrM83mG6WywUtFchrdt3dIbehTc=; b=GCvFGlRA8owjQ7Es1XBozEy/o1J6NhsM8LOWT4Q6PPghAbfrlM67Xd4Ag8kwVzDKOWJarkK6jHJ+8UYAVXCq0opPdZAr9pge0eibIb0ZvcOPAU4UIM1LfS1enIhyyWqyvy7BNA2rX4cDWo/rgoShLQOhm2Qo9frZHYybkh1z9yI= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0216.outbound.protection.outlook.com [213.199.154.216]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-19-a18kOcsgOo6fUNHOvfArMA-1; Tue, 21 Jun 2016 15:14:32 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (TLS) id 15.1.506.9; Tue, 21 Jun 2016 14:14:31 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0501.018; Tue, 21 Jun 2016 14:14:30 +0000 From: Tim Chown To: Mark Smith Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRyaupclhw6MFl5ESF47Z5gQnrXp/wsGwAgACH1QCAAChCgIABS5mAgAB+QwCAANEbgA== Date: Tue, 21 Jun 2016 14:14:30 +0000 Message-ID: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:8cba:4f87:8598:dc5d] x-ms-office365-filtering-correlation-id: 6e0ba998-dca6-4f58-0b9d-08d399de5ce0 x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 5:aFI5GV2npzhpCzDQ2vcL5tgVxi8H4m2/Zh67l6cvqokOtvNhuA9XLFz6fR7nanGtOWop6YVsJWXXinwsWOqm9EDuF1li0ZDXJ+RtqNPcZ8fEPduSp51JXRGymlutZGz0HkDOl6uVskWniNCoOrCYXw==; 24:M8YOMPFQNoqEYMifuLMPRrg7BYEDDg0WNKckPqNQx7JZKBlbZfRdcraFsyU7oUmiM6CTgW/U0WPfbvQJ2aL9SEXhnvDsLdzTPHph/j82x+k=; 7:uGBgTR8gIMDKuU9XzJFcQVAo9wKWrUgOBmE0lrmnrmyS9NvQ/eQEEqNFCqZjbx3csQDjA4OgxBNGMRbaddf7GCEPUcDhlWVIQ0nDkKA+lA67GSMTbiF4dx9CCm/PFuis4bH55LTTBcPhIQEAsVbWq660aIlvEj8mqQXr8XjkUy6I2L3fVKASCg0P+JpVLAzVtgn/yn//sM9G5ROXJwecWw==; 20:lt6s1GKEsTfdb9j93xXavuvecfoyvb6jIKM69tyw/o/qSDMs5XDUm49SwJ55eLSEIDX3h/JUd4HX3pH9aAa39ok2HRtlLLEb66r7j+7t3Y1qme/TRXl314zRWi+jXeRE4HAwRHUvJPmppU5C/JyHePZI10Vny4NEo7DU4SmeRus= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(50986999)(105586002)(5002640100001)(8676002)(19580395003)(10400500002)(122556002)(76176999)(4326007)(93886004)(101416001)(8936002)(561944003)(77096005)(81166006)(81156014)(7846002)(74482002)(106116001)(2950100001)(2900100001)(87936001)(19580405001)(106356001)(110136002)(15975445007)(102836003)(36756003)(6116002)(3280700002)(82746002)(97736004)(57306001)(2906002)(86362001)(50226002)(33656002)(68736007)(189998001)(92566002)(1411001)(586003)(83716003)(7736002)(3660700001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 14:14:30.7629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: a18kOcsgOo6fUNHOvfArMA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Fernando Gont , IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:14:44 -0000 SGksDQoNCj4gT24gMjEgSnVuIDIwMTYsIGF0IDAyOjQ3LCBNYXJrIFNtaXRoIDxtYXJrenp6c21p dGhAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDIxIEp1bmUgMjAxNiBhdCAwNDoxNSwg56We 5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3JvdGU6DQo+PiBBdCBNb24sIDIwIEp1biAy MDE2IDAwOjI4OjM5ICswMjAwLA0KPj4gRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3Mu Y29tPiB3cm90ZToNCj4+IA0KPj4+Pj4gSU1PLCB0aGUgcmVhc29uIGZvciBpbmNsdWRpbmcgdGhl IG9yaWdpbmFsIHRleHQgeW91IHF1b3RlIGFib3ZlIHdhcyB0bw0KPj4+Pj4gcmVtb3ZlIHRoZSBh bWJpZ3VpdHkgaW4gdGhlIHRleHQuIFRoZSBuZXcgdGV4dCBmYWlscyB0byByZXNwb25kIHRoZQ0K Pj4+Pj4gcXVlc3Rpb246IGlzIGhlYWRlciBpbnNlcnRpb24gYWxsb3dlZD8NCj4+Pj4gDQo+Pj4+ IFlvdSdyZSBjb3JyZWN0LiBSRkMgMjQ2MCBhbmQgUkZDIDE4ODMgd2VyZSBhbWJpZ3VvdXMgb24g dGhpcyBwb2ludCB0b28uDQo+Pj4+IFRoZSBzdWdnZXN0ZWQgY29tcHJvbWlzZSBsZWF2ZXMgaXQg YW1iaWd1b3VzLg0KPj4+PiANCj4+Pj4gQWNjb3JkaW5nIHRvIE1lcnJpYW0tV2Vic3RlciBvbi1s aW5lLCB0aGUgZmlyc3QgbWVhbmluZyBvZiAiY29tcHJvbWlzZSIgaXMNCj4+Pj4gImEgd2F5IG9m IHJlYWNoaW5nIGFncmVlbWVudCBpbiB3aGljaCBlYWNoIHBlcnNvbiBvciBncm91cCBnaXZlcyB1 cCBzb21ldGhpbmcNCj4+Pj4gdGhhdCB3YXMgd2FudGVkIGluIG9yZGVyIHRvIGVuZCBhbiBhcmd1 bWVudCBvciBkaXNwdXRlIg0KPj4+IA0KPj4+IElNTywgcHVibGlzaCBhIHNwZWMgdGhhdCB3ZSBh Z3JlZSBhbmQga25vdyBiZWZvcmVoYW5kIHRoYXQgaXMgYW1iaWd1b3MNCj4+PiBpcyBub3QgYSBn b29kIHRoaW5nLiBJIGRvbid0IG1pbmQgaWYgRUgtaW5zZXJ0aW9uIGlzIGFsbG93ZWQsIG9yDQo+ Pj4gZXhwbGljaXRseSBmb3JiaWRkZW4uIEJ1dCBsZWF2aW5nIGl0IHVuc3BlY2lmaWVkIGlzIG5v dCBhIGdvb2QgdGhpbmcuDQo+PiANCj4+IEkgYWdyZWUgd2l0aCBGZXJuYW5kbyBoZXJlLg0KPj4g DQo+PiBJbiBteSB1bmRlcnN0YW5kaW5nLCB3aGlsZSB0aGUgUkZDMjQ2MCB0ZXh0IHdhcyBjZXJ0 YWlubHkgYW1iaWd1b3VzDQo+IA0KPiBJIGRvbid0IGZpbmQgdGhlIFJGQzI0NjAgdGV4dCBhbWJp Z3VvdXMuIEkgdGhpbmsNCj4gDQo+ICJXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBoZWFk ZXJzIGFyZSBub3QgZXhhbWluZWQgb3IgcHJvY2Vzc2VkDQo+ICAgYnkgYW55IG5vZGUgYWxvbmcg YSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMNCj4gICB0 aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbiB0aGUgY2FzZSBvZiBtdWx0 aWNhc3QpDQo+ICAgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBv ZiB0aGUgSVB2NiBoZWFkZXIuIg0KPiANCj4gaXMgY2xlYXIuDQoNCldlbGwsIGlmIGl0IHdlcmUg MTAwJSBjbGVhciwgd2Ugd291bGRu4oCZdCBiZSBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uLiAgQnV0 IEkgZG8gYWdyZWUsIHBlcnNvbmFsbHkuDQoNCj4gSSBkb24ndCB0aGluayBpdCBpcyBwb3NzaWJs ZSB0byBpbnNlcnQgYW4gRUggaW50byBhIHBhY2tldCB3aXRob3V0DQo+IGxvb2tpbmcgYXQgKGV4 YW1pbmluZykgdGhlIGV4aXN0aW5nIEVIcyBhbmQgbW92aW5nIChwcm9jZXNzaW5nKSB0aGUNCj4g ZXhpc3RpbmcgRUhzIHRvIGluc2VydCB0aGUgRUguDQo+IA0KPiAoSSB0aGluayB0aGUgb25seSB3 YXkgeW91IGNvdWxkICJpbnNlcnQiIGFuIEVIIGludG8gYSBwYWNrZXQgd2l0aG91dA0KPiBleGFt aW5pbmcgb3IgcHJvY2Vzc2luZyB0aGUgZXhpc3RpbmcgRUhzIGlzIHRvIGJsaW5kbHkgd3JpdGUg YW4gRUgNCj4gZGlyZWN0bHkgYWZ0ZXIgdGhlIElQdjYgZml4ZWQgaGVhZGVyLCByZWdhcmRsZXNz IG9mIHdoYXQgYWxyZWFkeQ0KPiBleGlzdHMgdGhlcmUuIE9mIGNvdXJzZSwgd2hhdCBldmVyIHdh cyBpbiB0aGF0IHBvc2l0aW9uIG9yaWdpbmFsbHkgd2FzDQo+IHByb2JhYmx5IHByZXR0eSBpbXBv cnRhbnQgdG8gdGhlIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBob3N0cy4pDQoNCg0KPj4gYW5kDQo+ PiBzb21lIHBlb3BsZSBhY3R1YWxseSBpbnRlcnByZXRlZCBpdCBhcyBpdCBhbGxvd2VkIEVILWlu c2VydGlvbiAob3INCj4+IGRlbGV0aW9uIGZvciB0aGF0IG1hdHRlciksIGl0J3MgbmV2ZXIgYmVl biB0aGUgaW50ZW50IG9mIHRoZSBvcmlnaW5hbA0KPj4gYXV0aG9ycyBvciBtb3N0IG9mIHRoZSB3 ZyBtZW1iZXJzLiAgV2UgYWxzbyBrbm93IHRoZXJlIGFyZQ0KPj4gaW50ZXJvcGVyYWJpbGl0eSBp c3N1ZXMgdGhhdCBjYW4gaGFwcGVuIGR1ZSB0byB0aGUgaW5zZXJ0aW9uL2RlbGV0aW9uLg0KPj4g DQo+IA0KPiA8c25pcD4NCj4gDQo+ICBTdWNoIGEgY29tcHJvbWlzZSBjb3VsZCByZWFkIGxpa2UN Cj4+IHRoaXM6DQo+PiANCj4+ICAgSW4gdGhlIG9yaWdpbmFsIGRlc2lnbiBvZiBJUHY2IGV4dGVu c2lvbiBoZWFkZXJzIGF0IHRoZSB0aW1lDQo+PiAgIFJGQzI0NjAsIGV4dGVuc2lvbiBoZWFkZXJz IGFyZSBub3Qgc3VwcG9zZWQgdG8gYmUgaW5zZXJ0ZWQgKG9yDQo+PiAgIGRlbGV0ZWQgZm9yIHRo YXQgbWF0dGVyKSBieSBhbnkgbm9kZSBvdGhlciB0aGFuIHRoZSBzb3VyY2Ugb2YgdGhlDQo+PiAg IHBhY2tldC4gIFtSZWxhdGVkIGlzc3VlcyB3aXRoIHRoZSBpbnNlcnRpb24vZGVsZXRpb24gc3Vj aCBhcyBQTVRVRA0KPj4gICBtYXkgYmUgaW5zZXJ0ZWQgaGVyZV0gIEJ1dCBzb21lIHJlY2VudGx5 IGRldmVsb3BlZCBhdHRlbXB0cyBoYXZlDQo+PiAgIHNvdWdodCB0byBsb29zZW4gdGhlIHJlc3Ry aWN0aW9uIHVuZGVyIHNvbWUgcGFydGljdWxhciBzZXQgb2YNCj4+ICAgY29uZGl0aW9ucy4gIEEg ZnV0dXJlIHVwZGF0ZSB0byB0aGUgcHJvdG9jb2wgbWF5IGFsbG93IHN1Y2gNCj4+ICAgZmxleGli bGUgYmVoYXZpb3IuICBCdXQsIHVudGlsIHRoZSBjb25kaXRpb25zIHRoYXQgYWxsb3cgaXQgYXJl DQo+PiAgIGZpZ3VyZWQgb3V0LCBpdCBpcyBwcnVkZW50IGZvciBuZXdlciBwcm90b2NvbHMgdG8g YXNzdW1lIHRoZQ0KPj4gICBvcmlnaW5hbGx5IGludGVuZGVkIHJlc3RyaWN0aW9ucy4NCj4+IA0K PiANCj4gSSB0aGluayB0aGlzIGlzIHByZXR0eSBnb29kIHRleHQgYXMgYW4gYWx0ZXJuYXRpdmUg b3IgYXMgYSBjb21wbGltZW50DQo+IHRvIHdoYXQgSSBzdWdnZXN0ZWQgdGhlIG90aGVyIGRheS4N Cj4gDQo+IEkgd291bGQgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgbGFzdCBzZW50ZW5jZSB0byBzb21l dGhpbmcgbGlrZToNCj4gDQo+ICJIb3dldmVyLCB1bnRpbCB0aGUgY29uZGl0aW9ucyB0aGF0IGFs bG93IGl0IGFyZSBkZXRlcm1pbmVkLCBuZXdlcg0KPiBwcm90b2NvbHMgc2hvdWxkIGFzc3VtZSB0 aGUgb3JpZ2luYWxseSBpbnRlbmRlZCByZXN0cmljdGlvbnMu4oCdDQoNCkkgdGhpbmsgSmlubWVp 4oCZcyBjb21tZW50cyBhcmUgdmVyeSBnb29kLCBhbmQgdGhlIHNwaXJpdCBvZiBoaXMgcHJvcG9z ZWQgdGV4dCBpcyBhbHNvIGdvb2QuIEkgd291bGQgYWxzbyBzdXBwb3J0IHlvdXIgc3VnZ2VzdGlv biBNYXJrIHRvIGFkYXB0IEJvYuKAmXMgcHJvcG9zYWwgdG8gc2F5IOKAnFRoZSByZWNvbW1lbmRl ZCBhcHByb2FjaOKAnSByYXRoZXIgdGhhbiDigJxPbmUgYXBwcm9hY2jigJ0uICBUaGlzIHdvdWxk IHN0aWxsIGxlYXZlIHRoZSBkb29yIG9wZW4gZm9yIGFub3RoZXIgYXBwcm9hY2ggdG8gYmUgcHJv dmVuIGxhdGVyIChpLmUuIHRoZSBvcGVuIGRvb3IgaXMgdGhlIGNvbXByb21pc2UpLg0KDQpUaW0N Cg0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQo= From nobody Tue Jun 21 12:18:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5DF12D1B8 for ; Tue, 21 Jun 2016 12:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 R7a3PSi16fBa for ; Tue, 21 Jun 2016 12:18:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD7912DCF9 for <6man@ietf.org>; Tue, 21 Jun 2016 12:18:09 -0700 (PDT) Received: from localhost ([::1]:60625 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFRBZ-0002ON-Cw; Tue, 21 Jun 2016 12:18:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 19:18:09 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #10 (rfc2460bis): Update reference of I-D.hinden-6man-rfc4291bis. X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/10#comment:1 Message-ID: <078.c026c9748c1d83e6354ee481a9d9a2bd@trac.tools.ietf.org> References: <063.a3cab36e26a2a42ee6cd541706471c6e@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <063.a3cab36e26a2a42ee6cd541706471c6e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 19:18:11 -0000 #10: Update reference of I-D.hinden-6man-rfc4291bis. Changes (by bob.hinden@gmail.com): * owner: => bob.hinden@gmail.com * status: new => assigned Old description: New description: Will fix in next version of the draft. -- -- ----------------------------------+----------------------------------- Reporter: otroan@employees.org | Owner: bob.hinden@gmail.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+----------------------------------- Ticket URL: 6man From nobody Tue Jun 21 12:19:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18F812D625 for ; Tue, 21 Jun 2016 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 K7AoD-WNgOu0 for ; Tue, 21 Jun 2016 12:19:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC57012D1B8 for <6man@ietf.org>; Tue, 21 Jun 2016 12:19:04 -0700 (PDT) Received: from localhost ([::1]:60872 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFRCS-0003Zl-JM; Tue, 21 Jun 2016 12:19:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 19:19:04 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #10 (rfc2460bis): Update reference of I-D.hinden-6man-rfc4291bis. X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/10#comment:2 Message-ID: <078.66e6f68a772a66641ed7f94f96a7dab9@trac.tools.ietf.org> References: <063.a3cab36e26a2a42ee6cd541706471c6e@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <063.a3cab36e26a2a42ee6cd541706471c6e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 19:19:06 -0000 #10: Update reference of I-D.hinden-6man-rfc4291bis. Changes (by bob.hinden@gmail.com): * status: assigned => closed * resolution: => fixed -- ----------------------------------+----------------------------------- Reporter: otroan@employees.org | Owner: bob.hinden@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ----------------------------------+----------------------------------- Ticket URL: 6man From nobody Tue Jun 21 13:14:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6112DDC4 for ; Tue, 21 Jun 2016 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 V8tklFnrfQqG for ; Tue, 21 Jun 2016 13:14:21 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DCB12DDB3 for ; Tue, 21 Jun 2016 13:14:21 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id i123so9772935pfg.0 for ; Tue, 21 Jun 2016 13:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6BF7jyNSm1cm9w/ZH08E1bHauuCQEa36viyfR81+1OI=; b=Rbg9Gsh2GF7/SbtfRZCbrAaroSpgFS+X8l3I8I7TsSH5DFW5QrFesQ2AwciM0dLqBr LCkaURz5eMTuyP3zKSQykt2U2tE7RwLppf65Q0jXQUyVGc+6V41mKkqSHXbq+BoNGZd0 y+BaOf8TUkG+3dBApREQwbj1qqGtZ0vJ+9STokqO/fVOvEhOTTxzHsvTHCw3C7I8tj/J HQch7EWc39H1tZdJ+kUjQdC6RJRTmzjGF91oqA2dlJSz21UFH6bnTF82gtAOZ1SD/m/c k7z/gsYCcXUshg1iOlPr7aAIJa47IsGpV0JqxrXkZXS0lD+YXoa5Ie0jWqGwgtnnhvYV cXwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=6BF7jyNSm1cm9w/ZH08E1bHauuCQEa36viyfR81+1OI=; b=fpyHKg1zC4SYQfkm/e/H8vP9N6lNBQXGP9LWtHGnDXMwlXe56vDPV8oCjInSJQXMe9 EY1Z4onOsz51fNXa7Zm6bCdONCiQTe8C8WnVvB9mOTk5iavdO7mrf/qmMmE7yehs3CeO vZRBlUogOyZcep9zJ9Cl1HLF2/LKXRUyRzStsf5lXHNrdvVG0gclqYDy1XPAnlXtPXp7 mty9zFXHWTFqWE0Pcaf3ZU3sN2dO5ue0OVtfh1bJmS9MT811qpRksuSiuTeF3pPHrFrL kWC4G2DjFbP6t2kaKqYcyaCEIB9eWIyQmXgGvCf+yPF3s7yasYkc01Sm2+9bH7NMX/vV uQ0A== X-Gm-Message-State: ALyK8tIfAS2z4hTmpOmlocovZE0neqee9DBoY5Ok1JqHUhBt8eZyEXTVVIfzM4+4u6hacQ== X-Received: by 10.98.50.1 with SMTP id y1mr29584039pfy.120.1466540060868; Tue, 21 Jun 2016 13:14:20 -0700 (PDT) Received: from [192.168.178.23] ([118.148.66.208]) by smtp.gmail.com with ESMTPSA id o68sm11556685pfb.18.2016.06.21.13.14.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 13:14:20 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Tim Chown , Mark Smith References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 22 Jun 2016 08:14:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 20:14:24 -0000 On 22/06/2016 02:14, Tim Chown wrote: > Hi, >=20 >> On 21 Jun 2016, at 02:47, Mark Smith wrote: >> >> On 21 June 2016 at 04:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> At Mon, 20 Jun 2016 00:28:39 +0200, >>> Fernando Gont wrote: >>> >>>>>> IMO, the reason for including the original text you quote above wa= s to >>>>>> remove the ambiguity in the text. The new text fails to respond th= e >>>>>> question: is header insertion allowed? >>>>> >>>>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point = too. >>>>> The suggested compromise leaves it ambiguous. >>>>> >>>>> According to Merriam-Webster on-line, the first meaning of "comprom= ise" is >>>>> "a way of reaching agreement in which each person or group gives up= something >>>>> that was wanted in order to end an argument or dispute" >>>> >>>> IMO, publish a spec that we agree and know beforehand that is ambigu= os >>>> is not a good thing. I don't mind if EH-insertion is allowed, or >>>> explicitly forbidden. But leaving it unspecified is not a good thing= =2E >>> >>> I agree with Fernando here. >>> >>> In my understanding, while the RFC2460 text was certainly ambiguous >> >> I don't find the RFC2460 text ambiguous. I think >> >> "With one exception, extension headers are not examined or processed >> by any node along a packet's delivery path, until the packet reaches= >> the node (or each of the set of nodes, in the case of multicast) >> identified in the Destination Address field of the IPv6 header." >> >> is clear. >=20 > Well, if it were 100% clear, we wouldn=E2=80=99t be having this discuss= ion. =20 That is indeed the point. Inserting, deleting or changing are three forms= of 'processing' in my opinion, but it seems that some implementors don't = think so. > But I do agree, personally. OK... suppose all of us here agree that 'no processing' means 'no inserti= on, deleting or changing.' How do we ensure that all readers of 2460bis under= stand this from the text? Brian >=20 >> I don't think it is possible to insert an EH into a packet without >> looking at (examining) the existing EHs and moving (processing) the >> existing EHs to insert the EH. >> >> (I think the only way you could "insert" an EH into a packet without >> examining or processing the existing EHs is to blindly write an EH >> directly after the IPv6 fixed header, regardless of what already >> exists there. Of course, what ever was in that position originally was= >> probably pretty important to the sending and receiving hosts.) >=20 >=20 >>> and >>> some people actually interpreted it as it allowed EH-insertion (or >>> deletion for that matter), it's never been the intent of the original= >>> authors or most of the wg members. We also know there are >>> interoperability issues that can happen due to the insertion/deletion= =2E >>> >> >> >> >> Such a compromise could read like >>> this: >>> >>> In the original design of IPv6 extension headers at the time >>> RFC2460, extension headers are not supposed to be inserted (or >>> deleted for that matter) by any node other than the source of the >>> packet. [Related issues with the insertion/deletion such as PMTUD >>> may be inserted here] But some recently developed attempts have >>> sought to loosen the restriction under some particular set of >>> conditions. A future update to the protocol may allow such >>> flexible behavior. But, until the conditions that allow it are >>> figured out, it is prudent for newer protocols to assume the >>> originally intended restrictions. >>> >> >> I think this is pretty good text as an alternative or as a compliment >> to what I suggested the other day. >> >> I would suggest changing the last sentence to something like: >> >> "However, until the conditions that allow it are determined, newer >> protocols should assume the originally intended restrictions.=E2=80=9D= >=20 > I think Jinmei=E2=80=99s comments are very good, and the spirit of his = proposed text is also good. I would also support your suggestion Mark to = adapt Bob=E2=80=99s proposal to say =E2=80=9CThe recommended approach=E2=80= =9D rather than =E2=80=9COne approach=E2=80=9D. This would still leave t= he door open for another approach to be proven later (i.e. the open door = is the compromise). >=20 > Tim >=20 >> Regards, >> Mark. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Jun 21 14:42:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD412DE2B for ; Tue, 21 Jun 2016 14:42:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 bJ_5heJfYuQy for ; Tue, 21 Jun 2016 14:42:17 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E9A12D807 for ; Tue, 21 Jun 2016 14:42:17 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f6so24918493ith.0 for ; Tue, 21 Jun 2016 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=26OFd08dqM8EiUhVxqFHqEG2jBUqFwgpudkNVYMnnFw=; b=BirhYHhPwE82cJte/4GUDmxlCpMTUm6JoQJYVeRiIBySkOPuSiX2I9NpPJk1y72QPk 7Cq7UwaFco7+mfLUG3LOTlSwzdbIVasEdvQHX7KSgKEbFOzLI7o33I7Svb+j6GGlPch6 qSjhGMUV0KtBQHJaONEn9jVKBFDMcc92dd3TuUfuFddDeUyDx8JWeQUGBxEIunAScd09 IOr58JbAA+6G1hhVu2yIDvRJvuuLBBVj3UV38BgMk5RnMsNNu24SrR75Ylq1xETxlyVU oUEbPkgxsHXcy137OtDADOxPZyF145e5rRVcJNpPjEeBFfiFcT5WKf1fXAxE4B1N8RUg sGow== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=26OFd08dqM8EiUhVxqFHqEG2jBUqFwgpudkNVYMnnFw=; b=M4VqHk3y0koTTIEue3jV796DzWwcQQXe0vlSjZ8XmP4hD9ENoGewFop8YlPAfjiHeh vstifAYSEp1fFjIlDxSXOJZ8ykHAsE487w9mPEJBwllzW1XEUy0iizYEoe2ULtNiKUs/ +0wiM+pyyoxKuUROwRQTeDYGuiWfAaiijcfqiU2kTCFUos+rHs/kOB8VBjRBmsaR/FLV J2SF6ToJWkeHS1gi0YhPy5jEwI066nq7jxf5MJK9YR8j6pbhVWPJxP30OyNbEs3uB3YW WWeLVasPqcIc+9n9LUVh/LvXav5ZpVe6JKH7eK0HlQbxy3e1zG4KCt4r1m9WJIxh9Kua Zf6Q== X-Gm-Message-State: ALyK8tJaUlfAePaO6+naZ6Q0TZOWPgZ9M3Nzj9P5Lpe/kkSNxrlVV/gM8SRColpdBR7caJ6MPLQDgUs0UyMjyQ== MIME-Version: 1.0 X-Received: by 10.36.208.1 with SMTP id m1mr9496763itg.37.1466545336155; Tue, 21 Jun 2016 14:42:16 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Tue, 21 Jun 2016 14:42:15 -0700 (PDT) In-Reply-To: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> Date: Tue, 21 Jun 2016 14:42:15 -0700 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:42:20 -0000 On Tue, Jun 21, 2016 at 1:14 PM, Brian E Carpenter wrote: > On 22/06/2016 02:14, Tim Chown wrote: >> Hi, >> >>> On 21 Jun 2016, at 02:47, Mark Smith wrote: >>> >>> On 21 June 2016 at 04:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>> At Mon, 20 Jun 2016 00:28:39 +0200, >>>> Fernando Gont wrote: >>>> >>>>>>> IMO, the reason for including the original text you quote above was= to >>>>>>> remove the ambiguity in the text. The new text fails to respond the >>>>>>> question: is header insertion allowed? >>>>>> >>>>>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point t= oo. >>>>>> The suggested compromise leaves it ambiguous. >>>>>> >>>>>> According to Merriam-Webster on-line, the first meaning of "compromi= se" is >>>>>> "a way of reaching agreement in which each person or group gives up = something >>>>>> that was wanted in order to end an argument or dispute" >>>>> >>>>> IMO, publish a spec that we agree and know beforehand that is ambiguo= s >>>>> is not a good thing. I don't mind if EH-insertion is allowed, or >>>>> explicitly forbidden. But leaving it unspecified is not a good thing. >>>> >>>> I agree with Fernando here. >>>> >>>> In my understanding, while the RFC2460 text was certainly ambiguous >>> >>> I don't find the RFC2460 text ambiguous. I think >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." >>> >>> is clear. >> >> Well, if it were 100% clear, we wouldn=E2=80=99t be having this discussi= on. > > That is indeed the point. Inserting, deleting or changing are three forms > of 'processing' in my opinion, but it seems that some implementors don't = think so. > >> But I do agree, personally. > > OK... suppose all of us here agree that 'no processing' means 'no inserti= on, > deleting or changing.' How do we ensure that all readers of 2460bis under= stand > this from the text? > But doesn't the 'no processing' text only apply to non-HBH EH? Could someone infer that it is okay to modify or add HBH. Since HBH must be first EH in the packet it seems possible to add or modify it without 'processing' any other EHs. Tom > Brian > >> >>> I don't think it is possible to insert an EH into a packet without >>> looking at (examining) the existing EHs and moving (processing) the >>> existing EHs to insert the EH. >>> >>> (I think the only way you could "insert" an EH into a packet without >>> examining or processing the existing EHs is to blindly write an EH >>> directly after the IPv6 fixed header, regardless of what already >>> exists there. Of course, what ever was in that position originally was >>> probably pretty important to the sending and receiving hosts.) >> >> >>>> and >>>> some people actually interpreted it as it allowed EH-insertion (or >>>> deletion for that matter), it's never been the intent of the original >>>> authors or most of the wg members. We also know there are >>>> interoperability issues that can happen due to the insertion/deletion. >>>> >>> >>> >>> >>> Such a compromise could read like >>>> this: >>>> >>>> In the original design of IPv6 extension headers at the time >>>> RFC2460, extension headers are not supposed to be inserted (or >>>> deleted for that matter) by any node other than the source of the >>>> packet. [Related issues with the insertion/deletion such as PMTUD >>>> may be inserted here] But some recently developed attempts have >>>> sought to loosen the restriction under some particular set of >>>> conditions. A future update to the protocol may allow such >>>> flexible behavior. But, until the conditions that allow it are >>>> figured out, it is prudent for newer protocols to assume the >>>> originally intended restrictions. >>>> >>> >>> I think this is pretty good text as an alternative or as a compliment >>> to what I suggested the other day. >>> >>> I would suggest changing the last sentence to something like: >>> >>> "However, until the conditions that allow it are determined, newer >>> protocols should assume the originally intended restrictions.=E2=80=9D >> >> I think Jinmei=E2=80=99s comments are very good, and the spirit of his p= roposed text is also good. I would also support your suggestion Mark to ada= pt Bob=E2=80=99s proposal to say =E2=80=9CThe recommended approach=E2=80=9D= rather than =E2=80=9COne approach=E2=80=9D. This would still leave the do= or open for another approach to be proven later (i.e. the open door is the = compromise). >> >> Tim >> >>> Regards, >>> Mark. >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jun 21 14:58:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39A412D5E9; Tue, 21 Jun 2016 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 6zCo_eVzpPZB; Tue, 21 Jun 2016 14:58:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7B412D7E2; Tue, 21 Jun 2016 14:58:51 -0700 (PDT) Received: from localhost ([::1]:59426 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFTh5-0002Un-HM; Tue, 21 Jun 2016 14:58:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 21:58:51 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #12 (rfc1981bis): s/proper MTU/path MTU X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/12#comment:1 Message-ID: <078.9f22507faedbbed2a4bac07d1b1c6eb1@trac.tools.ietf.org> References: <063.9ecc889b9160f99a7586db27dee3f693@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <063.9ecc889b9160f99a7586db27dee3f693@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160621215852.4A7B412D7E2@ietfa.amsl.com> Resent-Date: Tue, 21 Jun 2016 14:58:51 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:58:54 -0000 #12: s/proper MTU/path MTU Comment (by bob.hinden@gmail.com): The word "proper" is taken directly from RFC4821. The full intro paragraph from RFC4821 is: This document describes a method for Packetization Layer Path MTU Discovery (PLPMTUD), which is an extension to existing Path MTU Discovery methods described in [RFC1191] and [RFC1981]. In the absence of ICMP messages, the proper MTU is determined by starting with small packets and probing with successively larger packets. The bulk of the algorithm is implemented above IP, in the transport layer (e.g., TCP) or other "Packetization Protocol" that is responsible for determining packet boundaries. I think this should be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc1981bis@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc1981bis | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jun 21 14:59:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEDD12DA49; Tue, 21 Jun 2016 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 fUUj0JOGFaKG; Tue, 21 Jun 2016 14:59:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FE812D5E9; Tue, 21 Jun 2016 14:59:29 -0700 (PDT) Received: from localhost ([::1]:59494 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFThh-0002z4-GI; Tue, 21 Jun 2016 14:59:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 21:59:29 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #12 (rfc1981bis): s/proper MTU/path MTU X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/12#comment:2 Message-ID: <078.4925cbb9a2b0467188d61951fff374e2@trac.tools.ietf.org> References: <063.9ecc889b9160f99a7586db27dee3f693@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <063.9ecc889b9160f99a7586db27dee3f693@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160621215929.B4FE812D5E9@ietfa.amsl.com> Resent-Date: Tue, 21 Jun 2016 14:59:29 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:59:31 -0000 #12: s/proper MTU/path MTU Changes (by bob.hinden@gmail.com): * status: new => closed * resolution: => invalid -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc1981bis@ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc1981bis | Version: Severity: In WG Last | Resolution: invalid Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jun 21 15:10:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95DA12DE69; Tue, 21 Jun 2016 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 hwaUvdSGF8JJ; Tue, 21 Jun 2016 15:10:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8497412DE67; Tue, 21 Jun 2016 15:10:16 -0700 (PDT) Received: from localhost ([::1]:60586 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFTs7-0001Z9-VB; Tue, 21 Jun 2016 15:10:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 22:10:15 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #13 (rfc1981bis): Regardless of whether it decrements the Hop Limit X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/13#comment:1 Message-ID: <078.5733b54860855f54c0e8863c46b87901@trac.tools.ietf.org> References: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160621221016.8497412DE67@ietfa.amsl.com> Resent-Date: Tue, 21 Jun 2016 15:10:16 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:10:18 -0000 #13: Regardless of whether it decrements the Hop Limit Comment (by bob.hinden@gmail.com): Saying "independent of whether it decrements the Hop Limit" might be better. However, undefended of which word we choose, I think is a useful clarification as some thought that it only needed to preformed if the node decremented the Hop Limit. Recommend this be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc1981bis@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc1981bis | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jun 21 15:14:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E3312DE71 for ; Tue, 21 Jun 2016 15:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IPJEydp_0VG1 for ; Tue, 21 Jun 2016 15:14:45 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F7412DE46 for ; Tue, 21 Jun 2016 15:14:45 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i123so10597119pfg.0 for ; Tue, 21 Jun 2016 15:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rtel7aYUt9JxeeDZGflDi3d1l4brye0EnzsLKolhHaY=; b=EJkXCqhtJSPnbg4VWZfFE4MZEH7d9NIrlqvj1E7Pnkz63EVLtTcB3TS6s9fMDn+Uoj mlWTj9qVDSkS1zpYPUhuYcNLpqCg63mZL/Bhz1awVKDo5tOE0trTrkh2woJ3W7ByHBX1 nk03UwZ24g7S0Sxb9k12mRT6bcgW4o0wFbNHw5VMYoDMqr0ocohZZdmeZBYknBWUYxy/ iLOEmCP8LS4uk3aUCJhuzMbKJNpNDX03bRYZGH+cVwW5TpGAHGzS0OD2Y0KWSTLTaWtY HYJe0GWmk5VelYZyMNOAsmkAucnQQN7FxrcCxL926mve2hxDzq2UHpQd6/ILnIShGA4v ld0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rtel7aYUt9JxeeDZGflDi3d1l4brye0EnzsLKolhHaY=; b=a9n974EDKVvqefrnN2U+Gaz6lbLmIc+gPUvf/QJ8YaNp0zF20g1fsG6z86Ux4tVAEU lgwQT80WYxi1QnrhMAcCGpLyXnOOmzQeFJ6C4UxrzxMLUCr+eWXq0lmKV0dTrQCI4hHr V2kAkBEPs+rY7hSK0UStBikpGEwR5EA3PnD+IMF5fX4vkRA8efUrgdlNpu9JdhWjPQcr re34sYcsmncJNkG2mzksWepXi/q0g7SEVSPos30fOoSDAvMqKZyFZc8Z9XVeDQJwp6LE VXAjZZy4IQZvAxlelU1JYPc+qrJiU4vx1fBMC6WyEpHTm5kcilvL9voqqU1Lk1jCmbFV CfvA== X-Gm-Message-State: ALyK8tLmkcOLxwlU5rKbogQkcGU2UnTWiEu7KFpHOSHAUgD/Ypds8gB1qT/s6Xj/lo0nTQ== X-Received: by 10.98.40.4 with SMTP id o4mr30590944pfo.165.1466547284586; Tue, 21 Jun 2016 15:14:44 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id h189sm58996650pfc.52.2016.06.21.15.14.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 15:14:43 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Tom Herbert References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7e3809f4-4cb8-7277-10f9-cce1572dd9aa@gmail.com> Date: Wed, 22 Jun 2016 10:14:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:14:48 -0000 On 22/06/2016 09:42, Tom Herbert wrote: > On Tue, Jun 21, 2016 at 1:14 PM, Brian E Carpenter > wrote: >> On 22/06/2016 02:14, Tim Chown wrote: >>> Hi, >>> >>>> On 21 Jun 2016, at 02:47, Mark Smith wrote:= >>>> >>>> On 21 June 2016 at 04:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>> At Mon, 20 Jun 2016 00:28:39 +0200, >>>>> Fernando Gont wrote: >>>>> >>>>>>>> IMO, the reason for including the original text you quote above = was to >>>>>>>> remove the ambiguity in the text. The new text fails to respond = the >>>>>>>> question: is header insertion allowed? >>>>>>> >>>>>>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this poin= t too. >>>>>>> The suggested compromise leaves it ambiguous. >>>>>>> >>>>>>> According to Merriam-Webster on-line, the first meaning of "compr= omise" is >>>>>>> "a way of reaching agreement in which each person or group gives = up something >>>>>>> that was wanted in order to end an argument or dispute" >>>>>> >>>>>> IMO, publish a spec that we agree and know beforehand that is ambi= guos >>>>>> is not a good thing. I don't mind if EH-insertion is allowed, or >>>>>> explicitly forbidden. But leaving it unspecified is not a good thi= ng. >>>>> >>>>> I agree with Fernando here. >>>>> >>>>> In my understanding, while the RFC2460 text was certainly ambiguous= >>>> >>>> I don't find the RFC2460 text ambiguous. I think >>>> >>>> "With one exception, extension headers are not examined or processed= >>>> by any node along a packet's delivery path, until the packet reach= es >>>> the node (or each of the set of nodes, in the case of multicast) >>>> identified in the Destination Address field of the IPv6 header." >>>> >>>> is clear. >>> >>> Well, if it were 100% clear, we wouldn=E2=80=99t be having this discu= ssion. >> >> That is indeed the point. Inserting, deleting or changing are three fo= rms >> of 'processing' in my opinion, but it seems that some implementors don= 't think so. >> >>> But I do agree, personally. >> >> OK... suppose all of us here agree that 'no processing' means 'no inse= rtion, >> deleting or changing.' How do we ensure that all readers of 2460bis un= derstand >> this from the text? >> > But doesn't the 'no processing' text only apply to non-HBH EH? Could > someone infer that it is okay to modify or add HBH. Since HBH must be > first EH in the packet it seems possible to add or modify it without > 'processing' any other EHs. That's the 'one exception' discussed immediately afterwards in the text. Brian >=20 > Tom >=20 >> Brian >> >>> >>>> I don't think it is possible to insert an EH into a packet without >>>> looking at (examining) the existing EHs and moving (processing) the >>>> existing EHs to insert the EH. >>>> >>>> (I think the only way you could "insert" an EH into a packet without= >>>> examining or processing the existing EHs is to blindly write an EH >>>> directly after the IPv6 fixed header, regardless of what already >>>> exists there. Of course, what ever was in that position originally w= as >>>> probably pretty important to the sending and receiving hosts.) >>> >>> >>>>> and >>>>> some people actually interpreted it as it allowed EH-insertion (or >>>>> deletion for that matter), it's never been the intent of the origin= al >>>>> authors or most of the wg members. We also know there are >>>>> interoperability issues that can happen due to the insertion/deleti= on. >>>>> >>>> >>>> >>>> >>>> Such a compromise could read like >>>>> this: >>>>> >>>>> In the original design of IPv6 extension headers at the time >>>>> RFC2460, extension headers are not supposed to be inserted (or >>>>> deleted for that matter) by any node other than the source of the= >>>>> packet. [Related issues with the insertion/deletion such as PMTU= D >>>>> may be inserted here] But some recently developed attempts have >>>>> sought to loosen the restriction under some particular set of >>>>> conditions. A future update to the protocol may allow such >>>>> flexible behavior. But, until the conditions that allow it are >>>>> figured out, it is prudent for newer protocols to assume the >>>>> originally intended restrictions. >>>>> >>>> >>>> I think this is pretty good text as an alternative or as a complimen= t >>>> to what I suggested the other day. >>>> >>>> I would suggest changing the last sentence to something like: >>>> >>>> "However, until the conditions that allow it are determined, newer >>>> protocols should assume the originally intended restrictions.=E2=80=9D= >>> >>> I think Jinmei=E2=80=99s comments are very good, and the spirit of hi= s proposed text is also good. I would also support your suggestion Mark t= o adapt Bob=E2=80=99s proposal to say =E2=80=9CThe recommended approach=E2= =80=9D rather than =E2=80=9COne approach=E2=80=9D. This would still leav= e the door open for another approach to be proven later (i.e. the open do= or is the compromise). >>> >>> Tim >>> >>>> Regards, >>>> Mark. >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Jun 21 15:41:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394CC12DE77; Tue, 21 Jun 2016 15:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 5KjqXNBRJEgq; Tue, 21 Jun 2016 15:41:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8C812DA8C; Tue, 21 Jun 2016 15:41:01 -0700 (PDT) Received: from localhost ([::1]:35301 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bFULt-0002FD-1v; Tue, 21 Jun 2016 15:41:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc4291bis@ietf.org, bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 21 Jun 2016 22:41:01 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #14 (rfc4291bis): Reference to default-iid X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/14#comment:1 Message-ID: <078.f11d855bb8a4efefabf55727d0c473ca@trac.tools.ietf.org> References: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc4291bis@ietf.org, bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc4291bis@ietf.org Resent-Message-Id: <20160621224101.7F8C812DA8C@ietfa.amsl.com> Resent-Date: Tue, 21 Jun 2016 15:41:01 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:41:09 -0000 #14: Reference to default-iid Comment (by bob.hinden@gmail.com): It might better to change the example to point to RFC7721 "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" or RFC7271 "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as they are already RFCs and provides similar guidance. Comments? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc4291bis@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc4291bis | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jun 21 15:52:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15D012DE9D for ; Tue, 21 Jun 2016 15:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zou7C1OrcAQU for ; Tue, 21 Jun 2016 15:52:00 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 C752912D813 for ; Tue, 21 Jun 2016 15:52:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5LMq0Ap041657; Tue, 21 Jun 2016 15:52:00 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5LMpoVa041157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 15:51:50 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Jun 2016 15:51:49 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Tue, 21 Jun 2016 15:51:50 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter Subject: RE: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRyaupvvtvtMtNwUuE0wZ2jx6r6p/wsGwAgACH1QCAAChCgIABS5mAgAB+QwCAANEbgIAA2YYA//+0zdA= Date: Tue, 21 Jun 2016 22:51:49 +0000 Message-ID: <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:52:02 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50ZXINCg0KPiBPSy4u LiBzdXBwb3NlIGFsbCBvZiB1cyBoZXJlIGFncmVlIHRoYXQgJ25vIHByb2Nlc3NpbmcnIG1lYW5z ICdubyBpbnNlcnRpb24sDQo+IGRlbGV0aW5nIG9yIGNoYW5naW5nLicgSG93IGRvIHdlIGVuc3Vy ZSB0aGF0IGFsbCByZWFkZXJzIG9mIDI0NjBiaXMNCj4gdW5kZXJzdGFuZA0KPiB0aGlzIGZyb20g dGhlIHRleHQ/DQoNCkluc3RlYWQgb2YgInByb2Nlc3NpbmcsIiB3aHkgbm90IHNheSAibW9kaWZ5 aW5nLCIgb3IgbWF5YmUgZXZlbiAiaW5zcGVjdGluZyBhbmQgbW9kaWZ5aW5nIiAod2l0aCB0aGUg b25lIGV4Y2VwdGlvbiBzcGVjaWZpZWQgYWxyZWFkeSk/DQoNCldlIHNlZW0gdG8gZ28gYXJvdW5k IGFuZCBhcm91bmQgb24gdGhpcywgYmVjYXVzZSBvZiB3aGF0ICJjb25zZW50aW5nIGFkdWx0cyIg aGF2ZSBiZWVuIGtub3duIHRvIGRvLCBzdHJpY3RseSB3aXRoaW4gdGhlaXIgb3duIGFkbWluaXN0 cmF0aXZlIGRvbWFpbi4gRG8gd2UgbmVlZCB3b3JkcyB0byB0aGUgZWZmZWN0PyBUaGF0IHNlZW1z IHRvIGJlIHRoZSBpc3N1ZS4NCg0KQmVydA0KDQo= From nobody Tue Jun 21 16:13:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFF12D837; Tue, 21 Jun 2016 16:13:51 -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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pBKVVrmHfEZR; Tue, 21 Jun 2016 16:13:50 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A8C12D18C; Tue, 21 Jun 2016 16:13:50 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id t190so10979537pfb.3; Tue, 21 Jun 2016 16:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+JJQ4uMGDb2rBY40JoFMY0exHo2Y0rF3rWN8GDNu0aw=; b=DYdS/KvHmCRBg5AxS2EA+mihj5byMm+E7dnspYyx9JsgdljA09P0vYRZH2vQ9GZK4+ N8lsePm6kbWfCTVFkBrSYYrv5hkXPj45e38udYpZ1+9emkZx7vkCYrt9kCSRFKVPFi6U X/df0R1pYUatWnXxfr/hh9xoDjHQxolOjrQM5eCZTjiZVYZQwDMZOxS45qPkGtKEqCpo eOonZ2zxbYKd/Xp7SfWGyzhnG4mSioAruybmhIq5nQY3PRcBia8ZbGGRb37ROXvx69cs ptbdHGjKCxa3nWiMTbk4HGZIvS3wBvTR5OQKxrksV0GK4HjQVno4A1+jJwxxUwG3NrzT ksdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+JJQ4uMGDb2rBY40JoFMY0exHo2Y0rF3rWN8GDNu0aw=; b=mjxcGAhMvKFdtHdPtxu/6qp2OJxXbDAw/K+l3YfISG5iVdekQMELixREM2dvUzojDy NgPR0uvMceXYH0kdonwHnVb5jFMOud+2p7PJzpNYKVvJ8QFxxY6Gz89uvxDbLB8z2zAa 5wyeHqXH/gWVMpoibi8mDoav7zo3DvgCyTuIeROZ3NhXMIfz0rcl5iPgCaZNd1kBp6Dm +fcpCIrbDvLO4O2xkoVUzGCo9MUVOhHhBu9yR032FxXMI9tZ2Mn6H5qKi3O5cdb3Dy0Q dKg/FEQQbnRDECyLAp2xLNfTtVN6srMAe8Q/WxCo44fwfpG6jf8qipljkRMiNxq4pBTj AhCA== X-Gm-Message-State: ALyK8tI5sd/Sfld2Y3cdf6Y/noJmtPxlKJuqtDpEKVSmHPb9unz6EKpAvAtOwI3JPKPlVg== X-Received: by 10.98.196.18 with SMTP id y18mr30982657pff.163.1466550830402; Tue, 21 Jun 2016 16:13:50 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id ab6sm28339085pad.44.2016.06.21.16.13.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 16:13:49 -0700 (PDT) Subject: Re: [6man] #14 (rfc4291bis): Reference to default-iid To: 6man@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, bob.hinden@gmail.com References: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> <078.f11d855bb8a4efefabf55727d0c473ca@trac.tools.ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3ef753c0-9d0c-e36b-c5cb-c26b19526b06@gmail.com> Date: Wed, 22 Jun 2016 11:13:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <078.f11d855bb8a4efefabf55727d0c473ca@trac.tools.ietf.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:13:52 -0000 On 22/06/2016 10:41, 6man issue tracker wrote: > #14: Reference to default-iid > > > Comment (by bob.hinden@gmail.com): > > It might better to change the example to point to RFC7721 "Security and > Privacy Considerations for IPv6 Address Generation Mechanisms" or RFC7271 > "A Method for Generating Semantically Opaque Interface Identifiers with > IPv6 Stateless Address Autoconfiguration (SLAAC)" as they are already RFCs > and provides similar guidance. Makes sense to me, unless default-iid makes rapid progress in the WG. Brian From nobody Tue Jun 21 16:17:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221212D69E for ; Tue, 21 Jun 2016 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vDhl8pgLoc0D for ; Tue, 21 Jun 2016 16:17:29 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D177912D18C for <6man@ietf.org>; Tue, 21 Jun 2016 16:17:28 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l125so27862955ywb.2 for <6man@ietf.org>; Tue, 21 Jun 2016 16:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=eFxG1lvq6d9eWDvvA5fn0YTzwqIwEcvkrUAkhlhd1hY=; b=UNjltCIdQUxIAwrKw1OUqdM/7lCfDz5EHV3+F1NOtI0mGPlOVRomvBbpwscXRBb4kL PXrIVNiafbwHmDiQzrVzfDqYFN9pVF0dBCwtWMJpLnvxvlFKNm/R9bEHWQheXPEUI/N/ dTKThxoMzLANJ/kk1e2XN+aDO/UA8o06ezaDxR2uiG6p8RcdYvZOV23YfCazwtybKm69 vcI5ZyopRgI41Klxnn4USw8JtCuE9bl6rEMIsafJqeAzbKxwIilcXM0A1M5X0say0wiQ ryFtyh9P6qEwsF/32oDZIJ0dvZySEoGu2Sck63Byx1spapMkTwe49Pkc7eIQsELmQXBy 2VWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=eFxG1lvq6d9eWDvvA5fn0YTzwqIwEcvkrUAkhlhd1hY=; b=dDY2o9EFxRV+jZH1qXnBi42QdRZBrrnfDZsVnxek/shoTibuioAxjHxy2oTo8AqsQt B+ouLU/2EadFNoQ/dsAJLWT1E1lH5A6ILL7PrMAwqTwLWpDh3ZDpFIBsycMNXXvwCp4X S841NJPTzT1diONfHRl4x7kmRq6B2fjrmLVKSSVdc7u4ldRDVotHL4Zlz25B7ZUy9NnT mE+WFBgOqGKzlm+BC9IhAyYmZ0kpE1XKjLUPyWufIpS2Eh1V/HwyHxJA3aN7WhPjioDS VXCO/2MheWssmJxenoLupVNtNRPMBWk/Kifg2bZyiWzpU4d9c9RXNCHqIJkRFgte1VCS 5aGQ== X-Gm-Message-State: ALyK8tIxgCVNMZOXi+Ryk8pUsRF3EectGTle9m8iRnZcljB6WZViK9iALjataSP5vyaaIA== X-Received: by 10.129.54.16 with SMTP id d16mr13299421ywa.41.1466551048045; Tue, 21 Jun 2016 16:17:28 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f130sm6978263ywb.52.2016.06.21.16.17.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 16:17:27 -0700 (PDT) Subject: Re: [6man] #11 (rfc2460bis): HBH header handling Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BB053632-8820-4682-BB4F-40F47CC7526C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> Date: Tue, 21 Jun 2016 16:17:25 -0700 Message-Id: <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> To: 6man@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:17:30 -0000 --Apple-Mail=_BB053632-8820-4682-BB4F-40F47CC7526C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, This proposed change is to make the processing of HBH options optional. = To me this matches what we have in operational practice. Making that = change, reduces the need for the note about some nodes may not = processing HBH options. I support this change. Comments? Bob > On Jun 12, 2016, at 11:34 AM, 6man issue tracker = wrote: >=20 > #11: HBH header handling >=20 > 2460bis relaxes the must to a should. And incorporates a paragraph = from > 7045 giving performance considerations. > The use of a _should_ process combined with a _may_ drop is not = elegant. > The second paragraph can also be read as a licence to drop. >=20 > After having thought about the text in draft-ietf-6man-hbh-header- > handling, I propose the following instead: >=20 > OLD: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that should be = examined > and processed by every node along a packet's delivery path, = including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. >=20 > It should be noted that due to performance restrictions nodes may > ignore the Hop-by-Hop Option header, drop packets containing a hop- > by-hop option header, or assign packets containing a hop-by-hop > option header to a slow processing path. Designers planning to use = a > hop-by-hop option need to be aware of this likely behaviour. >=20 > NEW: > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by nodes along a packet's delivery path, including the > source and destination nodes. The Hop-by-Hop Options header, when > present, must immediately follow the IPv6 header. Its presence is > indicated by the value zero in the Next Header field of the IPv6 > header. >=20 > NOTE: While RFC2460 required that all nodes must process the Hop-by- > Hop Options header, it is now expected that nodes only process the > Hop-by-Hop Options header if explicitly configured to do so. >=20 >=20 > In short replace the should we a may, making HBH options header purely > optional. Note that section 4.8 in 2460bis already uses a may. > I also suggest we remove the 7045 paragraph on performance = considerations, > that's highly subjective. >=20 > 3. Section 4.3 HBH > OLD: > The Hop-by-Hop Options header is used to carry optional information > that should be examined by every node along a packet's delivery = path. > The Hop-by-Hop Options header is identified by a Next Header value = of > 0 in the IPv6 header, and has the following format: >=20 > NEW: > The Hop-by-Hop Options header is used to carry optional information > that may be examined by every node along a packet's delivery path. > The Hop-by-Hop Options header is identified by a Next Header value = of > 0 in the IPv6 header, and has the following format: >=20 > Same change as above. >=20 > -- > ----------------------------------+----------------- > Reporter: otroan@employees.org | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: rfc2460bis | Version: > Severity: In WG Last Call | Keywords: > ----------------------------------+----------------- >=20 > Ticket URL: > 6man >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_BB053632-8820-4682-BB4F-40F47CC7526C 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 iQEcBAEBCgAGBQJXacsFAAoJEK7rdBF357uou/MIAL7p7D4P2kUc5qkXLePtlFG+ uXWuGIZ/cLG9b53YygxKnNSerVNYq0MJrUMO3GH/NzjsUq6z7AVh35d6r/RkZykr 7Ag70Aa3dbFK0dcawdZCceoZ9rJVea+X5gCL2gBQEF04iGuJvoukCwhRMxiPgvyH DPjwveyOwT7twlYJNS5RLvxKanzyXRo6lJdVl7HQO8+tLz4WHpF4kyAo6KMQhO8H R7zXB3FiKC5HVdir7kClsGAalGrUpTYINzSTT5X01EpMuJZNaU4jsoqeOnKbFjyR +6LJD7cyb00SO5iwxUGiHsEKF2yryjq7gqoP4ajay+t7xnkxAfrQoRq+X5fMCNw= =WJme -----END PGP SIGNATURE----- --Apple-Mail=_BB053632-8820-4682-BB4F-40F47CC7526C-- From nobody Tue Jun 21 16:37:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7945012DEC0 for ; Tue, 21 Jun 2016 16:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nbh7JeuiPSbz for ; Tue, 21 Jun 2016 16:37:10 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 62CDA12DA93 for <6man@ietf.org>; Tue, 21 Jun 2016 16:37:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5LNb9ja036682; Tue, 21 Jun 2016 16:37:10 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5LNb1RO036656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 16:37:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Jun 2016 16:37:00 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Tue, 21 Jun 2016 16:37:01 -0700 From: "Manfredi, Albert E" To: Bob Hinden , "6man@ietf.org" <6man@ietf.org> Subject: RE: [6man] #11 (rfc2460bis): HBH header handling Thread-Topic: [6man] #11 (rfc2460bis): HBH header handling Thread-Index: AQHRzBMdKRLE9UcFnketXUipm0+QlZ/0j7cw Date: Tue, 21 Jun 2016 23:37:00 +0000 Message-ID: <74911bd3b690492a8d85faadac129589@XCH15-06-11.nw.nos.boeing.com> References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> In-Reply-To: <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:37:11 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden =20 > This proposed change is to make the processing of HBH options optional. = To > me this matches what we have in operational practice. Making that change= , > reduces the need for the note about some nodes may not processing HBH > options. >=20 > I support this change. >=20 > Comments? I think we should not use "process," but instead "examine and process." Mak= es it clear that nodes can completely ignore the HBH header, like all the o= ther extension headers. > > NEW: > > The exception referred to in the preceding paragraph is the Hop-by- > > Hop Options header, which carries information that may be *examined* > > and processed by nodes along a packet's delivery path, including the > > source and destination nodes. The Hop-by-Hop Options header, when > > present, must immediately follow the IPv6 header. Its presence is > > indicated by the value zero in the Next Header field of the IPv6 > > header. > > NOTE: While RFC2460 required that all nodes must examine the Hop-by- Hop Options header, it is now expected that nodes only examine the Hop-by-Hop Options header, and process the packet accordingly, if explicitly configured to do so. From nobody Wed Jun 22 01:08:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9FD12D1AE; Wed, 22 Jun 2016 01:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 i1lJgZG-JPjr; Wed, 22 Jun 2016 01:08:00 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B14C12D104; Wed, 22 Jun 2016 01:08:00 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2016 08:07:59 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 239CB9CC51; Wed, 22 Jun 2016 01:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=Sbjjgnjr06CiKaqkR7jz5ZerJx8=; b= qvCOnM4QUeKNOuT4QbDVVtqQ6OMoPMk/a5CNoIWWFLLN5DRywNIyfGCCheLM6pj4 WGrF06I5zX5DTPWPIoApTTflK3PA2MUhoClTUnPIAMbo5v4mygom1SrzS2s6gvEU DYwmmGedaj/UXDDox5dfLPp8zzcPB8JDgqit9rt0VT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=fviG+ctdtnTrtPJe7xXZ8rNBX8 TmGZnFKEQGLL9bb7VcxrZ5pa2FGUyNvDTb/OtdHgXzHxHyYIlWL4jcmLROknKLGY bCR7z4/xuUs99kI21w5h8sXvoLHjxvDptDEyOu7bGmiwidEBlonhtLh2osefb92N mLXG76Mm0VeyQEV78= Received: from h.hanazo.no (unknown [62.214.2.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DC4AF9CC4E; Wed, 22 Jun 2016 01:07:57 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id EBB4F21E53ED; Wed, 22 Jun 2016 10:07:54 +0200 (CEST) Subject: Re: [6man] #13 (rfc1981bis): Regardless of whether it decrements the Hop Limit Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F130AA23-CD8F-408C-98A1-1FA26B9F027E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <078.5733b54860855f54c0e8863c46b87901@trac.tools.ietf.org> Date: Wed, 22 Jun 2016 10:07:51 +0200 Message-Id: References: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> <078.5733b54860855f54c0e8863c46b87901@trac.tools.ietf.org> To: 6man@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: bob.hinden@gmail.com, draft-ietf-6man-rfc1981bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 08:08:02 -0000 --Apple-Mail=_F130AA23-CD8F-408C-98A1-1FA26B9F027E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > #13: Regardless of whether it decrements the Hop Limit > > > Comment (by bob.hinden@gmail.com): > > Saying "independent of whether it decrements the Hop Limit" might be > better. > > However, undefended of which word we choose, I think is a useful > clarification as some thought that it only needed to preformed if the node > decremented the Hop Limit. what is this "thing" that does not decrement the Hop Limit but sends ICMP? Ole --Apple-Mail=_F130AA23-CD8F-408C-98A1-1FA26B9F027E 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 iQEcBAEBCgAGBQJXakdaAAoJED4aXnjSQuKWA9YIAJk+xG5wvVVbgsEIZG811LAe g8TYBfZQ2/73Lvt9d2wvKOXbOoyvqq1eOafch5dAWhgoNOfzowL0vfyEf8Fq7S5K 6pLVeXpUTMKvL8kru0fkEaVXddpzz972BnRwkCl/Dfb8uqki0pUapJFWANQ8Vsco 0WS9NV1vLLm9WYEQr4gEagji9jEzAL8QJ8ZFZ6hRBYHfCmSVwFyDPovXX/J8SkiB DCNVseYCsMqLhl6B5pW30zcUjNFBxlwlKiYJQP1VlfZrZK1ziCwCEpx2OH6bEute W4kNc6DmrEhXviINPmzyTPuF2mMLX0GPQBDKbgNeY7k91/aSvneO//k08UUFGG0= =6WFJ -----END PGP SIGNATURE----- --Apple-Mail=_F130AA23-CD8F-408C-98A1-1FA26B9F027E-- From nobody Wed Jun 22 02:55:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1112B069; Wed, 22 Jun 2016 02:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Av5ExvUtSSPj; Wed, 22 Jun 2016 02:55:20 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E59127058; Wed, 22 Jun 2016 02:55:19 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2016 09:55:18 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5E12A9CC4F; Wed, 22 Jun 2016 02:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=QL4uko2XZaP9DVNV+hWksvAQ/So=; b= MrWzjaq5EEjHtLWLNeGRca/EE1fUO2d4T2QpQXTobDIlkf4cPJfpBMO1VUBKsPV8 P9cr+q7rHOHkKffV2PwaW7FvRSeinXqYQyg2v64MwHGu2VsZmpyBRR5YV6dCbeE5 Knjts253/44X+FbCC3IB3r6XMk07UZidvwCu9G16PO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=W/7rKwXvtfz/gnAN5vFPyCf1KB yujfQG3NrEZaBXYsqjIe/hdMWZ5AJfxH6st3Wgs5CzFsPam+t7dZp+s6ZTQ7CYs/ yx5Pumm7jPSMztIymt51hriHpXVeUCVZT+U8OgGjmbX5LOeg6UVwnjFFSmhxTh2v dI9XFhM9lcC9Asjpk= Received: from h.hanazo.no (unknown [62.214.2.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 228BB9CC4E; Wed, 22 Jun 2016 02:55:17 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id F2C4B21F551F; Wed, 22 Jun 2016 11:55:14 +0200 (CEST) Subject: Re: [6man] #14 (rfc4291bis): Reference to default-iid Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1E8366F6-B48B-4815-A1FA-B3E40B69A153"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <3ef753c0-9d0c-e36b-c5cb-c26b19526b06@gmail.com> Date: Wed, 22 Jun 2016 11:55:11 +0200 Message-Id: References: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> <078.f11d855bb8a4efefabf55727d0c473ca@trac.tools.ietf.org> <3ef753c0-9d0c-e36b-c5cb-c26b19526b06@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: bob.hinden@gmail.com, 6man@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 09:55:22 -0000 --Apple-Mail=_1E8366F6-B48B-4815-A1FA-B3E40B69A153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> #14: Reference to default-iid >>=20 >>=20 >> Comment (by bob.hinden@gmail.com): >>=20 >> It might better to change the example to point to RFC7721 "Security = and >> Privacy Considerations for IPv6 Address Generation Mechanisms" or = RFC7271 >> "A Method for Generating Semantically Opaque Interface Identifiers = with >> IPv6 Stateless Address Autoconfiguration (SLAAC)" as they are already = RFCs >> and provides similar guidance. >=20 > Makes sense to me, unless default-iid makes rapid progress in the WG. OLD: The details of forming interface identifiers are defined in other specifications, such as "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] and "Recommendation on Stable IPv6 Interface Identifiers" [I-D.ietf-6man-default-iids]. Specific cases are described in appropriate "IPv6 over " specifications, such as "IPv6 over Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428]. NEW: The details of forming interface identifiers are defined in other specifications, such as "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7271]. Specific cases are described = in appropriate "IPv6 over " specifications, such as "IPv6 over = Ethernet" [RFC2464]. The security and privacy considerations for IPv6 address generation = is described in [RFC7721]. cheers, Ole --Apple-Mail=_1E8366F6-B48B-4815-A1FA-B3E40B69A153 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 iQEcBAEBCgAGBQJXamCCAAoJED4aXnjSQuKWD9YH/iL7bWIf9Wyl18lirrs6q18u Amfu7CgAVRmOGW1j/m+ldsdINOHKejlvxqj8T9dCJQv8GnAmixvaSe7Srw9WDM3p nX2fZKAwnSfhQv+X75sxMrp+42LIw09WjB+CYSPM6qPWjcxpSC+6vCev1+gKViE+ LAIPGSiukmkF2t2XgVpvliP16r3toFf4KDaeb1opNXwLl00VDCRnJYuIQ/wXk9mI Tb2LQTjJxxpNsfVGJGwfWmzBn3BDdj7wogP7pR04gvngQBXxAYceFO8r7wjYbQhG kGzTTuXOAvYwdONZYP+2IlRWa3gjh96Pn+PD6lxRpg1aZipbRuC3emH1Hv2/DiU= =tUmy -----END PGP SIGNATURE----- --Apple-Mail=_1E8366F6-B48B-4815-A1FA-B3E40B69A153-- From nobody Wed Jun 22 05:33:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6F12D0DA for ; Wed, 22 Jun 2016 05:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BPjKLOFKcXFP for ; Wed, 22 Jun 2016 05:33:17 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C33712D0BC for ; Wed, 22 Jun 2016 05:33:17 -0700 (PDT) Received: from [192.168.1.129] (BSN-95-241-32.static.siol.net [193.95.241.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 21F0F80307; Wed, 22 Jun 2016 14:33:15 +0200 (CEST) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Brian E Carpenter , Tim Chown , Mark Smith References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <576A857E.3050603@si6networks.com> Date: Wed, 22 Jun 2016 14:33:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Bob Hinden , IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 12:33:20 -0000 On 06/21/2016 10:14 PM, Brian E Carpenter wrote: >>> >>> On 21 June 2016 at 04:15, 神明é”哉 wrote: >>>> At Mon, 20 Jun 2016 00:28:39 +0200, >>>> Fernando Gont wrote: >>>> >>>>>>> IMO, the reason for including the original text you quote above was to >>>>>>> remove the ambiguity in the text. The new text fails to respond the >>>>>>> question: is header insertion allowed? >>>>>> >>>>>> You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too. >>>>>> The suggested compromise leaves it ambiguous. >>>>>> >>>>>> According to Merriam-Webster on-line, the first meaning of "compromise" is >>>>>> "a way of reaching agreement in which each person or group gives up something >>>>>> that was wanted in order to end an argument or dispute" >>>>> >>>>> IMO, publish a spec that we agree and know beforehand that is ambiguos >>>>> is not a good thing. I don't mind if EH-insertion is allowed, or >>>>> explicitly forbidden. But leaving it unspecified is not a good thing. >>>> >>>> I agree with Fernando here. >>>> >>>> In my understanding, while the RFC2460 text was certainly ambiguous >>> >>> I don't find the RFC2460 text ambiguous. I think >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." >>> >>> is clear. >> >> Well, if it were 100% clear, we wouldn’t be having this discussion. > > That is indeed the point. Inserting, deleting or changing are three forms > of 'processing' in my opinion, but it seems that some implementors don't think so. > >> But I do agree, personally. > > OK... suppose all of us here agree that 'no processing' means 'no insertion, > deleting or changing.' How do we ensure that all readers of 2460bis understand > this from the text? This is exactly my point. We're publishing a bis document, that hopefully we'll be there for ages. It'd be too bad to leave this "ambiguity" in, particularly when we knew about it at the time the bis document was being discussed. Given I've filled an errata, maybe a good first step would be to make a decision on the errata? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 22 06:10:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956012B041 for ; Wed, 22 Jun 2016 06:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RmVHy1OnLX5v for ; Wed, 22 Jun 2016 06:09:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB0D12B074 for ; Wed, 22 Jun 2016 06:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1466600997; x=1467810597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tcZegpzfdjQojiV8on9MxxnRMY9J+4h9qA+H7JNETKk=; b=lDQ09ypIz29+hqPDmvCONPtjuVvE9ipiaLAC14KRRmcSrCwQ4N2lm2qj DZfINILn9MZ4O1gcMxWkVA0ci0EgUh2P43zSaLGAhuykgyVeR+d7Q4VkR i6vKzb4pJB63OBL2jvZU0/TNYrQqII5Y2wdIN98CVm0uSETAwpSGks1js Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAgC7jWpX/4oNJK1egz5WfQa6LoF6F?= =?us-ascii?q?wuFdQIcgRA4FAEBAQEBAQFlJ4RMAQEBAwEBAQEgEToLBQsCAQYCDgoCAiYCAgI?= =?us-ascii?q?lCxUQAgQOBYgoCA6VNp0dkEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSaBd?= =?us-ascii?q?wiCToE5AYJ2J4JqK4IvBYgUkGkBhgeCeIUtjyOPewEeNoIVgVtuiXJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,509,1459814400"; d="scan'208";a="288508025" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2016 13:09:53 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5MD9qaq006647 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jun 2016 13:09:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Jun 2016 09:09:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 22 Jun 2016 09:09:52 -0400 From: "Carlos Pignataro (cpignata)" To: Fernando Gont Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRzIdc4OFY3lhTjk6IbNVfni3OTQ== Date: Wed, 22 Jun 2016 13:09:52 +0000 Message-ID: <49DB95B1-AC11-4DC5-8251-5ECE0A5F0934@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <576A857E.3050603@si6networks.com> In-Reply-To: <576A857E.3050603@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.120] Content-Type: text/plain; charset="utf-8" Content-ID: <18F406A42710D64A8B9A6098700CACF1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 List , Bob Hinden , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 13:10:01 -0000 DQo+IE9uIEp1biAyMiwgMjAxNiwgYXQgODozMyBBTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2 bmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IE9uIDA2LzIxLzIwMTYgMTA6MTQgUE0sIEJyaWFu IEUgQ2FycGVudGVyIHdyb3RlOg0KPj4+PiANCj4+Pj4gT24gMjEgSnVuZSAyMDE2IGF0IDA0OjE1 LCDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPiB3cm90ZToNCj4+Pj4+IEF0IE1vbiwg MjAgSnVuIDIwMTYgMDA6Mjg6MzkgKzAyMDAsDQo+Pj4+PiBGZXJuYW5kbyBHb250IDxmZ29udEBz aTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4+PiBJTU8sIHRoZSByZWFzb24g Zm9yIGluY2x1ZGluZyB0aGUgb3JpZ2luYWwgdGV4dCB5b3UgcXVvdGUgYWJvdmUgd2FzIHRvDQo+ Pj4+Pj4+PiByZW1vdmUgdGhlIGFtYmlndWl0eSBpbiB0aGUgdGV4dC4gVGhlIG5ldyB0ZXh0IGZh aWxzIHRvIHJlc3BvbmQgdGhlDQo+Pj4+Pj4+PiBxdWVzdGlvbjogaXMgaGVhZGVyIGluc2VydGlv biBhbGxvd2VkPw0KPj4+Pj4+PiANCj4+Pj4+Pj4gWW91J3JlIGNvcnJlY3QuIFJGQyAyNDYwIGFu ZCBSRkMgMTg4MyB3ZXJlIGFtYmlndW91cyBvbiB0aGlzIHBvaW50IHRvby4NCj4+Pj4+Pj4gVGhl IHN1Z2dlc3RlZCBjb21wcm9taXNlIGxlYXZlcyBpdCBhbWJpZ3VvdXMuDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBBY2NvcmRpbmcgdG8gTWVycmlhbS1XZWJzdGVyIG9uLWxpbmUsIHRoZSBmaXJzdCBtZWFu aW5nIG9mICJjb21wcm9taXNlIiBpcw0KPj4+Pj4+PiAiYSB3YXkgb2YgcmVhY2hpbmcgYWdyZWVt ZW50IGluIHdoaWNoIGVhY2ggcGVyc29uIG9yIGdyb3VwIGdpdmVzIHVwIHNvbWV0aGluZw0KPj4+ Pj4+PiB0aGF0IHdhcyB3YW50ZWQgaW4gb3JkZXIgdG8gZW5kIGFuIGFyZ3VtZW50IG9yIGRpc3B1 dGUiDQo+Pj4+Pj4gDQo+Pj4+Pj4gSU1PLCBwdWJsaXNoIGEgc3BlYyB0aGF0IHdlIGFncmVlIGFu ZCBrbm93IGJlZm9yZWhhbmQgdGhhdCBpcyBhbWJpZ3Vvcw0KPj4+Pj4+IGlzIG5vdCBhIGdvb2Qg dGhpbmcuIEkgZG9uJ3QgbWluZCBpZiBFSC1pbnNlcnRpb24gaXMgYWxsb3dlZCwgb3INCj4+Pj4+ PiBleHBsaWNpdGx5IGZvcmJpZGRlbi4gQnV0IGxlYXZpbmcgaXQgdW5zcGVjaWZpZWQgaXMgbm90 IGEgZ29vZCB0aGluZy4NCj4+Pj4+IA0KPj4+Pj4gSSBhZ3JlZSB3aXRoIEZlcm5hbmRvIGhlcmUu DQo+Pj4+PiANCj4+Pj4+IEluIG15IHVuZGVyc3RhbmRpbmcsIHdoaWxlIHRoZSBSRkMyNDYwIHRl eHQgd2FzIGNlcnRhaW5seSBhbWJpZ3VvdXMNCj4+Pj4gDQo+Pj4+IEkgZG9uJ3QgZmluZCB0aGUg UkZDMjQ2MCB0ZXh0IGFtYmlndW91cy4gSSB0aGluaw0KPj4+PiANCj4+Pj4gIldpdGggb25lIGV4 Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCBvciBwcm9jZXNzZWQN Cj4+Pj4gIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgdW50aWwg dGhlIHBhY2tldCByZWFjaGVzDQo+Pj4+ICB0aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9m IG5vZGVzLCBpbiB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpDQo+Pj4+ICBpZGVudGlmaWVkIGluIHRo ZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZSBJUHY2IGhlYWRlci4iDQo+Pj4+IA0K Pj4+PiBpcyBjbGVhci4NCj4+PiANCj4+PiBXZWxsLCBpZiBpdCB3ZXJlIDEwMCUgY2xlYXIsIHdl IHdvdWxkbuKAmXQgYmUgaGF2aW5nIHRoaXMgZGlzY3Vzc2lvbi4gIA0KPj4gDQo+PiBUaGF0IGlz IGluZGVlZCB0aGUgcG9pbnQuIEluc2VydGluZywgZGVsZXRpbmcgb3IgY2hhbmdpbmcgYXJlIHRo cmVlIGZvcm1zDQo+PiBvZiAncHJvY2Vzc2luZycgaW4gbXkgb3BpbmlvbiwgYnV0IGl0IHNlZW1z IHRoYXQgc29tZSBpbXBsZW1lbnRvcnMgZG9uJ3QgdGhpbmsgc28uDQo+PiANCj4+PiBCdXQgSSBk byBhZ3JlZSwgcGVyc29uYWxseS4NCj4+IA0KPj4gT0suLi4gc3VwcG9zZSBhbGwgb2YgdXMgaGVy ZSBhZ3JlZSB0aGF0ICdubyBwcm9jZXNzaW5nJyBtZWFucyAnbm8gaW5zZXJ0aW9uLA0KPj4gZGVs ZXRpbmcgb3IgY2hhbmdpbmcuJyBIb3cgZG8gd2UgZW5zdXJlIHRoYXQgYWxsIHJlYWRlcnMgb2Yg MjQ2MGJpcyB1bmRlcnN0YW5kDQo+PiB0aGlzIGZyb20gdGhlIHRleHQ/DQo+IA0KPiBUaGlzIGlz IGV4YWN0bHkgbXkgcG9pbnQuIFdlJ3JlIHB1Ymxpc2hpbmcgYSBiaXMgZG9jdW1lbnQsIHRoYXQN Cj4gaG9wZWZ1bGx5IHdlJ2xsIGJlIHRoZXJlIGZvciBhZ2VzLiBJdCdkIGJlIHRvbyBiYWQgdG8g bGVhdmUgdGhpcw0KPiAiYW1iaWd1aXR5IiBpbiwgcGFydGljdWxhcmx5IHdoZW4gd2Uga25ldyBh Ym91dCBpdCBhdCB0aGUgdGltZSB0aGUgYmlzDQo+IGRvY3VtZW50IHdhcyBiZWluZyBkaXNjdXNz ZWQuDQo+IA0KPiBHaXZlbiBJJ3ZlIGZpbGxlZCBhbiBlcnJhdGEsIG1heWJlIGEgZ29vZCBmaXJz dCBzdGVwIHdvdWxkIGJlIHRvIG1ha2UgYQ0KPiBkZWNpc2lvbiBvbiB0aGUgZXJyYXRhPw0KPiAN Cg0KVGhlIGNpcmN1bGFyIG5hdHVyZSBvZiB0aGlzIGRpc2N1c3Npb24gaXMgbm90IGhlbHBpbmcs IEZlcm5hbmRvLiBUaGUgY29udGVudCBvZiB0aGF0IGVycmF0YSBoYXMgYmVlbiB0aGUgc3ViamVj dCBvZiB0aGlzIGNpcmN1bGFyIHRocmVhZC4NCg0KSW4gbXkgb3BpbmlvbiwgYW4gZXJyYXRhIGlz IHRoZSB3cm9uZyB2ZWhpY2xlIGZvciB0aGlzIOKAlCBhbmQgYXMgMjQ2MGJpcyBpcyBiZWluZyBk aXNjdXNzZWQsIGdpdmVuIGFsbCB0aGUgZW1haWxzIG9uIHRoZSB0b3BpYyB0aHVzIGZhciwgdGhl IHByb3Bvc2FsIGF0Og0KDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lw djYvQk12SHVJWTkwcDEwNy1yUFM2VVZjaWc1eTJrDQoNCmlzIHdoYXQgZ2V0cyB1cyBjbG9zZXIg dG8gdGhlIG9yaWdpbmFsIDI0NjAgYW5kIG9yaWdpbmFsIGRpc2N1c3Npb24uDQoNClRoaXMgd291 bGQgZm9yayBhbnkgcG90ZW50aWFsIHN1YnNlcXVlbnQgZGlzY3Vzc2lvbiBhbmQgY29uc2Vuc3Vz IGJ1aWxkaW5nIGZvciBhZnRlciAyNDYwYmlzIOKAlCBhbmQgYW4gSS1EIHNlZW1zIGEgYmV0dGVy IHZlaGljbGUgdGhhbiBmdXJ0aGVyIGV4dGVuZGluZyB0aGlzIHRocmVhZCBhZCBuYXVzZWFtIGFu ZCBob2xkaW5nIDI0NjBiaXMuDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KPiBUaGFua3Ms DQo+IC0tIA0KPiBGZXJuYW5kbyBHb250DQo+IFNJNiBOZXR3b3Jrcw0KPiBlLW1haWw6IGZnb250 QHNpNm5ldHdvcmtzLmNvbQ0KPiBQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIg OEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYu b3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Wed Jun 22 06:42:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5EF12D193 for ; Wed, 22 Jun 2016 06:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IPEpDTxCvONG for ; Wed, 22 Jun 2016 06:41:59 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3496F12D186 for ; Wed, 22 Jun 2016 06:41:59 -0700 (PDT) Received: from [192.168.1.129] (BSN-95-241-32.static.siol.net [193.95.241.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7574E801AA; Wed, 22 Jun 2016 15:41:44 +0200 (CEST) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Carlos Pignataro (cpignata)" References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <576A857E.3050603@si6networks.com> <49DB95B1-AC11-4DC5-8251-5ECE0A5F0934@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <576A924B.7070907@si6networks.com> Date: Wed, 22 Jun 2016 15:27:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <49DB95B1-AC11-4DC5-8251-5ECE0A5F0934@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Bob Hinden , IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 13:42:02 -0000 On 06/22/2016 03:09 PM, Carlos Pignataro (cpignata) wrote: > >>> OK... suppose all of us here agree that 'no processing' means 'no >>> insertion, deleting or changing.' How do we ensure that all >>> readers of 2460bis understand this from the text? >> >> This is exactly my point. We're publishing a bis document, that >> hopefully we'll be there for ages. It'd be too bad to leave this >> "ambiguity" in, particularly when we knew about it at the time the >> bis document was being discussed. >> >> Given I've filled an errata, maybe a good first step would be to >> make a decision on the errata? >> > > The circular nature of this discussion is not helping, Fernando. The > content of that errata has been the subject of this circular thread. > > In my opinion, an errata is the wrong vehicle for this — and as > 2460bis is being discussed, given all the emails on the topic thus > far, the proposal at: > > https://mailarchive.ietf.org/arch/msg/ipv6/BMvHuIY90p107-rPS6UVcig5y2k > > is what gets us closer to the original 2460 and original > discussion. > > This would fork any potential subsequent discussion and consensus > building for after 2460bis — and an I-D seems a better vehicle than > further extending this thread ad nauseam and holding 2460bis. Honestly, I don't see a circular discussion. It all started with the question regarding whether EH insertion is supposed to be allowed. Bob himself noted that "no", and a number of people gave examples of the things that can go wrong when doing that. -- I think that for most, it was understood that it was not possible, but given the recent discussion, a clarification was warranted. But a group of folks still want to insert EHs. When I look at the new text, the question about whether EH insertion is allowed or not is not clear. And I think it should be. Either state that it is allowed (which IMO would be a change, but you might think otherwise), or clarify that it is not. But leaving this feeling of "not sure if its possible" doesn't seem right. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 22 06:56:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17AE12D1D1 for ; Wed, 22 Jun 2016 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 TWhuqM7qkCHC for ; Wed, 22 Jun 2016 06:56:06 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCCE12D19E for ; Wed, 22 Jun 2016 06:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1466603766; x=1467813366; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yq4iCbKAaAOtlNF0w2VrWt1JRIctSsYLF2MPo6V5u1s=; b=j/zfadTlJnS2jEMzp+8eolcg5ToKJJCYiU98Vh/vMEaIX5QKxV48CCA+ LOND8ohh0KG5Q1XLR1bdy2bs8L7UdxxgNGnJmdwzpufuH8f2YJ+8//e6t X2Nylo0HNMwLMlJJZ/dko7RP+0TGZ2xCFk4DEfv0aTajttiQ7Iyw4H/7S c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcBQCpmGpX/5NdJa1egz5WfQa6LoF6I?= =?us-ascii?q?oV1AhyBEDkTAQEBAQEBAWUnhEwBAQEDASMRRQULAgEIDgoCAiYCAgIwFRACBA4?= =?us-ascii?q?FiCgIDrJrkEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSaBdwiCToE5AYJ2E?= =?us-ascii?q?BeCaiuCLwWYfQGGB4gljyOPewEgAzGCFYFbbolyfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,509,1459814400"; d="scan'208";a="286815444" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2016 13:56:05 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5MDu2XO029730 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jun 2016 13:56:05 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Jun 2016 09:55:55 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 22 Jun 2016 09:55:55 -0400 From: "Carlos Pignataro (cpignata)" To: Fernando Gont Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHRzIveKnrCPLrVyEauDxhmX5q9zZ/1xYwA Date: Wed, 22 Jun 2016 13:55:55 +0000 Message-ID: <7B1E0C84-10D1-4555-8629-62586556B68D@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <576A857E.3050603@si6networks.com> <49DB95B1-AC11-4DC5-8251-5ECE0A5F0934@cisco.com> <576A924B.7070907@si6networks.com> In-Reply-To: <576A924B.7070907@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.120] Content-Type: text/plain; charset="utf-8" Content-ID: <1D07AA25B249DA4BA6C279785EDFEBF9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 13:56:08 -0000 DQo+IE9uIEp1biAyMiwgMjAxNiwgYXQgOToyNyBBTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2 bmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IE9uIDA2LzIyLzIwMTYgMDM6MDkgUE0sIENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4+IA0KPj4+PiBPSy4uLiBzdXBwb3NlIGFs bCBvZiB1cyBoZXJlIGFncmVlIHRoYXQgJ25vIHByb2Nlc3NpbmcnIG1lYW5zICdubw0KPj4+PiBp bnNlcnRpb24sIGRlbGV0aW5nIG9yIGNoYW5naW5nLicgSG93IGRvIHdlIGVuc3VyZSB0aGF0IGFs bA0KPj4+PiByZWFkZXJzIG9mIDI0NjBiaXMgdW5kZXJzdGFuZCB0aGlzIGZyb20gdGhlIHRleHQ/ DQo+Pj4gDQo+Pj4gVGhpcyBpcyBleGFjdGx5IG15IHBvaW50LiBXZSdyZSBwdWJsaXNoaW5nIGEg YmlzIGRvY3VtZW50LCB0aGF0IA0KPj4+IGhvcGVmdWxseSB3ZSdsbCBiZSB0aGVyZSBmb3IgYWdl cy4gSXQnZCBiZSB0b28gYmFkIHRvIGxlYXZlIHRoaXMgDQo+Pj4gImFtYmlndWl0eSIgaW4sIHBh cnRpY3VsYXJseSB3aGVuIHdlIGtuZXcgYWJvdXQgaXQgYXQgdGhlIHRpbWUgdGhlDQo+Pj4gYmlz IGRvY3VtZW50IHdhcyBiZWluZyBkaXNjdXNzZWQuDQo+Pj4gDQo+Pj4gR2l2ZW4gSSd2ZSBmaWxs ZWQgYW4gZXJyYXRhLCBtYXliZSBhIGdvb2QgZmlyc3Qgc3RlcCB3b3VsZCBiZSB0bw0KPj4+IG1h a2UgYSBkZWNpc2lvbiBvbiB0aGUgZXJyYXRhPw0KPj4+IA0KPj4gDQo+PiBUaGUgY2lyY3VsYXIg bmF0dXJlIG9mIHRoaXMgZGlzY3Vzc2lvbiBpcyBub3QgaGVscGluZywgRmVybmFuZG8uIFRoZQ0K Pj4gY29udGVudCBvZiB0aGF0IGVycmF0YSBoYXMgYmVlbiB0aGUgc3ViamVjdCBvZiB0aGlzIGNp cmN1bGFyIHRocmVhZC4NCj4+IA0KPj4gSW4gbXkgb3BpbmlvbiwgYW4gZXJyYXRhIGlzIHRoZSB3 cm9uZyB2ZWhpY2xlIGZvciB0aGlzIOKAlCBhbmQgYXMNCj4+IDI0NjBiaXMgaXMgYmVpbmcgZGlz Y3Vzc2VkLCBnaXZlbiBhbGwgdGhlIGVtYWlscyBvbiB0aGUgdG9waWMgdGh1cw0KPj4gZmFyLCB0 aGUgcHJvcG9zYWwgYXQ6DQo+PiANCj4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvaXB2Ni9CTXZIdUlZOTBwMTA3LXJQUzZVVmNpZzV5MmsNCj4+IA0KPj4gaXMgd2hhdCBn ZXRzIHVzIGNsb3NlciB0byB0aGUgb3JpZ2luYWwgMjQ2MCBhbmQgb3JpZ2luYWwNCj4+IGRpc2N1 c3Npb24uDQo+PiANCj4+IFRoaXMgd291bGQgZm9yayBhbnkgcG90ZW50aWFsIHN1YnNlcXVlbnQg ZGlzY3Vzc2lvbiBhbmQgY29uc2Vuc3VzDQo+PiBidWlsZGluZyBmb3IgYWZ0ZXIgMjQ2MGJpcyDi gJQgYW5kIGFuIEktRCBzZWVtcyBhIGJldHRlciB2ZWhpY2xlIHRoYW4NCj4+IGZ1cnRoZXIgZXh0 ZW5kaW5nIHRoaXMgdGhyZWFkIGFkIG5hdXNlYW0gYW5kIGhvbGRpbmcgMjQ2MGJpcy4NCj4gDQo+ IEhvbmVzdGx5LCBJIGRvbid0IHNlZSBhIGNpcmN1bGFyIGRpc2N1c3Npb24uDQoNClRoYXQgaGFw cGVucyBpZiB5b3UgYXJlIG1vdmluZyB0b2dldGhlciB3aXRoIHRoZSBkaXNjdXNzaW9uIGluIGNp cmNsZXMgOi0pDQoNCj4gDQo+IEl0IGFsbCBzdGFydGVkIHdpdGggdGhlIHF1ZXN0aW9uIHJlZ2Fy ZGluZyB3aGV0aGVyIEVIIGluc2VydGlvbiBpcw0KPiBzdXBwb3NlZCB0byBiZSBhbGxvd2VkLiBC b2IgaGltc2VsZiBub3RlZCB0aGF0ICJubyIsIGFuZCBhIG51bWJlciBvZg0KPiBwZW9wbGUgZ2F2 ZSBleGFtcGxlcyBvZiB0aGUgdGhpbmdzIHRoYXQgY2FuIGdvIHdyb25nIHdoZW4gZG9pbmcgdGhh dC4gLS0NCj4gSSB0aGluayB0aGF0IGZvciBtb3N0LCBpdCB3YXMgdW5kZXJzdG9vZCB0aGF0IGl0 IHdhcyBub3QgcG9zc2libGUsIGJ1dA0KPiBnaXZlbiB0aGUgcmVjZW50IGRpc2N1c3Npb24sIGEg Y2xhcmlmaWNhdGlvbiB3YXMgd2FycmFudGVkLg0KPiANCj4gQnV0IGEgZ3JvdXAgb2YgZm9sa3Mg c3RpbGwgd2FudCB0byBpbnNlcnQgRUhzLg0KPiANCj4gV2hlbiBJIGxvb2sgYXQgdGhlIG5ldyB0 ZXh0LCB0aGUgcXVlc3Rpb24gYWJvdXQgd2hldGhlciBFSCBpbnNlcnRpb24gaXMNCj4gYWxsb3dl ZCBvciBub3QgaXMgbm90IGNsZWFyLiBBbmQgSSB0aGluayBpdCBzaG91bGQgYmUuIEVpdGhlciBz dGF0ZSB0aGF0DQo+IGl0IGlzIGFsbG93ZWQgKHdoaWNoIElNTyB3b3VsZCBiZSBhIGNoYW5nZSwg YnV0IHlvdSBtaWdodCB0aGluaw0KPiBvdGhlcndpc2UpLCBvciBjbGFyaWZ5IHRoYXQgaXQgaXMg bm90LiBCdXQgbGVhdmluZyB0aGlzIGZlZWxpbmcgb2YgIm5vdA0KPiBzdXJlIGlmIGl0cyBwb3Nz aWJsZSIgZG9lc24ndCBzZWVtIHJpZ2h0Lg0KDQpUaGUgc2FmZXN0IHJvdXRlIHNlZW1zIHRvIGJl IHRvIGRlc2NyaWJlIGFuZCBleHBsYWluIHdoYXTigJlzIGtub3duIGFib3V0IHRoZSBzdWJqZWN0 LiBUaGUgbmV3IHByb3Bvc2VkIHRleHQgYXQgPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvaXB2Ni9CTXZIdUlZOTBwMTA3LXJQUzZVVmNpZzV5Mms+IGFjaGlldmVzIGp1c3Qg dGhhdC4gSXQgbGlzdHMgcG90ZW50aWFsIHJlc3VsdHMgb2YgRUggaW5zZXJ0aW9uIGJ5IGFueSBu b2RlLiBJdCBhbHNvIGdvZXMgZnVydGhlciBhbmQgbGlzdHMgb25lIGFwcHJvYWNoIHRoYXQgZWxp bWluYXRlcyB0aG9zZSByZXN1bHRzLiAodGhlIHRleHQgY291bGQgYWxzbyBsaXN0IFBMLVBNVFVE KSBUbyBtZSwgdGhpcyBpcyBhIHN0ZXAgZm9yd2FyZCB3aXRob3V0IGFsbGVyZ2ljIHJlYWN0aW9u cywgdGhhdCBtYWtlcyB0aGUgZ2lzdCBvZiB0aGUgZGlzY3Vzc2lvbiBleHBsaWNpdC4NCg0KVGhh bmtzLA0KDQrigJQgQ2FybG9zLg0KDQo+IA0KPiBUaGFua3MsDQo+IC0tIA0KPiBGZXJuYW5kbyBH b250DQo+IFNJNiBOZXR3b3Jrcw0KPiBlLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KPiBQ R1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAx RDRFIDc0OTINCj4gDQo+IA0KPiANCj4gDQoNCg== From nobody Wed Jun 22 07:54:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BA12D974; Wed, 22 Jun 2016 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o15oKq2xvWBg; Wed, 22 Jun 2016 07:54:25 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0275012D741; Wed, 22 Jun 2016 07:46:02 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id b72so44547575ywa.3; Wed, 22 Jun 2016 07:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=khg4KfoS/7d3odr/xXUCqmgpWQ0sp1iDP+GgJTsHdtk=; b=vyua7+hqx8tFq/v062xeC6KcFxfNj+lawPjep3OJ7Dd791VwCDqEk0eox5MX43ZSpn STOjUH0RyDajYappP7nbcZ06OBScU+kCFq5ITOn7zNO2GrKW/Ou8HrAR5ZJa/sLzqyN6 epbc+jUNuWYU6AC7F0x2Mt/vSTfJroF3+opm9rubEbt8jDOZeHUgc6yKChRhjYIHCs08 VDWpb1hFb4S3dOOD/dTjloS9epl5PsQeOSvz5a9qUAmCPn4413DHsqsyQc2NBkaaO5HW 1FhQjWtT0uP9PyuICWRKkUwxXKIRUW2LEsi27nsdilxZw+JgDpy5MgGqf86ul83Oru3P H3Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=khg4KfoS/7d3odr/xXUCqmgpWQ0sp1iDP+GgJTsHdtk=; b=D7g0a+pUG1VP+KdkcSjNPmEEChq8Soa5NL6MAtQ+kz4g+mOjnxhf6yvkAGu0i0Tl7J sP9MQmT5cOUEnf3C7XvSEjSzlEsYr3k0T/Bv6haByMrwLuA8MV4/koZTKrWAck4vROFq hDcpe6thsNTEQjP67nXrLJKW/HaR8gsKXtcJwnV5Y7/4U6UkpYbEvBHoCMLB+/YE8ZH4 8UyA/1gytynofXucI5Kjap9HOrtZbOxJ+kTgCE+hal+LeF4OxLihL44ZLRE2DCiP/rNf gIPu0tWrBIuLNt2eyTLViT4CcSgwtkkLCSdVZFhlvsC9PUEPTY81w7318EVgeykvRVDP e74w== X-Gm-Message-State: ALyK8tJKkH0TpwoKwSfyeeADWFJhZqf8mYzU5jcAwHXwsj2arfcqVI2aw4Krp4NAeLpTtA== X-Received: by 10.13.226.73 with SMTP id l70mr6790973ywe.216.1466606762117; Wed, 22 Jun 2016 07:46:02 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:edbb:5c65:fd77:2bde? ([2601:647:4d00:abf0:edbb:5c65:fd77:2bde]) by smtp.gmail.com with ESMTPSA id s133sm37204904ywg.33.2016.06.22.07.45.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 07:46:00 -0700 (PDT) Subject: Re: [6man] #13 (rfc1981bis): Regardless of whether it decrements the Hop Limit Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0FA69AA4-FA87-4C21-A205-322627127AF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Wed, 22 Jun 2016 07:45:57 -0700 Message-Id: References: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> <078.5733b54860855f54c0e8863c46b87901@trac.tools.ietf.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: 6man@ietf.org, Bob Hinden , draft-ietf-6man-rfc1981bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 14:54:27 -0000 --Apple-Mail=_0FA69AA4-FA87-4C21-A205-322627127AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 22, 2016, at 1:07 AM, otroan@employees.org wrote: >=20 >> #13: Regardless of whether it decrements the Hop Limit >>=20 >>=20 >> Comment (by bob.hinden@gmail.com): >>=20 >> Saying "independent of whether it decrements the Hop Limit" might be >> better. >>=20 >> However, undefended of which word we choose, I think is a useful >> clarification as some thought that it only needed to preformed if the = node >> decremented the Hop Limit. >=20 > what is this "thing" that does not decrement the Hop Limit but sends = ICMP? There was some discussion at the last 6man meeting that there were = devices that did just that, and it needed to be clarified. Unless someone speaks up to defend this text, I am fine with removing = it. The =E2=80=9Cregardless=E2=80=9D text is in this paragraph: If any of the packets sent on that path are too large to be forwarded by some node (regardless of whether it decrements the Hop Limit) along the path, that node will discard them and return ICMPv6 Packet Too Big messages [ICMPv6]. Bob >=20 > Ole >=20 --Apple-Mail=_0FA69AA4-FA87-4C21-A205-322627127AF7 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 iQEcBAEBCgAGBQJXaqSmAAoJEK7rdBF357uoHGkH/ip2VMo+b7ovfYtrdyk8EUO5 rydi6eHPYfuyYM/YRM1+edsJZdNJz68ZaRPP/VhaSLqNPen4LPm6zMh8w3kTktb2 LiL7YAsiq99br7w2WHwsvSH5uQiqMyCdjAuUawcWqyxwg1bbfoff/0tAtnr6E46J KwS0udTjFlNGA8p4FXKZkASfbhIXYNoZeeskE8Y3FRRfeyLKZwKejKO8+JwfrwIn jnaS6kewKHj5P4TibHxsxSIS6+RPMvBUNAxKnfMEiYudkFHRJQ0CNPhK29iU+xf6 I2VC/K6Hgw0QtZk1NcT4sv6DQOUAzvwbB0SGjK40YONIb4zcFWJgyV6sZf/CWW8= =rrNp -----END PGP SIGNATURE----- --Apple-Mail=_0FA69AA4-FA87-4C21-A205-322627127AF7-- From nobody Wed Jun 22 08:07:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EC312D9C4 for ; Wed, 22 Jun 2016 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 L5SRcPO2ImBZ for ; Wed, 22 Jun 2016 08:07:30 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CC412D9E0 for <6man@ietf.org>; Wed, 22 Jun 2016 07:56:07 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so44234454ywb.2 for <6man@ietf.org>; Wed, 22 Jun 2016 07:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=fl/lEKGGapTkE/2Drwg5hdF6Q8Z+NP8o0aj+o8cfXnc=; b=o5vdMKU8jxq5WWKLMC4vQ1q9Q2bYbXA9MMmY4jiSxKVmQW6+bJwfnAQiEUn1ZpSBJ2 6PuBlYQaghfNtaJ1GdkGCfbKA4OnYKYN05lVU+BcvL2fe6xi4AgTCawzUcT+mkDjG0XW pTOR0hnYPPAfp4s9p4Adp2XemCxknb2gtSlJLf1LrwpB0iRKFmTcwB2vUqQBcw9fjmng Tgn/ElM8QpB3Su31ftipPCEhLy2dA+NSXIuo8Pn5t0ytR9oEzUIeLbFbwxPlLbb2n2oD PS/wjVJHkZIaEHcHEcuokkOAuy+McguTzdYLfVUTh+fgO4S1aG58CPjUFmi20JgdcCaX V+0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=fl/lEKGGapTkE/2Drwg5hdF6Q8Z+NP8o0aj+o8cfXnc=; b=TR85ZkpcTOPXxF7XmtNJ7vlgLuD7H0t6magM4Tjn/2Eu/BNu/Z8mKRYn41M5aCJXCb Cko9uuwVxg5YzWc1hhIBJ4F4qPhb9crxqJoYUnR3ICM17czsxyTTrVZVG9EuOH46vmd+ yFCE9ljXeeaYwyD9HNn6qanx5M/lt4h2vwiC/DUsiQZznYO8zAngw0EQoQsPUEgKZtef wwJXZVxptMOS7wtFBA/C13H2CnXD3OoPOVrieVYzZjaLdESqqBQm+LZSY28g2bGSr79E fGM/ZZRybuqdbTPXyRMgSEZFVtgRd3x0dRRvKbCE03VO0eBrvQoxkm4v+zoTIodXd8LJ AUrQ== X-Gm-Message-State: ALyK8tKujN+vApCM0UmlrYJX91PytKicoRioxid5CS2/GqxqIzwUEFl88KjzgKNg/bOvJQ== X-Received: by 10.129.76.208 with SMTP id z199mr15977036ywa.32.1466607367177; Wed, 22 Jun 2016 07:56:07 -0700 (PDT) Received: from [10.0.0.23] (c-71-202-18-198.hsd1.ca.comcast.net. [71.202.18.198]) by smtp.gmail.com with ESMTPSA id o4sm37314471ywe.22.2016.06.22.07.56.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 07:56:06 -0700 (PDT) Subject: Re: [6man] #11 (rfc2460bis): HBH header handling Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FBC21804-EEBD-4F87-A3AE-834CEC7BA9C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <74911bd3b690492a8d85faadac129589@XCH15-06-11.nw.nos.boeing.com> Date: Wed, 22 Jun 2016 07:56:04 -0700 Message-Id: References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> <74911bd3b690492a8d85faadac129589@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:07:34 -0000 --Apple-Mail=_FBC21804-EEBD-4F87-A3AE-834CEC7BA9C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Manfredi, > On Jun 21, 2016, at 4:37 PM, Manfredi, Albert E = wrote: >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >=20 >> This proposed change is to make the processing of HBH options = optional. To >> me this matches what we have in operational practice. Making that = change, >> reduces the need for the note about some nodes may not processing HBH >> options. >>=20 >> I support this change. >>=20 >> Comments? >=20 > I think we should not use "process," but instead "examine and = process." Makes it clear that nodes can completely ignore the HBH = header, like all the other extension headers. >=20 >>> NEW: >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that may be = *examined* >>> and processed by nodes along a packet's delivery path, including = the >>> source and destination nodes. The Hop-by-Hop Options header, when >>> present, must immediately follow the IPv6 header. Its presence is >>> indicated by the value zero in the Next Header field of the IPv6 >>> header. >>>=20 > NOTE: While RFC2460 required that all nodes must examine the Hop-by- > Hop Options header, it is now expected that nodes only examine the > Hop-by-Hop Options header, and process the packet accordingly, if > explicitly configured to do so. I agree, this makes sense, and more consistent with the rest of the = text. Thanks, Bob >=20 >=20 >=20 --Apple-Mail=_FBC21804-EEBD-4F87-A3AE-834CEC7BA9C6 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 iQEcBAEBCgAGBQJXaqcEAAoJEK7rdBF357uodO0H/jm8Srv3c21f74gjkd+m2cHe 6i2ajS7KPlRt7ba3DgAhjN0e2cw0bsbZ3E6oOEnmKWKatLBaRyX7kPUi9COqRww+ 5OmAoMMaNe8lQzVgTFYxy/K0MpKRqdaCj08j6dGbQ+VwDWadoWCELiJkWwgueyMF K762HXqFNiMzd5cqpFaRpJlo9eg431s+EzZh1PL4w5hu67hhLOMn9BJfTlddnEXV uWzfb9uz8KAlS4YbLRS7AG7+CQht1bgxn8kBL16LRiSzn7us5yr3RcG+FF/Pw8K9 E4fmaFqFjUBaF1Q7pGlCAm1ezm7YPsJhxsV8Q5VlbmGx2GRevNxGJlUaBUmERbA= =iiIv -----END PGP SIGNATURE----- --Apple-Mail=_FBC21804-EEBD-4F87-A3AE-834CEC7BA9C6-- From nobody Thu Jun 23 19:38:08 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3140912D94F; Thu, 23 Jun 2016 19:38:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-multi-homed-host-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624023804.12644.48749.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 19:38:04 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 02:38:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Routing packets from hosts in a multi-prefix network Authors : Fred Baker Brian Carpenter Filename : draft-ietf-6man-multi-homed-host-07.txt Pages : 13 Date : 2016-06-23 Abstract: This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that implements BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. This host behavior may interact with source address selection in a given implementation, but logically follows it. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-07 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 Thu Jun 23 19:51:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AE212D958 for ; Thu, 23 Jun 2016 19:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Gjzk3o8JiNPv for ; Thu, 23 Jun 2016 19:51:44 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1730A12D955 for <6man@ietf.org>; Thu, 23 Jun 2016 19:51:44 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c2so34539868pfa.2 for <6man@ietf.org>; Thu, 23 Jun 2016 19:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ej13zVaY7vjzqYuU6dKTLFVnbwcuM/5G65wMRxT2QtU=; b=ComnZ7UIXA+ai1wamVSlexKiCFSpLLN6cnJxx9H/T/6jwJK/5a/15ai8BBlYXOYbPu um4wc/6jaPpYwmL7nB/qWuebr5grBkFgL1Q+uf4b1viadKKUo8jgWwg5Vqs3UTWPEER3 qstafWAs8ipiDmz7iUXcDbzBIIqYbG60PLJEN02rf05RPTVxCRqIVXgKvB3WkNv8zNpP QL9TMLdsunFv1J96Gae8rAW7pAUEI401kU8UUJYhGNeJ39x7KOimW0PZ3AoZMzObGFfm j2YIiQBuPy/4jXodIpkFJhMk7tUDIt6aOQPi/JO9qBZihyeELRdpLuzAu9U7ur+Rsyw4 qtow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ej13zVaY7vjzqYuU6dKTLFVnbwcuM/5G65wMRxT2QtU=; b=HLkIGa64QbywW/9rTFmBLBU+gYsMdz6wOPWgoicy0eZmdfQCTNgJx0fjbNVcdf6UrL sjMK1OKieNnZi5y4eQXLCv8UdU3IWd+qxm3cYzg/FtvhNmHRsI+DQGo5U16HE/9atDWQ 2VGnRv1tKkoq+mvhtsYvsqby3o5Up30XCvjcB+Uu1ZHMaLYyR99zCyGGkDg9862wLqs2 cpPT1RiBghj2KY9kLRMz9b4prGyQRJePQoZeEobYl+5SC1tDkGSQr6cTqyrx3inwh5d/ pe9U3a1Colb0mqVgm4s/A1lF32vNG0sKy0tHu7qUfEaiO38uvI5Xravfo1xCTM2dXHsz DlSA== X-Gm-Message-State: ALyK8tIbuNsAWOifnaM4q3V5Z1+4X9a0ovswJQ9e8uYJ1ymBuRaoqtc8gQQ8NFEAnRi6mg== X-Received: by 10.98.95.197 with SMTP id t188mr2974149pfb.162.1466736703615; Thu, 23 Jun 2016 19:51:43 -0700 (PDT) Received: from [192.168.178.23] (210.223.47.163.dynamic.snap.net.nz. [163.47.223.210]) by smtp.gmail.com with ESMTPSA id bt5sm3062192pac.47.2016.06.23.19.51.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 19:51:43 -0700 (PDT) Subject: Re: [6man] #11 (rfc2460bis): HBH header handling To: Bob Hinden , 6man@ietf.org References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5127b898-b7e9-b28c-9850-2ff0746a5cfe@gmail.com> Date: Fri, 24 Jun 2016 14:51:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 02:51:47 -0000 OK for me Brian On 22/06/2016 11:17, Bob Hinden wrote: > Hi, > > This proposed change is to make the processing of HBH options optional. To me this matches what we have in operational practice. Making that change, reduces the need for the note about some nodes may not processing HBH options. > > I support this change. > > Comments? > > Bob > > >> On Jun 12, 2016, at 11:34 AM, 6man issue tracker wrote: >> >> #11: HBH header handling >> >> 2460bis relaxes the must to a should. And incorporates a paragraph from >> 7045 giving performance considerations. >> The use of a _should_ process combined with a _may_ drop is not elegant. >> The second paragraph can also be read as a licence to drop. >> >> After having thought about the text in draft-ietf-6man-hbh-header- >> handling, I propose the following instead: >> >> OLD: >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that should be examined >> and processed by every node along a packet's delivery path, including >> the source and destination nodes. The Hop-by-Hop Options header, >> when present, must immediately follow the IPv6 header. Its presence >> is indicated by the value zero in the Next Header field of the IPv6 >> header. >> >> It should be noted that due to performance restrictions nodes may >> ignore the Hop-by-Hop Option header, drop packets containing a hop- >> by-hop option header, or assign packets containing a hop-by-hop >> option header to a slow processing path. Designers planning to use a >> hop-by-hop option need to be aware of this likely behaviour. >> >> NEW: >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by nodes along a packet's delivery path, including the >> source and destination nodes. The Hop-by-Hop Options header, when >> present, must immediately follow the IPv6 header. Its presence is >> indicated by the value zero in the Next Header field of the IPv6 >> header. >> >> NOTE: While RFC2460 required that all nodes must process the Hop-by- >> Hop Options header, it is now expected that nodes only process the >> Hop-by-Hop Options header if explicitly configured to do so. >> >> >> In short replace the should we a may, making HBH options header purely >> optional. Note that section 4.8 in 2460bis already uses a may. >> I also suggest we remove the 7045 paragraph on performance considerations, >> that's highly subjective. >> >> 3. Section 4.3 HBH >> OLD: >> The Hop-by-Hop Options header is used to carry optional information >> that should be examined by every node along a packet's delivery path. >> The Hop-by-Hop Options header is identified by a Next Header value of >> 0 in the IPv6 header, and has the following format: >> >> NEW: >> The Hop-by-Hop Options header is used to carry optional information >> that may be examined by every node along a packet's delivery path. >> The Hop-by-Hop Options header is identified by a Next Header value of >> 0 in the IPv6 header, and has the following format: >> >> Same change as above. >> >> -- >> ----------------------------------+----------------- >> Reporter: otroan@employees.org | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rfc2460bis | Version: >> Severity: In WG Last Call | Keywords: >> ----------------------------------+----------------- >> >> Ticket URL: >> 6man >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 23 23:36:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15712D8A6 for ; Thu, 23 Jun 2016 23:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Jx3c0ZD5o9JS for ; Thu, 23 Jun 2016 23:36:36 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0D612D8B2 for <6man@ietf.org>; Thu, 23 Jun 2016 23:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5398; q=dns/txt; s=iport; t=1466750196; x=1467959796; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lwQTS2nzQk7ejU0YJJ5IjxlXURzN0WlA2G56q10SruQ=; b=UrciKSP3vy1bAnCZOTA3P6hKja6V4jFaqK+ZPPEwklCLd0/jku4E6vA3 NmGBKCJtZ3Mc53pMN0tbjkhArUnI/n6mAzp8PSu+/3Aci6V3LQX3wF/YV lXFq1ZqAkY8Dy6mVAyCbeCN10TSyMyDcIZIgdPVBjMUdReMtPD/lw2kk4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgCx02xX/5BdJa1dgz5WfQauKYwGg?= =?us-ascii?q?XsXC4V2AoEyOBQBAQEBAQEBZSeETAEBAQMBAQEBNy0HFwQCAQgRBAEBAR4JByE?= =?us-ascii?q?GCxQJCAIEARIIiA4DDwgOwngNg30BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYoh?= =?us-ascii?q?E2CQ4FthWsFiBaQNjQBhgeGK4F5gXCIAYU5iA+HbgEeNoNwbgGJAH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,518,1459814400"; d="scan'208";a="289305929" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 06:36:34 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5O6aYcd003757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2016 06:36:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 01:36:34 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 01:36:33 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , Bob Hinden , "6man@ietf.org" <6man@ietf.org> Subject: RE: [6man] #11 (rfc2460bis): HBH header handling Thread-Topic: [6man] #11 (rfc2460bis): HBH header handling Thread-Index: AQHRxNkEEMueF0UeUUeIGjD1SVJOmZ/08EOAgANgk4D//+mpIA== Date: Fri, 24 Jun 2016 06:36:33 +0000 Deferred-Delivery: Fri, 24 Jun 2016 06:36:24 +0000 Message-ID: <13597a18a58d489ab5a80c9177302df5@XCH-RCD-001.cisco.com> References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> <0AC2CDBF-3A30-43A9-AC56-B30F70E552BB@gmail.com> <5127b898-b7e9-b28c-9850-2ff0746a5cfe@gmail.com> In-Reply-To: <5127b898-b7e9-b28c-9850-2ff0746a5cfe@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 06:36:38 -0000 +1 I think that the whole point is that it is the practice in the real world. In a RPL domain, RPL nodes are configured to process the HbH header, so the= change in the text does not alter the existing practice. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: vendredi 24 juin 2016 04:52 > To: Bob Hinden ; 6man@ietf.org > Subject: Re: [6man] #11 (rfc2460bis): HBH header handling >=20 > OK for me > Brian > On 22/06/2016 11:17, Bob Hinden wrote: > > Hi, > > > > This proposed change is to make the processing of HBH options optional.= To > me this matches what we have in operational practice. Making that change= , > reduces the need for the note about some nodes may not processing HBH > options. > > > > I support this change. > > > > Comments? > > > > Bob > > > > > >> On Jun 12, 2016, at 11:34 AM, 6man issue tracker > wrote: > >> > >> #11: HBH header handling > >> > >> 2460bis relaxes the must to a should. And incorporates a paragraph > >> from > >> 7045 giving performance considerations. > >> The use of a _should_ process combined with a _may_ drop is not elegan= t. > >> The second paragraph can also be read as a licence to drop. > >> > >> After having thought about the text in draft-ietf-6man-hbh-header- > >> handling, I propose the following instead: > >> > >> OLD: > >> The exception referred to in the preceding paragraph is the Hop-by- > >> Hop Options header, which carries information that should be examine= d > >> and processed by every node along a packet's delivery path, includin= g > >> the source and destination nodes. The Hop-by-Hop Options header, > >> when present, must immediately follow the IPv6 header. Its presence > >> is indicated by the value zero in the Next Header field of the IPv6 > >> header. > >> > >> It should be noted that due to performance restrictions nodes may > >> ignore the Hop-by-Hop Option header, drop packets containing a hop- > >> by-hop option header, or assign packets containing a hop-by-hop > >> option header to a slow processing path. Designers planning to use = a > >> hop-by-hop option need to be aware of this likely behaviour. > >> > >> NEW: > >> The exception referred to in the preceding paragraph is the Hop-by- > >> Hop Options header, which carries information that may be examined > >> and processed by nodes along a packet's delivery path, including the > >> source and destination nodes. The Hop-by-Hop Options header, when > >> present, must immediately follow the IPv6 header. Its presence is > >> indicated by the value zero in the Next Header field of the IPv6 > >> header. > >> > >> NOTE: While RFC2460 required that all nodes must process the Hop-by- > >> Hop Options header, it is now expected that nodes only process the > >> Hop-by-Hop Options header if explicitly configured to do so. > >> > >> > >> In short replace the should we a may, making HBH options header > >> purely optional. Note that section 4.8 in 2460bis already uses a may. > >> I also suggest we remove the 7045 paragraph on performance > >> considerations, that's highly subjective. > >> > >> 3. Section 4.3 HBH > >> OLD: > >> The Hop-by-Hop Options header is used to carry optional information > >> that should be examined by every node along a packet's delivery path= . > >> The Hop-by-Hop Options header is identified by a Next Header value o= f > >> 0 in the IPv6 header, and has the following format: > >> > >> NEW: > >> The Hop-by-Hop Options header is used to carry optional information > >> that may be examined by every node along a packet's delivery path. > >> The Hop-by-Hop Options header is identified by a Next Header value o= f > >> 0 in the IPv6 header, and has the following format: > >> > >> Same change as above. > >> > >> -- > >> ----------------------------------+----------------- > >> Reporter: otroan@employees.org | Owner: > >> Type: defect | Status: new > >> Priority: major | Milestone: > >> Component: rfc2460bis | Version: > >> Severity: In WG Last Call | Keywords: > >> ----------------------------------+----------------- > >> > >> Ticket URL: > >> 6man > >> > >> -------------------------------------------------------------------- > >> 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 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 24 09:04:20 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2502F12DCAB; Fri, 24 Jun 2016 09:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , <6man-chairs@ietf.org> Subject: 6man - Requested session has been scheduled for IETF 96 X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160049.10933.16422.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:49 -0700 Archived-At: Cc: ipv6@ietf.org, suresh.krishnan@ericsson.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:49 -0000 Dear Ole Troan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. 6man Session 1 (2:30:00) Tuesday, Morning Session I 1000-1230 Room Name: Bellevue size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops softwire spring Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 12:34:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1E12D61A for ; Fri, 24 Jun 2016 12:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 aDHOOLSZLF3L for ; Fri, 24 Jun 2016 12:34:51 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29D912D607 for ; Fri, 24 Jun 2016 12:34:50 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 19:34:49 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BF5419CC51 for ; Fri, 24 Jun 2016 12:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:references:to:message-id :mime-version; s=selector1; bh=WXfTrg2RhdssPxqC1PFITH5tipg=; b=N a0OdlQ4it9MXAGrolDLHCfZTJUFv4Q/uFVLQ8QBnpNVlyFIlkiWugFu1b3FE8pOI 9s1aaIb8Wu9ZuZFwFRm2DVm8vSYxPQ7uvGKnEj94u2PmdSDDuiZA+iyL4esXS/a8 EwOnz9j+LoMaHL4gmrRT/TAWeeviEi5lm3fqlCOv1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:references:to:message-id :mime-version; q=dns; s=selector1; b=Ov7ul/vuoTI6/D8UUjOxzu60qNy yuGY4jEzAnU9qaFNJRgw3KYxbZobInaveRh5Za2mEABwI3tw49IdcvmHlXC7qzf3 i3PMT5rFqYfico/Av4fjbPvg0CECGC8kqKCGMCXJ8S6TaDyUFs8n/EPP2S5Pi3CF ZOQCtholqQ0C1bz4= Received: from h.hanazo.no (cm-84.213.17.83.getinternet.no [84.213.17.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7EA489CC4F for ; Fri, 24 Jun 2016 12:34:48 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D26D1233F56E for ; Fri, 24 Jun 2016 21:34:41 +0200 (CEST) From: otroan@employees.org X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_307883AC-4601-43CE-9320-0FEC0B4312AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Fwd: 6man - Requested session has been scheduled for IETF 96 Date: Fri, 24 Jun 2016 21:34:38 +0200 References: <20160624160049.10933.16422.idtracker@ietfa.amsl.com> To: 6man WG Message-Id: <29E3ECB3-20C0-470C-A310-15A75604EF55@employees.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:34:53 -0000 --Apple-Mail=_307883AC-4601-43CE-9320-0FEC0B4312AD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > Begin forwarded message: > > From: "\"IETF Secretariat\"" > Subject: 6man - Requested session has been scheduled for IETF 96 > Date: 24 June 2016 at 18:00:49 GMT+2 > To: , <6man-chairs@ietf.org> > Cc: ipv6@ietf.org, suresh.krishnan@ericsson.com > Resent-From: > Resent-To: otroan@employees.org, bob.hinden@gmail.com > > Dear Ole Troan, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > 6man Session 1 (2:30:00) > Tuesday, Morning Session I 1000-1230 > Room Name: Bellevue size: 200 > --------------------------------------------- > > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: IPv6 Maintenance > Area Name: Internet Area > Session Requester: Ole Troan > > Number of Sessions: 1 > Length of Session(s): 2.5 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: 6lo 6tisch dhc homenet intarea v6ops softwire spring > > > > > Special Requests: > > --------------------------------------------------------- --Apple-Mail=_307883AC-4601-43CE-9320-0FEC0B4312AD 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 iQEcBAEBCgAGBQJXbYtRAAoJED4aXnjSQuKWXzEH/AldIhOSB/fedLaIPpRwrwSv 0d1Ob+uuxAsov7DVcwSVVXT0V49axznSL068ig6ZQphJYosXZPisy5ERcDvrmaOg OKZx7zJvil7PrIpx9SR3/asSgMYE0cfXeOqzfNf6tKHFUg2haM0SfNEu8nECMdH7 HbIO+c+hzepPp+f+glUsQqXucuXP4AI+IFReUb0aD7q/qvgXlO/+VTH02HZ8KeXh PMXQHORb17Me7OlNjmRkajInOTYnnh9NDOVaUf9a9fVkReqDso/OzWYXLHfk/Non 99+9KwV0G71EF4CS73iw5j2pCqX67qo0obB74EtOf6jl4XOaaa0V8TDOcwoOOlg= =2P0j -----END PGP SIGNATURE----- --Apple-Mail=_307883AC-4601-43CE-9320-0FEC0B4312AD-- From nobody Sun Jun 26 15:16:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D3912D12B for ; Sun, 26 Jun 2016 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RSvcfpLm1YH9 for ; Sun, 26 Jun 2016 15:16:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5552B12B04E for <6man@ietf.org>; Sun, 26 Jun 2016 15:16:39 -0700 (PDT) Received: from [192.168.1.105] (BSN-95-229-160.static.siol.net [193.95.229.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BB8FA800A6; Mon, 27 Jun 2016 00:16:37 +0200 (CEST) To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont Subject: Summary of changes in draft-ietf-6man-rdnss-rfc6106bis X-Enigmail-Draft-Status: N1110 Message-ID: <57705155.9050903@si6networks.com> Date: Mon, 27 Jun 2016 00:04:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 22:16:42 -0000 Folks, Since WGLC, the document was revised 8 times (-06 through -14) to address the comments received. These are the summary of the changes: * The document contained text that was really implementation-dependent, such as details that would apply if this spec was implemented in e.g. kernel vs. user-space. This was removed. * The bis document document was written with quite some text referencing what RFC6106 had standardized, sounding awkward in such parts. This has been fixed. * "Lifetime" values were specified as to be applied from the moment that packet was sent as opposed to the moment the packets were received. This was changed accordingly. * The "Security Considerations" section was modified such that SEND is not "RECOMMENDED" anymore (RFC2119-wise) * A number of miscellaneous edits to improve readability. This document is ready to be shipped for publication. Thanks to all that provided comments and helped improve the quality of the document, and to the authors for working on the document to address the comments. Fernando (as document shepherd) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 27 11:15:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C7712D75A for ; Mon, 27 Jun 2016 11:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 g0sUPdhy05yb for ; Mon, 27 Jun 2016 11:15:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9207012D797 for ; Mon, 27 Jun 2016 11:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2792; q=dns/txt; s=iport; t=1467051323; x=1468260923; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TCTCrquuqbD+c9b+VAf4MOdlI6q0nP8cz4kOTS/jT0Q=; b=a4twrqamdagwJYktObNn1Cg/KzzlHvFfsKdvGtSG1LfygRL/jHCDE90e 1piXlztJkQ5HzDA/UDHKPhiQuLYZolcrVYYTtO/ESctsPGt85vYGkf1Qm cIqdXRW5xpvigcRQ0aqet8+vRzUx5PfgjkybDT9rFmsIPZUwLIXA4j9IV 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANBQB4bHFX/5RdJa1bgz6BUwa8IoYYA?= =?us-ascii?q?oE0OxEBAQEBAQEBZSeETAEBAQMBeQUHBAIBCBUDJwcyFBECBA4FDogaCMMSAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6IHwiCToE5AYJ2gzyCLwWZAQGDLYFsiR2PJ?= =?us-ascii?q?I9+ATQgghWBW24BiHd/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="asc'?scan'208";a="119546680" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 18:15:18 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5RIFIDQ002666 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 18:15:18 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 13:15:17 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 13:15:17 -0500 From: "Fred Baker (fred)" To: "Manfredi, Albert E" Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHR0J/bZsPKOks8VkGO6fpC/Xu6TA== Date: Mon, 27 Jun 2016 18:15:17 +0000 Message-ID: <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_34D5E9F3-28CC-4251-8800-E77F9CA11939"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:15:28 -0000 --Apple-Mail=_34D5E9F3-28CC-4251-8800-E77F9CA11939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E = wrote: >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E = Carpenter >=20 >> OK... suppose all of us here agree that 'no processing' means 'no = insertion, >> deleting or changing.' How do we ensure that all readers of 2460bis >> understand >> this from the text? >=20 > Instead of "processing," why not say "modifying," or maybe even = "inspecting and modifying" (with the one exception specified already)? >=20 > We seem to go around and around on this, because of what "consenting = adults" have been known to do, strictly within their own administrative = domain. Do we need words to the effect? That seems to be the issue. My understanding is that section 4.2 explicitly allows an option to be = modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting = from MSB) is set. An example of such a use case would implement RCP or = XCP; the option in the HBH header collects statistical information from = the network, and the same option as a destination option returns the = result to the sender, which then uses it in the evolution of the = TCP/SCTP/QUIC/whatever Effective Window. So this discussion makes me = uncomfortable. We're discussing changing the size or existence of the header, or the = set of objects it contains, not the contents of an existing object. = Right? --Apple-Mail=_34D5E9F3-28CC-4251-8800-E77F9CA11939 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 - http://gpgtools.org iQIVAwUBV3FtM0ayAOS/EQ8MAQLv5w/+LkLumrlvT4Y6rTzpMcQs+dB5wMcHILXg WxctW8OUea4R++iuJLo/B0/hwGWCGccYmgRwfa5ERoFK7K2wkRPRhCr/Bclw/Mn3 2m0T5i/9aQ07IGeijhs4zes0caQhRSshK8F2oWgEHFRViaXr68ivHPfhgcnIIQFB OVP0jHl7NsPjZhsvcXAOJp+4mcr/UhPVEIy3P9K8qyCxH73BUiCnErjDLR9hsCLE BE8EJ4P0glDPYXZRbmqkvAQFBlSshAKkNSIFibhpysJh7NNduDlqYMAgQY8FC3+C BYnIf3u7XTq72oX5Zn4K2RJMVkxTFAWnu0jWnj89947Sxuffc5M2gABZwW3GtFmd fiea8JNhgmDkjIT/N3CFfGV53iLALKWRLuVh5i1RBYKfXGgIZpoK9cqTu9JT0T3t RDAo0kKhQZ96yW7f5GYk6i5hyZXLoIDedTm+1gUsR0dMwoPUN6ZTkcPDu0EaMz0b 5MmfUpPYW8iGg+SbmCxR42MMDrA3vjOKTvbrAh4cXOL/Q49Lx4aQ+QIJpeoCFOvK dAQcbUDGpnvqYNE+4FNRQb8uoQIhtYG0qqNJfXjMJvzVu1ORDZajBmbmTHrFgdA9 pBIwhbjq6wx4KCgxgKk5Jt1Aiu7+t8oz7YDy6ipju5NlxvQs/deYhFK/mdFbtGdd WB/mOcHCn+w= =vWfB -----END PGP SIGNATURE----- --Apple-Mail=_34D5E9F3-28CC-4251-8800-E77F9CA11939-- From nobody Mon Jun 27 11:30:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5912D75D for ; Mon, 27 Jun 2016 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 buDmP1cM2YLS for ; Mon, 27 Jun 2016 11:30:08 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920D512D5EC for ; Mon, 27 Jun 2016 11:30:08 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6so68491330ith.0 for ; Mon, 27 Jun 2016 11:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NVIcK3HrsgmMAxWnoQGK4V+Lr/SUS3/AfNpg0hZmhfU=; b=DLZprHSgjrv8YVl7Ok5j9OL24XEqbDi1KJWbq3oBQCdE9ywy1C5FyvmKahFQMK96Z0 1c0oparGiP7kdAa6UexQ7FPOtsBeuh7y3Vs6+F6gOGE1hDGOxEKiEuXHxVU3sE3AQwgE xsrd5nRNxowG5WD8rP8FAm9ko8yFKZTiE9el5I14P2IvGgbOndqklrIT+M4PnJcjF+E4 Fs9DXDmbvw2576ebj0OsWozh/aNR5hH0PbXNXQwZFfEW8xeFmQdLxjzCFYQa4QUL2ciY Ihd+qW51okNg2GICsBkptwL7+kYAvEWQN461fHyqI3sTq/Cc9ZtOUI4FdPmvvuNQCpTn Pf1A== 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-transfer-encoding; bh=NVIcK3HrsgmMAxWnoQGK4V+Lr/SUS3/AfNpg0hZmhfU=; b=W/F9hUmOXc0/p6/HeN74ELpxuMlRvAGyrMl3cAdzHBHdFXu3nc3VArxKLngMoo35VC ddHN49Kk2/SC66I2CsFOH86xW8en652gtzCZpN++nrjgBBAgS2ePe+H3sm4A09FL0gZo +XXKa2U13XLvYFJ8Z45l3LWfJLFkemIH0IR40ENMGgPPLFJ4xwmi8z1vqn3JJzZ50vHa 1XuYBwFcz/fZYXc6W9FklTP1kkL03oITBrv8rtxgNm0btMpC7omOk6aCxeV4VmZaolXj G+84Ywfj0Gj1NfwDLVslg+c/gWMWOJybdT9DmoY6mi69sn3uOcq2yplb7BZt9bGoy3q8 q/mQ== X-Gm-Message-State: ALyK8tIX0SmJSNjQdGFCLFuD6URMuZUb9Ce23OwLdGnz3+GQj4ERHlvAqrFUlBn0EN36I1elX3/UNBW17xBF0w== X-Received: by 10.36.46.21 with SMTP id i21mr10745928ita.91.1467052207672; Mon, 27 Jun 2016 11:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 11:30:06 -0700 (PDT) In-Reply-To: <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> From: Tom Herbert Date: Mon, 27 Jun 2016 11:30:06 -0700 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:30:11 -0000 On Mon, Jun 27, 2016 at 11:15 AM, Fred Baker (fred) wrote: > >> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E wrote: >> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpente= r >> >>> OK... suppose all of us here agree that 'no processing' means 'no inser= tion, >>> deleting or changing.' How do we ensure that all readers of 2460bis >>> understand >>> this from the text? >> >> Instead of "processing," why not say "modifying," or maybe even "inspect= ing and modifying" (with the one exception specified already)? >> >> We seem to go around and around on this, because of what "consenting adu= lts" have been known to do, strictly within their own administrative domain= . Do we need words to the effect? That seems to be the issue. > > My understanding is that section 4.2 explicitly allows an option to be mo= dified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting from= MSB) is set. An example of such a use case would implement RCP or XCP; the= option in the HBH header collects statistical information from the network= , and the same option as a destination option returns the result to the sen= der, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever Effe= ctive Window. So this discussion makes me uncomfortable. > > We're discussing changing the size or existence of the header, or the set= of objects it contains, not the contents of an existing object. Right? > I think it may raise another interesting question. Does changing a HBH option include that it can be removed? And if we do allow to removing HBH options would that then allow removing the HBH EH entirely? There is a practical aspect to this in that a source network may have good support for HBH options and they could be used productively within that network, however when packets egress into the Internet we might want to strip HBH options and EH to improve reachability of packets. Tom > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 27 11:53:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3934B12D7A8 for ; Mon, 27 Jun 2016 11:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rzxbhHU2Qysl for ; Mon, 27 Jun 2016 11:53:47 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 CF92812D78A for ; Mon, 27 Jun 2016 11:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5RIrUCs013704; Mon, 27 Jun 2016 11:53:30 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5RIrMWX013544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 11:53:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Jun 2016 11:53:22 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Mon, 27 Jun 2016 11:53:22 -0700 From: "Manfredi, Albert E" To: Tom Herbert Subject: RE: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHR0KHxaCPHAcB7OEiGaoP8rnSopJ/9p2eQ Date: Mon, 27 Jun 2016 18:53:22 +0000 Message-ID: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:53:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRv OnRvbUBoZXJiZXJ0bGFuZC5jb21dDQoNCj4gSSB0aGluayBpdCBtYXkgcmFpc2UgYW5vdGhlciBp bnRlcmVzdGluZyBxdWVzdGlvbi4gRG9lcyBjaGFuZ2luZyBhIEhCSA0KPiBvcHRpb24gaW5jbHVk ZSB0aGF0IGl0IGNhbiBiZSByZW1vdmVkPyBBbmQgaWYgd2UgZG8gYWxsb3cgdG8gcmVtb3ZpbmcN Cj4gSEJIIG9wdGlvbnMgd291bGQgdGhhdCB0aGVuIGFsbG93IHJlbW92aW5nIHRoZSBIQkggRUgg ZW50aXJlbHk/IFRoZXJlDQo+IGlzIGEgcHJhY3RpY2FsIGFzcGVjdCB0byB0aGlzIGluIHRoYXQg YSBzb3VyY2UgbmV0d29yayBtYXkgaGF2ZSBnb29kDQo+IHN1cHBvcnQgZm9yIEhCSCBvcHRpb25z IGFuZCB0aGV5IGNvdWxkIGJlIHVzZWQgcHJvZHVjdGl2ZWx5IHdpdGhpbg0KPiB0aGF0IG5ldHdv cmssIGhvd2V2ZXIgd2hlbiBwYWNrZXRzIGVncmVzcyBpbnRvIHRoZSBJbnRlcm5ldCB3ZSBtaWdo dA0KPiB3YW50IHRvIHN0cmlwIEhCSCBvcHRpb25zIGFuZCBFSCB0byBpbXByb3ZlIHJlYWNoYWJp bGl0eSBvZiBwYWNrZXRzLg0KDQpZZXMsIGV4YWN0bHkgd2hlcmUgSSdtIGNvbWluZyBmcm9tIHRv by4gTWF5YmUgaXQgbmVlZHMgdG8gYmUgc3RpcHVsYXRlZCBleHBsaWNpdGx5LCB0aGF0IHNob3Vs ZCBhbnkgYWRtaW5pc3RyYXRpdmUgZG9tYWluJ3Mgbm9kZXMgKHJvdXRlcnMpIGRlY2lkZSB0byBp bmplY3QgZXh0ZW5zaW9uIGhlYWRlcnMgdXBvbiBpbmdyZXNzLCB0aGVuIHRoZXkgbXVzdCByZXN0 b3JlIHRoZSBvcmlnaW5hbCBoZWFkZXIgdXBvbiBlZ3Jlc3MuIFNvIHRoZSBkZXN0aW5hdGlvbiB0 aGlua3MgdGhlIG9ubHkgZXh0ZW5zaW9uIGhlYWRlcnMgaW4gdGhlIHBhY2tldCB3ZXJlIHRob3Nl IGluc2VydGVkIGJ5IHRoZSBzb3VyY2UsIGluY2x1ZGluZyB0aGUgSEJIIEVILg0KDQpTb21laG93 IG9yIG90aGVyLCBpdCB3b3VsZCBiZSBuaWNlIGlmIGFueSBvZGRiYWxsIHVzZSBvZiBFSHMgd2Vy ZSBrZXB0IGxvY2FsaXplZCB0byB0aGUgImNvbnNlbnRpbmcgYWR1bHRzLiINCg0KQmVydA0KDQo= From nobody Mon Jun 27 12:11:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4A12D7A8 for ; Mon, 27 Jun 2016 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 h2lRFJAGWU1I for ; Mon, 27 Jun 2016 12:11:51 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5931812D75D for ; Mon, 27 Jun 2016 12:11:51 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id g127so72613522ith.0 for ; Mon, 27 Jun 2016 12:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fGqBGvOj2l70i6GjwIdti4LWCJyclud7gDhJPmbk9d4=; b=11DIMnsv/54Qqx6SJhYUz7mJs5MbioeL6pvofc4ZvXuvwtpy8TthtzTsOIL6iYEYc3 ZOAcIFCAYOYStJ4WJCrfEb4pOESUaTGPtpZ3xfGaU7JsyxxqEBt1We1lDn1wo0OMFDLo zBA4abS4V2P60zN7ESZsmWo/6S5wvu/n6G+CwaRpKMmMh93Vp2RY3J+4gLGogy4osTKK VN2NB4V9TrrB62qM1YBckjJh8HqfMRVe2dYYEROP7vhO/52fR6dqRsZWjHXXz+0C3uFV OIU5QoET46C79BnP1RCthm/Pf+pZsIcp6gx8y0uuVSaCraMvGEHSH5D9h33ACy6GklZ3 wBHQ== 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-transfer-encoding; bh=fGqBGvOj2l70i6GjwIdti4LWCJyclud7gDhJPmbk9d4=; b=F2VIMMKzRm1Kb+221ldvyX+e7IcNLK7hgXCrU4kRpNexGb80c0rLA4HsecX7R4Oz9C 0a1gKnddHXvFdNACa2muKZ0NllMX6R+eLkWwOb97QPuj3rjzYuQ6Iqhh6WrhElG1IikV Wmn8haTzo5evGxYUfiLfD5aoSUR5G4BQTWm3PnNy/dIHZ8uRoRbUw4gZUJMi1rWZFmiC 712ofy6ateF++OTUNarAEC0JgWbwQbjVoIrlyb8XBHnFYP/g4ePCWiM81Llh1veCh4rR rx9mwAfKn3Jy2cKI5iQYcmICbfeh/nV+32dNoiQYLf4KnyVZnyAIKqqb4g7qucIIQvkl UNSA== X-Gm-Message-State: ALyK8tKpSDeVwsb9oB5tVHtIZAKMixgZRZk8r1b2SOZCHDn2K9oLQ6bcs+55tFuwFnr9AukGb9KZ6yasnYsiGA== X-Received: by 10.36.16.67 with SMTP id 64mr10382914ity.88.1467054710516; Mon, 27 Jun 2016 12:11:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Mon, 27 Jun 2016 12:11:49 -0700 (PDT) In-Reply-To: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> From: Tom Herbert Date: Mon, 27 Jun 2016 12:11:49 -0700 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Manfredi, Albert E" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:11:53 -0000 On Mon, Jun 27, 2016 at 11:53 AM, Manfredi, Albert E wrote: >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] > >> I think it may raise another interesting question. Does changing a HBH >> option include that it can be removed? And if we do allow to removing >> HBH options would that then allow removing the HBH EH entirely? There >> is a practical aspect to this in that a source network may have good >> support for HBH options and they could be used productively within >> that network, however when packets egress into the Internet we might >> want to strip HBH options and EH to improve reachability of packets. > > Yes, exactly where I'm coming from too. Maybe it needs to be stipulated e= xplicitly, that should any administrative domain's nodes (routers) decide t= o inject extension headers upon ingress, then they must restore the origina= l header upon egress. So the destination thinks the only extension headers = in the packet were those inserted by the source, including the HBH EH. > In the case I am considering it is still only the end host that creates EH. This model would allow forward signaling from hosts to local network nodes (maybe signal L4 state to a FW like being contemplated in PLUS), but doesn't help with packet in the reverse path unfortunately. Tom > Somehow or other, it would be nice if any oddball use of EHs were kept lo= calized to the "consenting adults." > > Bert > From nobody Mon Jun 27 13:15:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EEC12D180 for ; Mon, 27 Jun 2016 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AWOzTS3QOK0U for ; Mon, 27 Jun 2016 13:15:06 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EB512D0FF for ; Mon, 27 Jun 2016 13:15:06 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id i123so64984708pfg.0 for ; Mon, 27 Jun 2016 13:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TLPGwjeiC85eV2ayM72IBlHG6D+y1uYiyB+hBXLZpis=; b=BhbpmEGfrVamlR3WPt9BSHhynUjJ242pDRGoIu7kKKea/M9MFajSjYj2rvMVajLUqG 15Md8CFMlgN5V4JnsFW9fDSHXFuvVgJY1WNjG/d+uRMiZGPXXNZYzn9XSMUn9r4pSqqB Z4IHsRZ6bKEAxctOWEnkGRDH77BGz3NzxSmeXdCYuCYL80FLTdzh8jX59WFe7jyLDZtH Hyt6H0xLXsGCncheZDenvMsMzCrArIYHbb3BJMIfQ6gxKzZGo7XWJrnIkhCHW0MgNzL+ KHR1gViN/DyoosuiYmdiFediB/tFNX4cLEzKGjTg4ooJKzkDCvWIxaa5YVFEERoe2rzi mRZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=TLPGwjeiC85eV2ayM72IBlHG6D+y1uYiyB+hBXLZpis=; b=L18twFeWIW1QamgIOMDDOf/PpU0Dg1j40PtYbzrc4+4g6RduU1MbE/+gz/X9zpSfN3 tcx9VvJDuPsppVqCcSTlod2okDKqqe7hehe0v8u/MILNeBzc8LgI6vT3zUOHhVqKUKO4 zxml6V1VEw/2050HqEHAsGFWHYGeVbi+16p8l33WrnaAvrYHzQOyY95DQmcJ7ohbiwU5 zRZdjJ4W0mIfcv93CRBmfXHngA1kVsDPjW24aTWlD7zTYaSOwRkR+/gc7ckXOVJm7i/1 YFlOpXoZkbFxexEC9NOGlROLYMiQjIF6bkhNT9nJqdOtVeJSyMfCR0KOJcbnBgfyid4o xw8w== X-Gm-Message-State: ALyK8tJIpeVd97WcQ6U5IU4r3s9LVuFcqAn65mNBRv6OfF5uO4L+DEZXjb8l6maVaWDubQ== X-Received: by 10.98.68.84 with SMTP id r81mr36692123pfa.26.1467058506088; Mon, 27 Jun 2016 13:15:06 -0700 (PDT) Received: from [192.168.178.23] ([118.148.70.30]) by smtp.gmail.com with ESMTPSA id ql1sm1889616pac.2.2016.06.27.13.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2016 13:15:05 -0700 (PDT) Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Tom Herbert , "Fred Baker (fred)" References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <407797e5-a170-b088-aad0-6585140b445d@gmail.com> Date: Tue, 28 Jun 2016 08:15:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:15:09 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 28/06/2016 06:30, Tom Herbert wrote: > On Mon, Jun 27, 2016 at 11:15 AM, Fred Baker (fred) wrote: >> >>> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E wrote: >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >>> >>>> OK... suppose all of us here agree that 'no processing' means 'no insertion, >>>> deleting or changing.' How do we ensure that all readers of 2460bis >>>> understand >>>> this from the text? >>> >>> Instead of "processing," why not say "modifying," or maybe even "inspecting and modifying" (with the one exception specified already)? >>> >>> We seem to go around and around on this, because of what "consenting adults" have been known to do, strictly within their own administrative domain. Do we need words to the effect? That seems to be the issue. >> >> My understanding is that section 4.2 explicitly allows an option to be modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting from MSB) is set. An example of such a use case would implement RCP or XCP; the option in the HBH header collects statistical information from the network, and the same option as a destination option returns the result to the sender, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever Effective Window. So this discussion makes me uncomfortable. >> >> We're discussing changing the size or existence of the header, or the set of objects it contains, not the contents of an existing object. Right? >> > I think it may raise another interesting question. Does changing a HBH > option include that it can be removed? And if we do allow to removing > HBH options would that then allow removing the HBH EH entirely? There > is a practical aspect to this in that a source network may have good > support for HBH options and they could be used productively within > that network, however when packets egress into the Internet we might > want to strip HBH options and EH to improve reachability of packets. Any of these things breaks IPsec AH, which has a specific exception for value changes in options but not for length changes. Brian From nobody Mon Jun 27 20:41:38 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A8412DB13 for ; Mon, 27 Jun 2016 20:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SD14ygF2c01c for ; Mon, 27 Jun 2016 20:41:34 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4844C12DB0D for ; Mon, 27 Jun 2016 20:41:34 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j3so5626040vkb.0 for ; Mon, 27 Jun 2016 20:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6sCNqBaW83LQXPIzT/jvz62kWat4AcAauI03UP2bStI=; b=0qKgZNr1+ErgX5gXEchNIqX70jrEKAIQzBLIw7rii04K9OeItTrcvovjgtus9THemY YgiPLUvra5NuUw4hsoZcw5YJ5Tm1BVmw09WtswsnKLmP3Fdc3bhNI1GNYGVfbDX9SXx6 pPUAy7cyOKLzP8I6UUY3GplkJEn3Kh6L2ELLTy3qymyqU6jkxQbDukA5ZMl46bkzDQYJ XXT2uXyEopLWr60ZcYW3LO22qwiy+7yaHGoFpzy7kktOrJab9051QbZ3I4cEWhgYYpwZ fRO+9eDRNIO0R+u2heTq2G1HKuzn7q/JMxbnR/jEN0Tm02MXSsojoeO13OseIJ0GX77a 3//g== 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-transfer-encoding; bh=6sCNqBaW83LQXPIzT/jvz62kWat4AcAauI03UP2bStI=; b=YY0YFKm1rh9yyDR7Q7JZ8BQ2d8y4BJPNU0fupiPcmt3TzgyUwgH6B2fV4/+HAJBqVF OGUdDiDAxh3YBMSqx7ws4ya2yGvwiwLTx780PqoRQvTrf4xdDOEV202/1cRK8v4r4qvM vCjs5Bh2EfF1HuI28MepUpaeaYedQfwKmrL766JidAMw5403cUvdwEqLS3k571NWC3W6 3sSq4MjHCQbgUGw+/j4X4nYUUkprQdwie+/cLKqH6Lb0uNbGMVZcX37YWYkxfzNMaNQO AE2Ltn8m3LVfaWmqkJcez+zchnd8fAyu0ZXeYB0DDkXxBZb7woQtay4QJNwKg1C7qGo8 N7ug== X-Gm-Message-State: ALyK8tKlKOx0uXjZXW1LTB9o0Uzs/bdX2H2CBsblqywNMeDFbB2lyLlKCHGBc3MBTNf4F/wAGnSrSZLKoiN0xA== X-Received: by 10.159.32.67 with SMTP id 61mr347479uam.39.1467085293252; Mon, 27 Jun 2016 20:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.130 with HTTP; Mon, 27 Jun 2016 20:41:03 -0700 (PDT) In-Reply-To: <407797e5-a170-b088-aad0-6585140b445d@gmail.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> <407797e5-a170-b088-aad0-6585140b445d@gmail.com> From: Mark Smith Date: Tue, 28 Jun 2016 13:41:03 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 03:41:37 -0000 On 28 Jun 2016 06:15, "Brian E Carpenter" wro= te: > > > > Regards > Brian Carpenter > http://orcid.org/0000-0001-7924-6182 > > > > On 28/06/2016 06:30, Tom Herbert wrote: > > On Mon, Jun 27, 2016 at 11:15 AM, Fred Baker (fred) wr= ote: > >> > >>> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E wrote: > >>> > >>>> -----Original Message----- > >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpe= nter > >>> > >>>> OK... suppose all of us here agree that 'no processing' means 'no in= sertion, > >>>> deleting or changing.' How do we ensure that all readers of 2460bis > >>>> understand > >>>> this from the text? > >>> > >>> Instead of "processing," why not say "modifying," or maybe even "insp= ecting and modifying" (with the one exception specified already)? > >>> > >>> We seem to go around and around on this, because of what "consenting = adults" have been known to do, strictly within their own administrative dom= ain. Do we need words to the effect? That seems to be the issue. > >> > >> My understanding is that section 4.2 explicitly allows an option to be= modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting f= rom MSB) is set. An example of such a use case would implement RCP or XCP; = the option in the HBH header collects statistical information from the netw= ork, and the same option as a destination option returns the result to the = sender, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever E= ffective Window. So this discussion makes me uncomfortable. > >> > >> We're discussing changing the size or existence of the header, or the = set of objects it contains, not the contents of an existing object. Right? > >> > > I think it may raise another interesting question. Does changing a HBH > > option include that it can be removed? And if we do allow to removing > > HBH options would that then allow removing the HBH EH entirely? There > > is a practical aspect to this in that a source network may have good > > support for HBH options and they could be used productively within > > that network, however when packets egress into the Internet we might > > want to strip HBH options and EH to improve reachability of packets. > > Any of these things breaks IPsec AH, which has a specific exception for > value changes in options but not for length changes. > I haven't seen an explanation as to why EH insertion and removal within a domain, and its associated complexity, is better than tunnelling with the added EH being part of the outer tunnel headers. The more I think about using tunnelling for accommodating adding EHs to pre-existing packets the more it makes sense to me. The encapsulator gets to choose which device sees the added EH by specifying the outer header (unicast, anycast or multicast) destination address (making the packet destinations end-systems or hosts in RFC2460 parlance). Devices that don't have that outer destination address perform standard IPv6 forwarding, remaining oblivious to the addition of the EH (via tunnelling) to the pre-existing packet. If the added EH happens to be a newly defined one, only the set of devices that may be specified as destinations for these tunnel packets need to be upgraded to understand the new EH. These upgraded devices also remain oblivious to any added new EHs if they aren't assigned the packet's outer IP address, meaning simplified and standard IPv6 forwarding for these packets, rather than having to inspect the EH chain of each and every packet they receive for the presence of the new EH. Regards, Mark. > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- N From nobody Tue Jun 28 14:05:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687C12D14F for ; Tue, 28 Jun 2016 14:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c7G6xNkS0xng for ; Tue, 28 Jun 2016 14:05:28 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F9A12D11A for ; Tue, 28 Jun 2016 14:05:27 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id q79so53688350qke.0 for ; Tue, 28 Jun 2016 14:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=6gDKuSZfSHDHYYjLA5XpDiAxS/srKdWSrN7e2SUHA/8=; b=MuTfKtE1b/21Ppk92bsx4EcvaG4FXTbsLsnKCoHmW/QkEzEAWvR5t2NKa13DXHA1iJ CkQ/mNQS9jTp2CUAzfvpYUZsce6NRyS+1QuEz/wBjO2CTRdyWAxuDogpM76/vcVbfzJU ob57YldbZm4tNNKeFSCHGX4n0dzn2Je5zbp/tXWpBpQT58lA4sji3wm7s7BHQP5elgyd h/AkFQhhjsqkD/n9L3cLXWcB2SpbRya8W5Jx7X1k4JvddF6IGzx9faMFug5e1831rEEJ 8KoOz3jxpfN3tHpbq8K+DI37lyxkDqpfqgj4YCwh/ioHVGz/YnfR4obUfq6EkQRkhycA csAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=6gDKuSZfSHDHYYjLA5XpDiAxS/srKdWSrN7e2SUHA/8=; b=NTYwKxBtTgosnbe9gccFaw/VQGcy7vxmnIBgFz2N9PieVG5DxYslTbpTS/ekVRjMHH lZ3E3YLGzDfLeO2fC/8bLf8xX6F8gShT48wsT89yXL71smsGGRqOi6ASwg/EN4AQGeuw UG30GnanBVxK6A3LSZBSkOLSAiAfbv7lrufOWf4iDwPL8Y/5OIPVVT1KLkpn5DtYCFYx deZU+na/9InhPHEkO97a3nGEE/y+LMIGU5vEEN9U0KN3RyP8gAZoxIexsfZ2D4G2iXmA uA1YS20tP/dylfajmKYc5vCGIEHIJLbdXr1RbioXRDFgbdndfyWLi/s1tHyiz8e2Rxmp G2mQ== X-Gm-Message-State: ALyK8tJm2jaXT/cI46X3pHvlJPKcxQGp0Iy6D2eCADOjlbh5w7WK467j1eKEXfFGIDSMAw== X-Received: by 10.37.215.215 with SMTP id o206mr1823050ybg.167.1467147927145; Tue, 28 Jun 2016 14:05:27 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id t125sm152182ywd.0.2016.06.28.14.05.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 14:05:25 -0700 (PDT) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_C8D5D92C-BDC5-4AFF-B1A1-337F7899B35C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: 6MAN Working Group - IETF 96 Berlin Agenda Date: Tue, 28 Jun 2016 14:05:23 -0700 Message-Id: <635134B7-FBEE-4480-9D98-1BE92EB85334@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 21:05:30 -0000 --Apple-Mail=_C8D5D92C-BDC5-4AFF-B1A1-337F7899B35C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft 6man agenda for Berlin is posted: > https://www.ietf.org/proceedings/96/agenda/agenda-96-6man = Bob & Ole --Apple-Mail=_C8D5D92C-BDC5-4AFF-B1A1-337F7899B35C 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 iQEcBAEBCgAGBQJXcuaTAAoJEK7rdBF357uo2sgH/39eSAQQhBcGR+Q8FaH6BvpP MpQsSttJj+tDGUuha/0ddDHEF8/SjSQGpSXuoAEnv+8d2HyUHlckgZC38mkpPYGQ t5sxUpELGgAEXlrcFiv/Txm9mAjzgvSa8nz9cQ5wNYoy/rsLgROcXL7h/emz1D3s prSUr+oLadv5xPh40rFn+a1hHXlJcuRs5mNQmwAVQa8LSvhaCC41DcjPMvtWSvy4 Grl04bl4lefICYO4ymk7erLCyCzJBFkGRobUDWggAjyZl99tcajkZGoc67DhAG1M AD5BSKwvdC1PZxuDSeNvkcuzn0jFWqU+2SFxuseOBaO3XeDjIG7NV9W0lJQjKnw= =2j/j -----END PGP SIGNATURE----- --Apple-Mail=_C8D5D92C-BDC5-4AFF-B1A1-337F7899B35C-- From nobody Tue Jun 28 14:56:05 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE7F12D590; Tue, 28 Jun 2016 14:56:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc2460bis-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628215600.6062.81758.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 14:56:00 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 21:56:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Authors : Stephen E. Deering Robert M. Hinden Filename : draft-ietf-6man-rfc2460bis-05.txt Pages : 37 Date : 2016-06-28 Abstract: This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-05 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 Tue Jun 28 15:06:45 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7712D8F2; Tue, 28 Jun 2016 15:06:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc4291bis-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628220640.6066.35313.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 15:06:40 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:06:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering Filename : draft-ietf-6man-rfc4291bis-03.txt Pages : 30 Date : 2016-06-28 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-03 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 Tue Jun 28 15:20:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C712D916 for ; Tue, 28 Jun 2016 15:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MinBE3YWWux1 for ; Tue, 28 Jun 2016 15:20:55 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B5012D903 for ; Tue, 28 Jun 2016 15:20:55 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g13so29878455ioj.1 for ; Tue, 28 Jun 2016 15:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:date:cc:message-id:references:to; bh=B/fof2ws88hiSHMlsq0MCfyjT6NHhsyF/vLDTjvXVas=; b=pUxELncxYrucNGgyBOjmZ9dh4HfCh7KtWvHSZ8HwhNdaAgipdlGsdadMrSWpWk3HJI Z1/tBDcdzgVG3egfWqn+8+gs4dIRAsx9CuWsbyHUWdeYvjx0MpErGNRHerVTHVAZUEIh enEr79++WWu6rQ9IDdnR5UcdkC4YS4AL/XQfIt6b7377sIkK4ppxde/WvFCVhwdpd6G7 6/j2WqLs5huDpd4jzuCkjla7Jnw2GEWLfTNHorl6rbdHRg/UgLXnY8HdUv2Ii02Zs6Nm sbw/J+YlcU4kJHM8dpAxM/xDxXfAiimCriY8Nr0w9YlW1qqykGcx6TQmBEX9gb0eVUCE 345A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:date:cc:message-id :references:to; bh=B/fof2ws88hiSHMlsq0MCfyjT6NHhsyF/vLDTjvXVas=; b=ZgfITQYouk/AyYQo3cRpYfHDzNG8+V1xwXeRMBiHigSe+MJYTgJD6LjQ7vhrVvFb5F o8htYtWqFDQAZ9Ze1UlKw7hmM+w6QLOIEKD3EVySUKS9Zmyc5SAboMBZ8CqLSMJGULXy qs13P9MZ86IG6ej5wfj528IPAq/rZDXQxGbHbT91UhVN2CgXdrEqCqyh7dSpHRhZ5k6h 1+xR00lCYuo1mbKeTUmQeoQu+WljJDPwcQiQZnPpZ9/+nYWplLXEhFWwEFqT7pNJHX+7 /xgEPQ2gczNMt9F9hHJbI7rCOrTY1swb9EyTaBK0CCK5CFRRGHUU+Ut4r8Xt9sZ7d3yB GEGQ== X-Gm-Message-State: ALyK8tJb5zg/EnXBHfPzMkJ2xr4B2yjzVmcImWtGI0pT08nIDSxlEssLAZ2ln2cSVzYMMg== X-Received: by 10.107.175.161 with SMTP id p33mr5828365ioo.78.1467152454508; Tue, 28 Jun 2016 15:20:54 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r78sm499787ioe.15.2016.06.28.15.20.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 15:20:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_52AACD61-B621-4D9D-8144-91F98928BA8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden Date: Tue, 28 Jun 2016 15:20:50 -0700 Message-Id: <4445544F-119E-4927-BCF6-76A76D23FEDE@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:20:57 -0000 --Apple-Mail=_52AACD61-B621-4D9D-8144-91F98928BA8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new 6man w.g. version (-03) of the RFC4291bis draft. See = links below. The change in this version is: Changes the references in Section 2.4.1 that describes the details of forming IIDs to RFC7217 and RFC7721. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-03 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : IP Version 6 Addressing Architecture > Authors : Robert M. Hinden > Stephen E. Deering > Filename : draft-ietf-6man-rfc4291bis-03.txt > Pages : 30 > Date : 2016-06-28 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-03 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --Apple-Mail=_52AACD61-B621-4D9D-8144-91F98928BA8C 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 iQEcBAEBCgAGBQJXcvhDAAoJEK7rdBF357uoWEUH+QHJXiNR7ZOh4XAHd7D3+ZZ1 0Y7+D4pmoKioXpX4Qf3IEPzVIAu5tjmrRyY4z5dXvdP6F37IIZrN6+cFIm0NCBAK hOQ/7ybtmI6Jknfg7bM1oO1XwgoEYt6divn/EzqpvNnVnhg1TwOaaautHYZXH99a DDFUZ4pqaTORly5AKE2krawikqLxrARblcjBPbv+mLM9H2YnzuNGiPOSdNtV4wmQ yqqTPSufJDci9azH9S+Mx7PIT4AGYM/+Tqeae+enJlbdLuMHpDDuW36JEvmhz2HW vRuY5cCjnqKnrVTyDD+O60TC7qjRwbYUsMezU7nFeNlryeJKK669n/vc6C+V2tU= =4M5K -----END PGP SIGNATURE----- --Apple-Mail=_52AACD61-B621-4D9D-8144-91F98928BA8C-- From nobody Tue Jun 28 15:26:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CFE12D913; Tue, 28 Jun 2016 15:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 f-8u_VVljjtP; Tue, 28 Jun 2016 15:26:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6713012D937; Tue, 28 Jun 2016 15:25:47 -0700 (PDT) Received: from localhost ([::1]:44247 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bI1Ry-0006ir-Uw; Tue, 28 Jun 2016 15:25:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc4291bis@ietf.org, bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 28 Jun 2016 22:25:46 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #14 (rfc4291bis): Reference to default-iid X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/14#comment:2 Message-ID: <078.cfadb4ec5572ebeb8d6ef6727129b577@trac.tools.ietf.org> References: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <063.ca4bfbe22c449021ab7b3479179a59ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc4291bis@ietf.org, bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc4291bis@ietf.org Resent-Message-Id: <20160628222547.6713012D937@ietfa.amsl.com> Resent-Date: Tue, 28 Jun 2016 15:25:47 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:26:16 -0000 #14: Reference to default-iid Comment (by bob.hinden@gmail.com): Change to fix this published in draft-ietf-6man-rfc4291bis-03.txt . -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc4291bis@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc4291bis | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jun 28 15:31:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DC12D86D for ; Tue, 28 Jun 2016 15:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 f135_ZaRJR7Y for ; Tue, 28 Jun 2016 15:31:49 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB63B12D89A for ; Tue, 28 Jun 2016 15:31:48 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id j2so2001617qkf.3 for ; Tue, 28 Jun 2016 15:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=etHPH6qRt22ZpeOUajkRXYHzPlIdrelX2c/edvmMlDs=; b=hLGn/hp4sp50TXy/1CnieUcAnlD2zziB2Syzrx7LWgRMBCAQeXlPWYzB/YNcZz1/jJ Fi3ySAsBSibGUrozbBvxbucImNBEGfx42Jgwya4ARoWI24uwYtqR/fpvC1CfGZj1+Zfd A8JuXhyZujSvUU5P1dD4SG9CgBqQjdgi1MuIVeTQFKk0OknKjOcy/8Lb2yGfhrRnI1bO 3jSdTFZ5HG/HgbKotNAdc0dSAGE+gOQZZgZ+vkZLdgmCMhfd7ac/CPZFizmCePS+Q+kO jzhNHeYgr5O2U4BUCF6hEtOgahSvw+BBWIgcsFVo05L8UNgf/8teocUN/5CXokj+jN+e JEdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=etHPH6qRt22ZpeOUajkRXYHzPlIdrelX2c/edvmMlDs=; b=WlGcxV4YvmR6VZUGhTNGBaCVA/fPGlDxwhllBdet4Lz577PL7iKbt5cGafHGiZizSE ztARdB9PmMVMGN3m5p9ERD5cSfAKg6F99m/ZINQr6aXjtT0G1sVNXbkgiKhVP6YMDurw EDzaHIE6IyZWqwSBdebKzB0FvjXdxpiMDZwS1o7SiAZI9YDnsxyZgohcmeiQqnYfNbF/ yKJPjM+i2KTDGL7/Stvrxa1kYqJOQt/sxIQV0ztr8cg7vxpG7ezxuBCbgJfUUpZAq/WQ ojlpO6BHKgXRxE4wVdmF5TQd5FagRrhh9Lt6MzmSXKOMnhZl09/f+mYGcusDzAr+5sJ7 Qp0w== X-Gm-Message-State: ALyK8tL4auUWPsjpnXUvAwYUIyPtPmpYfjJraGMAFAHvEH1APSHWaqrnn0sGpLGsf/Pf9g== X-Received: by 10.13.207.129 with SMTP id r123mr2155445ywd.274.1467153107836; Tue, 28 Jun 2016 15:31:47 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a83sm323101ywe.2.2016.06.28.15.31.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 15:31:47 -0700 (PDT) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_EA2C08C5-C59B-4D7D-800B-9D7C4815AC76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Date: Tue, 28 Jun 2016 15:31:45 -0700 Message-Id: <2E5A19A4-41C2-4967-ADF4-475E98FBCC03@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:31:53 -0000 --Apple-Mail=_EA2C08C5-C59B-4D7D-800B-9D7C4815AC76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the -05 version of 6man working group draft of rfc2460bis. = Links below. The changes include: Changed requirement for HBH header from a should to a may, and added a note to indicate what is expected. Corrected reference to point to draft-ietf-6man-rfc4291bis instead of draft-hinden-6man-rfc4291bis. Change to text regarding not inserting extension headers to cite using encapsulation as an example. A diff from the -04 version can be found at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-05 Please review the changes. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : Internet Protocol, Version 6 (IPv6) = Specification > Authors : Stephen E. Deering > Robert M. Hinden > Filename : draft-ietf-6man-rfc2460bis-05.txt > Pages : 37 > Date : 2016-06-28 >=20 > Abstract: > This document specifies version 6 of the Internet Protocol (IPv6). > It obsoletes RFC2460 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-05 --Apple-Mail=_EA2C08C5-C59B-4D7D-800B-9D7C4815AC76 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 iQEcBAEBCgAGBQJXcvrRAAoJEK7rdBF357uodwkH/3ixQAM6EeZFzcR/HNQqpFJB py6ezHUybcbYw7X6zxF6d6ZFeM1g3Z8LL6wqp+5yzoVGDpTAqkCtjZ3EYIvCHyVJ uN11FHumQKm59U1rgvamoCmi0bWNBYWsAnulxGsBUGB2Vkx9uXdihQeYBLFJTbhh DiLtLB9X0x2T4TQEfX8NJtFY6vQdQtnVQxgoA/2jqbQ6P47BUcYA7SBq6xNh+3gg ZRQ+Hx7uNWZ4MlvYD6Z7tx5JWOXaz9gvsCN9I0x8Qr34Yx0EypDQi53tFZ5CtvcQ FVoR0y/wKlijFkx8V8ZfGkBlA2DFklkMf4twCfCFWcfzF36BTf95ngYdZT4w8cQ= =7ThF -----END PGP SIGNATURE----- --Apple-Mail=_EA2C08C5-C59B-4D7D-800B-9D7C4815AC76-- From nobody Tue Jun 28 15:32:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8584512D854 for ; Tue, 28 Jun 2016 15:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 2iq89E6tqnVZ for ; Tue, 28 Jun 2016 15:32:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7692C12D590 for <6man@ietf.org>; Tue, 28 Jun 2016 15:32:49 -0700 (PDT) Received: from localhost ([::1]:44444 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bI1Ym-00044S-Ro; Tue, 28 Jun 2016 15:32:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 28 Jun 2016 22:32:48 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #9 (rfc2460bis): Header injection issue X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/9#comment:1 Message-ID: <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:32:51 -0000 #9: Header injection issue Comment (by bob.hinden@gmail.com): Proposed text in draft-ietf-6man-rfc2460bis-05.txt. -- ----------------------------------+------------------ Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+------------------ Ticket URL: 6man From nobody Tue Jun 28 15:33:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CC112D90B for ; Tue, 28 Jun 2016 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 yiKd0-CP5xpj for ; Tue, 28 Jun 2016 15:33:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C17912D590 for <6man@ietf.org>; Tue, 28 Jun 2016 15:33:27 -0700 (PDT) Received: from localhost ([::1]:44454 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bI1ZP-0006OM-4J; Tue, 28 Jun 2016 15:33:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: bob.hinden@gmail.com X-Trac-Project: 6man Date: Tue, 28 Jun 2016 22:33:27 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #11 (rfc2460bis): HBH header handling X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/11#comment:1 Message-ID: <078.b70391eeea198d6cbe0b8fbd06d89fb4@trac.tools.ietf.org> References: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <063.aca6a5e1e9dd0002f4ae621ecbec293f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bob.hinden@gmail.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:33:31 -0000 #11: HBH header handling Comment (by bob.hinden@gmail.com): Changes published in draft-ietf-6man-rfc2460bis-05.txt. -- ----------------------------------+------------------ Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+------------------ Ticket URL: 6man From nobody Tue Jun 28 15:43:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE49512D932 for ; Tue, 28 Jun 2016 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G7bbnfnjkl3D for ; Tue, 28 Jun 2016 15:42:58 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDD212D8C2 for <6man@ietf.org>; Tue, 28 Jun 2016 15:42:47 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f6so27316703ith.0 for <6man@ietf.org>; Tue, 28 Jun 2016 15:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=X2D/KeeGVP3ChH+t+CRCA5K1xfLc8TgUcfMHrpkLKFU=; b=LV3dDoJwscL/eu2hpVqwfDN7SBWHKNj7+Zo01hxWTdYkOspP5NcXQl57mLY7vxZTz3 kSKJaN0KCF8P7hOZCfIFhDPRxpJITt1XJI2WJLsz/VVd00rHdmlnh2J/9bE3owXM2dqr 4PBE0r9/4jl5XhmmOpGHKN7yE/R51gy9ZcY+Zn4Py/jeIPNokoQSqfS50v/mJodh+w7I fmw60H++KAlApgb1+NhrypMUff54LOor/geFFF09X4tbH6h3kDYuXESOym48zZFmj486 CZRR1exJAQZs/ED44QpCUrIkJH9oDG5hqCKmpRGVNlI5xwFnd0be5xLfjYoyaVfFggxY wUFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=X2D/KeeGVP3ChH+t+CRCA5K1xfLc8TgUcfMHrpkLKFU=; b=gC5JDydqu7I5Cwq4lWSAoOiSKCa0gtg08i15b0Hrbaw+clerxTVdBsXSQ57N2Nh3IR +g9fMDy13WRaRvQZe2ES04UYr/IF3jEh1ELhR8ijyQ78AYX88cfpLkayZOQugcWYxuCh w2AuAji2MV3t0YB2zC4h5T05nICnOZe614NLZ8baWIime42UCR0jr+bhSBsoLcgl7QaN 8A9WyWa2hP1makIID2YVTFZN+weWfcJrkGmdUY6Ecm5FlTXj1fKSUBbxBsIRtouoXM6r 1O3++ilbSuQ/24+69/bpvJWMOilfFSeB3bnxqhLlX+5JcfryyWYwale5GqfJuyaNtEeT Jyew== X-Gm-Message-State: ALyK8tJRVgw8SkwfCvzF+xH+qtHr9tX7kxLgku7wRz0/InEdiTVTW5TgAgG+6kgHU82Dcg== X-Received: by 10.36.71.143 with SMTP id t137mr6389322itb.0.1467153767070; Tue, 28 Jun 2016 15:42:47 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id p102sm536399ioi.7.2016.06.28.15.42.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 15:42:46 -0700 (PDT) Subject: Re: [6man] #9 (rfc2460bis): Header injection issue Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BFE757CF-4CA1-45C4-BDD9-D64C8B21767E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> Date: Tue, 28 Jun 2016 15:42:44 -0700 Message-Id: <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> To: 6man@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:43:01 -0000 --Apple-Mail=_BFE757CF-4CA1-45C4-BDD9-D64C8B21767E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The text I published in draft-ietf-6man-rfc2460bis-05.txt is: The insertion of Extension Headers by any node other than the source of the packet breaks PMTU-discovery and can result in ICMP error messages being sent to the source of the packet that did not insert the header. The current approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473]. After reviewing the mailing list discussion, I think this describes the = issue and the current defined solution. At the same time, it doesn=E2=80=99= t prohibit other solutions to inserting extension headers in the future. My take is that this is about the best we can do given the range of the = views in the working group. I think it is much better than saying = nothing. I don=E2=80=99t think we can get a consensus on anything = significantly stronger. Comments? Bob > On Jun 28, 2016, at 3:32 PM, 6man issue tracker = wrote: >=20 > #9: Header injection issue >=20 >=20 > Comment (by bob.hinden@gmail.com): >=20 > Proposed text in draft-ietf-6man-rfc2460bis-05.txt. >=20 > -- > ----------------------------------+------------------ > Reporter: otroan@employees.org | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: rfc2460bis | Version: > Severity: In WG Last Call | Resolution: > Keywords: | > ----------------------------------+------------------ >=20 > Ticket URL: = > 6man >=20 --Apple-Mail=_BFE757CF-4CA1-45C4-BDD9-D64C8B21767E 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 iQEcBAEBCgAGBQJXcv1kAAoJEK7rdBF357uoctQIAKOangFxvKfcY8hIwrE1CbrR hb9TNRJUhvKAu2EeiljD61YErp9mUELzDKAx4bVtRCvv7Xk4/OuZc7Tl62RSeQfw LbzSwHSIGLBsKzIyRzeckwmjLnInh6zaBRlqXgrRQtTZuJMzZ4Ven/hgKcLK2bUh BKNyMm1BkNi0TCV2EqO/HuO+IJ0Ttc0o0Yt6S2v461KocBZNSsmRtKFPNaBCVH23 aOSjGkIvNU1UPud5iurGlScLneQjfckFuhzO/qPRpMzbggzKAuzn7voIPGQx+azc uyKoEdVp/2fGblO7cA2AuIYLFg6dAMN6+8F31ItJnri7G5OejknB43lwkLA81B8= =ACvF -----END PGP SIGNATURE----- --Apple-Mail=_BFE757CF-4CA1-45C4-BDD9-D64C8B21767E-- From nobody Tue Jun 28 15:48:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317C912D8A3 for ; Tue, 28 Jun 2016 15:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Drh4BV_hQwlv for ; Tue, 28 Jun 2016 15:48:25 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 6A3E212B04D for <6man@ietf.org>; Tue, 28 Jun 2016 15:48:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5SMmP2B029858; Tue, 28 Jun 2016 15:48:25 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5SMmOYZ029849 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2016 15:48:24 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Jun 2016 15:48:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Tue, 28 Jun 2016 15:48:23 -0700 From: "Manfredi, Albert E" To: Bob Hinden , "6man@ietf.org" <6man@ietf.org> Subject: RE: [6man] #9 (rfc2460bis): Header injection issue Thread-Topic: [6man] #9 (rfc2460bis): Header injection issue Thread-Index: AQHR0Y0VijvhA4ll/EONQPdMHfuxZp//7wMA//+LlPA= Date: Tue, 28 Jun 2016 22:48:23 +0000 Message-ID: References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> In-Reply-To: <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:48:27 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEhpbmRlbg0KDQo+IEhpLA0KPiANCj4g VGhlIHRleHQgSSBwdWJsaXNoZWQgaW4gZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDUudHh0 IGlzOg0KPiANCj4gICAgVGhlIGluc2VydGlvbiBvZiBFeHRlbnNpb24gSGVhZGVycyBieSBhbnkg bm9kZSBvdGhlciB0aGFuIHRoZSBzb3VyY2UNCj4gICAgb2YgdGhlIHBhY2tldCBicmVha3MgUE1U VS1kaXNjb3ZlcnkgYW5kIGNhbiByZXN1bHQgaW4gSUNNUCBlcnJvcg0KPiAgICBtZXNzYWdlcyBi ZWluZyBzZW50IHRvIHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCB0aGF0IGRpZCBub3QgaW5zZXJ0 DQo+ICAgIHRoZSBoZWFkZXIuDQo+IA0KPiAgICBUaGUgY3VycmVudCBhcHByb2FjaCB0byBhbGxv d2luZyBhIGhlYWRlciB0byBiZSBpbnNlcnRlZCBpcyB0bw0KPiAgICBlbmNhcHN1bGF0ZSB0aGUg cGFja2V0IHVzaW5nIGFub3RoZXIgSVB2NiBoZWFkZXIgYW5kIGluY2x1ZGluZyB0aGUNCj4gICAg YWRkaXRpb25hbCBleHRlbnNpb24gaGVhZGVyIGFmdGVyIHRoZSBmaXJzdCBJUHY2IGhlYWRlciwg Zm9yIGV4YW1wbGUsDQo+ICAgIGFzIGRlZmluZWQgaW4gW1JGQzI0NzNdLg0KPiANCj4gQWZ0ZXIg cmV2aWV3aW5nIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGlzIGRlc2Ny aWJlcyB0aGUgaXNzdWUNCj4gYW5kIHRoZSBjdXJyZW50IGRlZmluZWQgc29sdXRpb24uICBBdCB0 aGUgc2FtZSB0aW1lLCBpdCBkb2VzbuKAmXQgcHJvaGliaXQNCj4gb3RoZXIgc29sdXRpb25zIHRv IGluc2VydGluZyBleHRlbnNpb24gaGVhZGVycyBpbiB0aGUgZnV0dXJlLg0KDQpXaGF0IGFib3V0 IEJyYWluIEMncyBwb2ludCB0aGF0IGl0IGJyZWFrcyBJUHNlYyBhdXRoZW50aWNhdGlvbiB0b28/ IEkgbWVhbiwgYXMgbG9uZyBhcyB3ZSBsaXN0IFBNVFUsIHdlIG1pZ2h0IGluZGljYXRlIElQc2Vj ICJhbmQgb3RoZXIsIiBwZXJoYXBzPw0KDQpCZXJ0DQoNCg== From nobody Tue Jun 28 18:07:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18312D63C for ; Tue, 28 Jun 2016 18:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RZqyzZ39XZ-D for ; Tue, 28 Jun 2016 18:07:07 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC54F12D9A9 for <6man@ietf.org>; Tue, 28 Jun 2016 18:07:02 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id k62so35931423vkb.3 for <6man@ietf.org>; Tue, 28 Jun 2016 18:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BXaA/B5dN5w0o5kduH/IR9di8mSTp96173kR/S4w/90=; b=GliaHzLXcM8ETuitxVVWl2H2vQed30sVg87HFn2tyGmgk5xc9QKMNsVZBY/zMEemys TVEZcepFP7lbXeRHixNXcUkNu5cjFyLkMUXlNqUv8sVar3DQrh1MCjf2EmCJ+p+xq6lD GOuCzWh3fz3ohNlHasc1SC1eM6qAkgWybU/UfXzsO+5d2SR+DGfHzhFIPXTNv07l91GP D3qzi5Cg+o3ivB4KOgzRyICYERIHoSTamuh7P99ZgiJmVJJxlSQk8YDQoM5DR0wbIPNB XVRD9odZaLDAIvybdjxrB/Or0l1kYQL8xoUTR2kjrDKY5svpoNESMQ5dUtrtffO7GzWy opig== 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:date :message-id:subject:from:to:cc; bh=BXaA/B5dN5w0o5kduH/IR9di8mSTp96173kR/S4w/90=; b=LTvj+VgzRXBGbYM3KZDW5Su4K6NOhq6llsTMq3XQQRVasDNhqOJMrGfK1FVMvk2zdv JQVPto7MyQ/PqheE/qlfVwgngtJxXTUaP5g6eqJodOKzPliZpkSIZKSLDBylpZ3gSnqF 8jlbK3312kX31AWfdCyv2ibQ4JNG1yZZ5orOREiuhKRhibuZyqfaE5u+PoiyBrPBWwBv 85q3b6NrXXjs5lGuJ3sUJNvoki92lNwxKTi84CqVw0O9gXB+SbAL5IlFEcX1M3omltlG q/35aHtVWnPIRcB7R+4/tijzgs6kXXKdox3QaCWxlwqh07uXF76szrKIsh92UexYYiIv qaiA== X-Gm-Message-State: ALyK8tIzW3AcnOykLjzpnWkW6/jm3YZdJaACotgKa3LCHuG+sVnXjgHTnS5DxyxW+Heozte6oE/1pDZQgaTvGA== MIME-Version: 1.0 X-Received: by 10.31.63.129 with SMTP id m123mr2314013vka.149.1467162422056; Tue, 28 Jun 2016 18:07:02 -0700 (PDT) Received: by 10.159.39.130 with HTTP; Tue, 28 Jun 2016 18:07:01 -0700 (PDT) Received: by 10.159.39.130 with HTTP; Tue, 28 Jun 2016 18:07:01 -0700 (PDT) In-Reply-To: References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> Date: Wed, 29 Jun 2016 11:07:01 +1000 Message-ID: Subject: RE: [6man] #9 (rfc2460bis): Header injection issue From: Mark Smith To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=001a114d9af2fe9fd30536605efe Archived-At: Cc: 6man@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 01:07:09 -0000 --001a114d9af2fe9fd30536605efe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 Jun 2016 8:48 AM, "Manfredi, Albert E" wrote: > > > -----Original Message----- > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > > > Hi, > > > > The text I published in draft-ietf-6man-rfc2460bis-05.txt is: > > > > The insertion of Extension Headers by any node other than the source > > of the packet breaks PMTU-discovery and can result in ICMP error > > messages being sent to the source of the packet that did not insert > > the header. > > > > The current approach to allowing a header to be inserted is to > > encapsulate the packet using another IPv6 header and including the > > additional extension header after the first IPv6 header, for example= , > > as defined in [RFC2473]. > > > > After reviewing the mailing list discussion, I think this describes the issue > > and the current defined solution. At the same time, it doesn=E2=80=99t= prohibit > > other solutions to inserting extension headers in the future. > > What about Brain C's point that it breaks IPsec authentication too? I mean, as long as we list PMTU, we might indicate IPsec "and other," perhaps= ? > Actually, tunnel mode IPsec is another example of how to add EHs to a pre-existing packet. It's a little different to the RFC2473 example above because adding at least one IPsec EH is of course necessary to perform IPsec functions. Regards, Mark. > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a114d9af2fe9fd30536605efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Jun 2016 8:48 AM, "Manfredi, Albert E" <albert.e.manfredi@boeing.com> wrote:=
>
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-= bounces@ietf.org] On Behalf Of Bob Hinden
>
> > Hi,
> >
> > The text I published in draft-ietf-6man-rfc2460bis-05.txt is:
> >
> >=C2=A0 =C2=A0 The insertion of Extension Headers by any node other= than the source
> >=C2=A0 =C2=A0 of the packet breaks PMTU-discovery and can result i= n ICMP error
> >=C2=A0 =C2=A0 messages being sent to the source of the packet that= did not insert
> >=C2=A0 =C2=A0 the header.
> >
> >=C2=A0 =C2=A0 The current approach to allowing a header to be inse= rted is to
> >=C2=A0 =C2=A0 encapsulate the packet using another IPv6 header and= including the
> >=C2=A0 =C2=A0 additional extension header after the first IPv6 hea= der, for example,
> >=C2=A0 =C2=A0 as defined in [RFC2473].
> >
> > After reviewing the mailing list discussion, I think this describ= es the issue
> > and the current defined solution.=C2=A0 At the same time, it does= n=E2=80=99t prohibit
> > other solutions to inserting extension headers in the future.
>
> What about Brain C's point that it breaks IPsec authentication too= ? I mean, as long as we list PMTU, we might indicate IPsec "and other,= " perhaps?
>

Actually, tunnel mode IPsec is another example of how to add= EHs to a pre-existing packet.

It's a little different to the RFC2473 example above bec= ause adding at least one IPsec EH is of course necessary to perform IPsec f= unctions.

Regards,
Mark.

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

--001a114d9af2fe9fd30536605efe-- From nobody Wed Jun 29 10:14:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3978012B017 for ; Wed, 29 Jun 2016 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 9JFr6AucGG7p for ; Wed, 29 Jun 2016 10:14:28 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746EF12B00C for ; Wed, 29 Jun 2016 10:14:28 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id g127so123222235ith.0 for ; Wed, 29 Jun 2016 10:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zZQNGqQxIIM0TBsIHXgFwawZ6GA1QHWadVOrQTOG1to=; b=BCLVxfzVrjHGblEASXeqxmDHujNTxVbmJBIEcNwjLJuyrTrEYyjxyzsW1ON2rg6jHx smtsUcbLRcakxopMJ/qNUyIRSAftHPJAaVFnFKiopcm8KNVk9qR1VaY1TybMLFt6Z6QW vGedlOFOu8wTXuuhm1MKiaiQzU2AVzjfDzlPjm2i54LcU37HPWa72Zd9csShzKDEXMky 68WkvZg8sRZvdSD70CtiepIrX+eaxEp2KDBH5CSZg+nQ84xtliDGWSZMqw2mkO5oTYKR ks2xvUff5vwHAdnVZTIJb2h54UKc3ZSDlf+5DwnToqL4mrPOXsYQz+ln5HN32yXVKTM/ oBMg== 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-transfer-encoding; bh=zZQNGqQxIIM0TBsIHXgFwawZ6GA1QHWadVOrQTOG1to=; b=JDnA2IxmfxLzKQTIO6LrdD3DdA45KohheBOATsEFbmiSUYoR2x2sOLodxXveHdRiOn brgYxbwtgWR2DLunZ74J4RPiSjMJPpxRiZX5Ytn14vLue+PAFb+KgFqLnZYZtUzZxhVW 6Qj8L3jaK3q9BNRi/vpU7wyI7E2CKPPkjWRM/qrJDkwWojwNo7tsS4CEUojfyxsraJmZ v3dVLRhtHlV3gcRlC/m6vFnyKTSextBCWdz1+5RAyW7ZNQryzHoXbZBvLuinDYNf6u4b 8GzYtvc+yzp3vlT+ShzvxWB4UqASq0iRizsTCcG2TLopm0cPBbhQpuTXip2HtDIZbDAB YpoA== X-Gm-Message-State: ALyK8tLv7BjnZVZLbLMi+HzSYjeCKtjha6S95/DmlleOoaiYFR0hfBcKElvTGKeibG5K66yLS4vPs/fowb3zhA== X-Received: by 10.36.16.67 with SMTP id 64mr10949087ity.88.1467220467431; Wed, 29 Jun 2016 10:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 29 Jun 2016 10:14:26 -0700 (PDT) In-Reply-To: References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> <407797e5-a170-b088-aad0-6585140b445d@gmail.com> From: Tom Herbert Date: Wed, 29 Jun 2016 10:14:26 -0700 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: Mark Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:14:31 -0000 On Mon, Jun 27, 2016 at 8:41 PM, Mark Smith wrote: > On 28 Jun 2016 06:15, "Brian E Carpenter" w= rote: >> >> >> >> Regards >> Brian Carpenter >> http://orcid.org/0000-0001-7924-6182 >> >> >> >> On 28/06/2016 06:30, Tom Herbert wrote: >> > On Mon, Jun 27, 2016 at 11:15 AM, Fred Baker (fred) w= rote: >> >> >> >>> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E wrote: >> >>> >> >>>> -----Original Message----- >> >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carp= enter >> >>> >> >>>> OK... suppose all of us here agree that 'no processing' means 'no i= nsertion, >> >>>> deleting or changing.' How do we ensure that all readers of 2460bis >> >>>> understand >> >>>> this from the text? >> >>> >> >>> Instead of "processing," why not say "modifying," or maybe even "ins= pecting and modifying" (with the one exception specified already)? >> >>> >> >>> We seem to go around and around on this, because of what "consenting= adults" have been known to do, strictly within their own administrative do= main. Do we need words to the effect? That seems to be the issue. >> >> >> >> My understanding is that section 4.2 explicitly allows an option to b= e modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting = from MSB) is set. An example of such a use case would implement RCP or XCP;= the option in the HBH header collects statistical information from the net= work, and the same option as a destination option returns the result to the= sender, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever = Effective Window. So this discussion makes me uncomfortable. >> >> >> >> We're discussing changing the size or existence of the header, or the= set of objects it contains, not the contents of an existing object. Right? >> >> >> > I think it may raise another interesting question. Does changing a HBH >> > option include that it can be removed? And if we do allow to removing >> > HBH options would that then allow removing the HBH EH entirely? There >> > is a practical aspect to this in that a source network may have good >> > support for HBH options and they could be used productively within >> > that network, however when packets egress into the Internet we might >> > want to strip HBH options and EH to improve reachability of packets. >> >> Any of these things breaks IPsec AH, which has a specific exception for >> value changes in options but not for length changes. >> > > I haven't seen an explanation as to why EH insertion and removal > within a domain, and its associated complexity, is better than > tunnelling with the added EH being part of the outer tunnel headers. > I think it could be argued that tunneling incurs additional overhead, complexity, and is not transparent which could be an undue burden. For example, consider the mobile wireless case where we want bi-directional signaling between the host and network to indicate network-layer characteristics of the wireless link (something like a generalization of draft-flinck-mobile-throughput-guidance-03.txt). If we are able to use HBH options for this use case then host application will be able to easily set HBH options on a socket for setting on the sending path. The local network can consume this information and can strip the options from the packets when they egress the network-- this limits information exposure and avoids the possibility that some third party device in the Internet drops the packet because of HBH. On ingress into the network, a network device could insert EH for consumption by the end host. The local network can be engineered so that the enlarged packet will still fit into any MTU. If we try to get the same effect with encapsulation, this requires significant changes on the mobile client. Tunneling doesn't "just work", it needs specific implementation and configuration. We would need encapsulation/decapsulation enabled (probably kernel needs to be involved) and selection of the destination address in the encapsulation may be non-trivial, especially if we want the destination to be the egress router corresponding to the best one for the actual destination. Also, the forty bytes of overhead for the additional IP header in every packet may be significant overhead in some domains. Tom From nobody Wed Jun 29 10:36:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9287B12DD89 for ; Wed, 29 Jun 2016 10:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rP4pjaP0cp2y for ; Wed, 29 Jun 2016 10:36:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8A512DDB6 for ; Wed, 29 Jun 2016 10:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6926; q=dns/txt; s=iport; t=1467221780; x=1468431380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kd2FqTdC7hxN7C0cjL8WwZb06rVX3hwlbXLvnn6ddRI=; b=UNlTTMz+LGUYJpeHEN85C6GKDWIeG+mpZUSjytamG4jeZtVEqQk8KeFI krjhHIZCZLQBWFkGIdBonvBWjSmdxFi4rmBFBhboY7finyDxRlxvVc9Kz a+2Rljlo3IXDOCDawgaVK63oR0hanx5MHpykkGsdHCnF6PMki2tedjo36 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgDsBXRX/5NdJa1agz5WfQatNYwOg?= =?us-ascii?q?XsXC4V2AhyBFjgUAQEBAQEBAWUnhEwBAQEDAQEBASAROgsFBwQCAQgVAwICIwM?= =?us-ascii?q?CAgIfBgsUARACBA4FG4d7Aw8IDrNejAANhBoBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEcgQGFJ4F3CIJOgTkBgQmBbQMNF4JqK4IvBYgWkDs0AYYHhiyCCoI3jG6IEYd?= =?us-ascii?q?xAR42ghWBW24Bh3tDfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208";a="291445325" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 17:36:18 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5THaIaw028615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 17:36:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 13:36:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 13:36:17 -0400 From: "Carlos Pignataro (cpignata)" To: Mark Smith Subject: Re: RFC2460bis - Ticket #9 - Header injection issue Thread-Topic: RFC2460bis - Ticket #9 - Header injection issue Thread-Index: AQHR0iy9ZIjnCvxYFUGbPjc6XO0Yxw== Date: Wed, 29 Jun 2016 17:36:17 +0000 Message-ID: <1A85BA2A-6507-4D04-A18B-FF57BCD05A87@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> <407797e5-a170-b088-aad0-6585140b445d@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.50.171] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 6man WG , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:36:23 -0000 DQo+IE9uIEp1biAyNywgMjAxNiwgYXQgMTE6NDEgUE0sIE1hcmsgU21pdGggPG1hcmt6enpzbWl0 aEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMjggSnVuIDIwMTYgMDY6MTUsICJCcmlhbiBF IENhcnBlbnRlciIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+ IA0KPj4gDQo+PiBSZWdhcmRzDQo+PiAgIEJyaWFuIENhcnBlbnRlcg0KPj4gICBodHRwOi8vb3Jj aWQub3JnLzAwMDAtMDAwMS03OTI0LTYxODINCj4+IA0KPj4gDQo+PiANCj4+IE9uIDI4LzA2LzIw MTYgMDY6MzAsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPj4+IE9uIE1vbiwgSnVuIDI3LCAyMDE2IGF0 IDExOjE1IEFNLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20+IHdyb3RlOg0KPj4+ PiANCj4+Pj4+IE9uIEp1biAyMSwgMjAxNiwgYXQgMzo1MSBQTSwgTWFuZnJlZGksIEFsYmVydCBF IDxhbGJlcnQuZS5tYW5mcmVkaUBib2VpbmcuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQo+Pj4+PiAN Cj4+Pj4+PiBPSy4uLiBzdXBwb3NlIGFsbCBvZiB1cyBoZXJlIGFncmVlIHRoYXQgJ25vIHByb2Nl c3NpbmcnIG1lYW5zICdubyBpbnNlcnRpb24sDQo+Pj4+Pj4gZGVsZXRpbmcgb3IgY2hhbmdpbmcu JyBIb3cgZG8gd2UgZW5zdXJlIHRoYXQgYWxsIHJlYWRlcnMgb2YgMjQ2MGJpcw0KPj4+Pj4+IHVu ZGVyc3RhbmQNCj4+Pj4+PiB0aGlzIGZyb20gdGhlIHRleHQ/DQo+Pj4+PiANCj4+Pj4+IEluc3Rl YWQgb2YgInByb2Nlc3NpbmcsIiB3aHkgbm90IHNheSAibW9kaWZ5aW5nLCIgb3IgbWF5YmUgZXZl biAiaW5zcGVjdGluZyBhbmQgbW9kaWZ5aW5nIiAod2l0aCB0aGUgb25lIGV4Y2VwdGlvbiBzcGVj aWZpZWQgYWxyZWFkeSk/DQo+Pj4+PiANCj4+Pj4+IFdlIHNlZW0gdG8gZ28gYXJvdW5kIGFuZCBh cm91bmQgb24gdGhpcywgYmVjYXVzZSBvZiB3aGF0ICJjb25zZW50aW5nIGFkdWx0cyIgaGF2ZSBi ZWVuIGtub3duIHRvIGRvLCBzdHJpY3RseSB3aXRoaW4gdGhlaXIgb3duIGFkbWluaXN0cmF0aXZl IGRvbWFpbi4gRG8gd2UgbmVlZCB3b3JkcyB0byB0aGUgZWZmZWN0PyBUaGF0IHNlZW1zIHRvIGJl IHRoZSBpc3N1ZS4NCj4+Pj4gDQo+Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzZWN0aW9u IDQuMiBleHBsaWNpdGx5IGFsbG93cyBhbiBvcHRpb24gdG8gYmUgbW9kaWZpZWQvY2hhbmdlZC93 aGF0ZXZlci1pdCdzLWNhbGxlZCBpbiBmbGlnaHQgaWYgYml0IDIgKDAsMSwyIGNvdW50aW5nIGZy b20gTVNCKSBpcyBzZXQuIEFuIGV4YW1wbGUgb2Ygc3VjaCBhIHVzZSBjYXNlIHdvdWxkIGltcGxl bWVudCBSQ1Agb3IgWENQOyB0aGUgb3B0aW9uIGluIHRoZSBIQkggaGVhZGVyIGNvbGxlY3RzIHN0 YXRpc3RpY2FsIGluZm9ybWF0aW9uIGZyb20gdGhlIG5ldHdvcmssIGFuZCB0aGUgc2FtZSBvcHRp b24gYXMgYSBkZXN0aW5hdGlvbiBvcHRpb24gcmV0dXJucyB0aGUgcmVzdWx0IHRvIHRoZSBzZW5k ZXIsIHdoaWNoIHRoZW4gdXNlcyBpdCBpbiB0aGUgZXZvbHV0aW9uIG9mIHRoZSBUQ1AvU0NUUC9R VUlDL3doYXRldmVyIEVmZmVjdGl2ZSBXaW5kb3cuIFNvIHRoaXMgZGlzY3Vzc2lvbiBtYWtlcyBt ZSB1bmNvbWZvcnRhYmxlLg0KPj4+PiANCj4+Pj4gV2UncmUgZGlzY3Vzc2luZyBjaGFuZ2luZyB0 aGUgc2l6ZSBvciBleGlzdGVuY2Ugb2YgdGhlIGhlYWRlciwgb3IgdGhlIHNldCBvZiBvYmplY3Rz IGl0IGNvbnRhaW5zLCBub3QgdGhlIGNvbnRlbnRzIG9mIGFuIGV4aXN0aW5nIG9iamVjdC4gUmln aHQ/DQo+Pj4+IA0KPj4+IEkgdGhpbmsgaXQgbWF5IHJhaXNlIGFub3RoZXIgaW50ZXJlc3Rpbmcg cXVlc3Rpb24uIERvZXMgY2hhbmdpbmcgYSBIQkgNCj4+PiBvcHRpb24gaW5jbHVkZSB0aGF0IGl0 IGNhbiBiZSByZW1vdmVkPyBBbmQgaWYgd2UgZG8gYWxsb3cgdG8gcmVtb3ZpbmcNCj4+PiBIQkgg b3B0aW9ucyB3b3VsZCB0aGF0IHRoZW4gYWxsb3cgcmVtb3ZpbmcgdGhlIEhCSCBFSCBlbnRpcmVs eT8gVGhlcmUNCj4+PiBpcyBhIHByYWN0aWNhbCBhc3BlY3QgdG8gdGhpcyBpbiB0aGF0IGEgc291 cmNlIG5ldHdvcmsgbWF5IGhhdmUgZ29vZA0KPj4+IHN1cHBvcnQgZm9yIEhCSCBvcHRpb25zIGFu ZCB0aGV5IGNvdWxkIGJlIHVzZWQgcHJvZHVjdGl2ZWx5IHdpdGhpbg0KPj4+IHRoYXQgbmV0d29y aywgaG93ZXZlciB3aGVuIHBhY2tldHMgZWdyZXNzIGludG8gdGhlIEludGVybmV0IHdlIG1pZ2h0 DQo+Pj4gd2FudCB0byBzdHJpcCBIQkggb3B0aW9ucyBhbmQgRUggdG8gaW1wcm92ZSByZWFjaGFi aWxpdHkgb2YgcGFja2V0cy4NCj4+IA0KPj4gQW55IG9mIHRoZXNlIHRoaW5ncyBicmVha3MgSVBz ZWMgQUgsIHdoaWNoIGhhcyBhIHNwZWNpZmljIGV4Y2VwdGlvbiBmb3INCj4+IHZhbHVlIGNoYW5n ZXMgaW4gb3B0aW9ucyBidXQgbm90IGZvciBsZW5ndGggY2hhbmdlcy4NCj4+IA0KPiANCj4gSSBo YXZlbid0IHNlZW4gYW4gZXhwbGFuYXRpb24gYXMgdG8gd2h5IEVIIGluc2VydGlvbiBhbmQgcmVt b3ZhbA0KPiB3aXRoaW4gYSBkb21haW4sIGFuZCBpdHMgYXNzb2NpYXRlZCBjb21wbGV4aXR5LCBp cyBiZXR0ZXIgdGhhbg0KPiB0dW5uZWxsaW5nIHdpdGggdGhlIGFkZGVkIEVIIGJlaW5nIHBhcnQg b2YgdGhlIG91dGVyIHR1bm5lbCBoZWFkZXJzLg0KPiANCg0KSSB0aGluayB0aGlzIGlzIHRoZSB3 cm9uZyBsaW5lIG9mIHRoaW5raW5nIHdpdGhpbiB0aGUgY29udGV4dCBvZiBSRkMyNDYwYmlzIGFu ZCB0aGlzIGRpc2N1c3Npb24uDQoNCkl0IHJlYWxseSBpcyBub3QgYWJvdXQgd2hldGhlciBFSCBp bnNlcnRpb24gaXMgKmJldHRlciB0aGFuKiBvciAqd29yc3QgdGhhbiogdHVubmVsaW5nIHdpdGgg dGhlIGFkZGVkIEVILiBJdCBpcyBub3QgYSBjb21wZXRpdGlvbiwgYW5kIHBlcmhhcHMgZXZlbiBu YcOvdmUgdG8gYXNzdW1lIHRoZXJlIGlzIGEgdW5pcXVlIHNvbHV0aW9uIGZvciBldmVyeSBwb3Rl bnRpYWwgdXNlIGNhc2UuDQoNClRvIG1lLCB0aGUgbmV0LW5ldCBvZiBpdCBpcyB0aGF0IHRoZSBw cm9wb3NlZCB0ZXh0IGRlc2NyaWJlcyB0aGUgaXNzdWUgYW5kIGEgY3VycmVudCBzb2x1dGlvbiwg d2l0aG91dCBvdmVycmVhY2hpbmcgYW5kIG92ZXJwcmVzY3JpYmluZyBiZXlvbmQgMjQ2MGJpcyBz Y29wZS4g4oCUIEFsdGhvdWdoIEnigJlkIHByZWZlciB0byBzL1RoZSBjdXJyZW50IGFwcHJvYWNo L09uZSBhcHByb2FjaC8sIEkgc3VwcG9ydCB0aGF0IHRleHQuDQoNClRoYW5rcywNCg0K4oCUIENh cmxvcy4NCg0KPiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IHVzaW5nIHR1bm5lbGxpbmcgZm9yIGFj Y29tbW9kYXRpbmcgYWRkaW5nIEVIcw0KPiB0byBwcmUtZXhpc3RpbmcgcGFja2V0cyB0aGUgbW9y ZSBpdCBtYWtlcyBzZW5zZSB0byBtZS4NCj4gDQo+IFRoZSBlbmNhcHN1bGF0b3IgZ2V0cyB0byBj aG9vc2Ugd2hpY2ggZGV2aWNlIHNlZXMgdGhlIGFkZGVkIEVIIGJ5DQo+IHNwZWNpZnlpbmcgdGhl IG91dGVyIGhlYWRlciAodW5pY2FzdCwgYW55Y2FzdCBvciBtdWx0aWNhc3QpDQo+IGRlc3RpbmF0 aW9uIGFkZHJlc3MgKG1ha2luZyB0aGUgcGFja2V0IGRlc3RpbmF0aW9ucyBlbmQtc3lzdGVtcyBv cg0KPiBob3N0cyBpbiBSRkMyNDYwIHBhcmxhbmNlKS4gRGV2aWNlcyB0aGF0IGRvbid0IGhhdmUg dGhhdCBvdXRlcg0KPiBkZXN0aW5hdGlvbiBhZGRyZXNzIHBlcmZvcm0gc3RhbmRhcmQgSVB2NiBm b3J3YXJkaW5nLCByZW1haW5pbmcNCj4gb2JsaXZpb3VzIHRvIHRoZSBhZGRpdGlvbiBvZiB0aGUg RUggKHZpYSB0dW5uZWxsaW5nKSB0byB0aGUNCj4gcHJlLWV4aXN0aW5nIHBhY2tldC4NCj4gDQo+ IElmIHRoZSBhZGRlZCBFSCBoYXBwZW5zIHRvIGJlIGEgbmV3bHkgZGVmaW5lZCBvbmUsIG9ubHkg dGhlIHNldCBvZg0KPiBkZXZpY2VzIHRoYXQgbWF5IGJlIHNwZWNpZmllZCBhcyBkZXN0aW5hdGlv bnMgZm9yIHRoZXNlIHR1bm5lbCBwYWNrZXRzDQo+IG5lZWQgdG8gYmUgdXBncmFkZWQgdG8gdW5k ZXJzdGFuZCB0aGUgbmV3IEVILiBUaGVzZSB1cGdyYWRlZCBkZXZpY2VzDQo+IGFsc28gcmVtYWlu IG9ibGl2aW91cyB0byBhbnkgYWRkZWQgbmV3IEVIcyBpZiB0aGV5IGFyZW4ndCBhc3NpZ25lZCB0 aGUNCj4gcGFja2V0J3Mgb3V0ZXIgSVAgYWRkcmVzcywgbWVhbmluZyBzaW1wbGlmaWVkIGFuZCBz dGFuZGFyZCBJUHY2DQo+IGZvcndhcmRpbmcgZm9yIHRoZXNlIHBhY2tldHMsIHJhdGhlciB0aGFu IGhhdmluZyB0byBpbnNwZWN0IHRoZSBFSA0KPiBjaGFpbiBvZiBlYWNoIGFuZCBldmVyeSBwYWNr ZXQgdGhleSByZWNlaXZlIGZvciB0aGUgcHJlc2VuY2Ugb2YgdGhlDQo+IG5ldyBFSC4NCj4gDQo+ IA0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiANCj4gDQo+PiAgIEJyaWFuDQo+IA0KPj4gDQo+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+PiBp cHY2QGlldGYub3JnDQo+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBODQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2 NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Wed Jun 29 23:08:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8951A12D90A for ; Wed, 29 Jun 2016 23:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5_DoxnEZWllL for ; Wed, 29 Jun 2016 23:08:32 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4889612D78E for <6man@ietf.org>; Wed, 29 Jun 2016 23:08:32 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id o76so13965548qke.0 for <6man@ietf.org>; Wed, 29 Jun 2016 23:08:32 -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:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=6BGyKdO/FNrHNg1T45HDNipf2e85SiS7gxOx4tjOmdI=; b=N+Aet4OEjZ51ybtgwwst1Dgi5Ys8jG/fziKS/BrUL7+mYgSUgl67EcCW6yhmSf5QCx UQqz5m4JMGeOCCJVqukwAy5tnAFDLH+zUfr5UbmNXK7PYQ05/4l9V1Pp4dm66hrZYNGT 3/taoC3lHNS0coPXXxvjAni5iYP5F6vnUQetKczKtNirstnDl2VOQP4+t1ig7xIH6kO7 M7L6yN7DUEHVSroXPphzLCO4pTf6wQ6FDIaP39F7h+CqgX1JHOQWBumLUYJQfBorRcxA 1KDWPfVYFy6EOlj2oq0GOPT904XWMX2b017KFDIt4nQ61gE06P9KkeQ0ed9o+7i2GJyN HTiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=6BGyKdO/FNrHNg1T45HDNipf2e85SiS7gxOx4tjOmdI=; b=bbfnjYHF2Ucqy/V51gygKvkpKduPaMxnySqxNOfyCCPtquiQiqmYB8Gshj4PfR2CWJ +OxK6AslWMl7QMyaDTT4KQ5MUVzs8WGrNM2+pOaAcQd1Dd/IdJYCYkf9+18/KDmyPxll Xwk29LGpnCdQ1/hb2KNEmmhN0Zyi9wanIlzX+Sl23wGjFSu0yl8nV0CtCz70ZEnBLZ+X AuCgiMrT3YkbLCPY7MIj+1aoIu9olXJZpl+7MvP+8GtyK4lgAFFCgbaEiiPi43/Q2afN 3fpA+hpcQic0ldKJIzxNKtmwA4mg10RW5pOc8BIsn2+Y5D8kmVPtZPipJVTZoCX57Rr+ aaTw== X-Gm-Message-State: ALyK8tIwQl3X8J8B5r+1R+5cqq95bp8swWqxQ3dBMS/ZKF+OlrJaCFHU7Z61l5plDlVOZreYjwbM+Ts4/9khSw== X-Received: by 10.55.98.205 with SMTP id w196mr16645081qkb.65.1467266911463; Wed, 29 Jun 2016 23:08:31 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.166 with HTTP; Wed, 29 Jun 2016 23:08:30 -0700 (PDT) In-Reply-To: <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 29 Jun 2016 23:08:30 -0700 X-Google-Sender-Auth: ewJAz0WmDhqEFYOMbYjJDgqqrcg Message-ID: Subject: Re: [6man] #9 (rfc2460bis): Header injection issue To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 06:08:35 -0000 At Tue, 28 Jun 2016 15:42:44 -0700, Bob Hinden wrote: > After reviewing the mailing list discussion, I think this describes > the issue and the current defined solution. At the same time, it > doesn=E2=80=99t prohibit other solutions to inserting extension headers i= n > the future. > > My take is that this is about the best we can do given the range of > the views in the working group. I think it is much better than > saying nothing. I don=E2=80=99t think we can get a consensus on anything > significantly stronger. > > Comments? I don't like to be a stubborn blocker, but, I for one still have to disagree that this is the best "compromise" we can make. My points in my previous comment still apply: https://www.ietf.org/mail-archive/web/ipv6/current/msg24779.html I also suggested a sense of alternate text, for which I've seen a few positive feedback and (as far as I'm aware) no explicit objection. So I wonder whether we can adopt something like this. -- JINMEI, Tatuya From nobody Thu Jun 30 01:26:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5AB12D624 for ; Thu, 30 Jun 2016 01:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kPOEizd6V3aj for ; Thu, 30 Jun 2016 01:26:39 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3072A12D536 for <6man@ietf.org>; Thu, 30 Jun 2016 01:26:39 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v199so210740041wmv.0 for <6man@ietf.org>; Thu, 30 Jun 2016 01:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mzJG33XsvOlaADASCP5xH79r7ijVi63ep32oLsPeW/4=; b=QJiPp83ZkW7q/2wD4hbZ5khvpEpkvBRDq9qx4kyVQokqmLkyF35jj6xCoickbWbSWk cV6XmEbsuXEp3bR1uAzv+LBkCEvjZEw6Ulcj4qAdS9gKclP5+xO1FWwlrFgp78NrkVyu bXMOnaJeKzG3m2aIbfKHZzCvhSYfSnNGzhSPQmpvpBcfOqVUWT7zkLxnND1tYssJLtt2 12aJwK1iuU1Rj4GIAKhrFQKLNzka/NZazSMW3yKovyseNpzr0RAVSojU97edA+AgItCG 6fU/7zSFBvOtbMH/8WkuWkeLboowU/hT501daJszfAdgYEiwuMPHvAbPTTnbATHUvgsU /axQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mzJG33XsvOlaADASCP5xH79r7ijVi63ep32oLsPeW/4=; b=m8qPXaIsa67cUmy9tbFgJzrnCC1DDu/4aBv7j2yBcvTzG4VztX+7bs9k1nwjYZTpT+ Qh68xIyq5HrkBzWW8Y6rnU79QJV5kP5zHrocISxF6/5HiD5f7NSZFSf1K9DLQq1Nksk6 gc/JTLwdFE232PNQ3fTjjUNMGy469OimsI3MMG9vF1sX6Cr9aS8k8cyAQhWygTP+nQDv oqULOoUfIb3g7b/ciD6DweRxO5JU1OOxnpHmbyq+dYcjwifQEttGN9Iq+oF2aGkmUozq HX7qzCydjp4nBa3I1svm1rCej+iBqKBGnUX01+hHPU39TUWUbmkx12EZgW0IqODZmLHQ ShJg== X-Gm-Message-State: ALyK8tKiJ0uVUFZ4k8JjIPeRXJKlR4AhzvnX457lMuLTMm+7p6ifnSVAkP2IhIJ5WaO1Xw== X-Received: by 10.28.57.212 with SMTP id g203mr13370202wma.7.1467275197718; Thu, 30 Jun 2016 01:26:37 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id ur2sm452023wjc.33.2016.06.30.01.26.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 01:26:37 -0700 (PDT) Subject: Re: [6man] #9 (rfc2460bis): Header injection issue To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden References: <063.46dedc0eea831fdd4d5e2fa4afbad641@trac.tools.ietf.org> <078.0ae6347dd45c3cc3d61535dc6ca59b49@trac.tools.ietf.org> <8A2D4A64-8FC7-4D49-9CCC-C7A4DC8B4A43@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Jun 2016 20:26:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 08:26:42 -0000 On 30/06/2016 18:08, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 28 Jun 2016 15:42:44 -0700, > Bob Hinden wrote: >=20 >> After reviewing the mailing list discussion, I think this describes >> the issue and the current defined solution. At the same time, it >> doesn=E2=80=99t prohibit other solutions to inserting extension header= s in >> the future. >> >> My take is that this is about the best we can do given the range of >> the views in the working group. I think it is much better than >> saying nothing. I don=E2=80=99t think we can get a consensus on anyth= ing >> significantly stronger. >> >> Comments? >=20 > I don't like to be a stubborn blocker, but, I for one still have to > disagree that this is the best "compromise" we can make. My points in > my previous comment still apply: > https://www.ietf.org/mail-archive/web/ipv6/current/msg24779.html >=20 > I also suggested a sense of alternate text, for which I've seen a few > positive feedback and (as far as I'm aware) no explicit objection. So > I wonder whether we can adopt something like this. The point about a compromise is that nobody gets exactly what they want. Or, as a boss of mine once said, it's the best possible distribution of unhappiness. On that basis, I support Bob's latest proposed text. Brian From nobody Thu Jun 30 03:05:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8E12DA03 for ; Thu, 30 Jun 2016 03:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OboyfqUv_dDc for ; Thu, 30 Jun 2016 03:05:19 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB9312D9EE for ; Thu, 30 Jun 2016 03:05:18 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c2so102884340vkg.1 for ; Thu, 30 Jun 2016 03:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ROqhONIJgzTyxn4JxGvHsyTmhJ0pwJeywYXc3eJWo14=; b=kBcsX/FVThQJYoV/9C+olJrftvS8ML5AFfpFL76qZcHC5wkCM+9ylXWm+E2CXXSdOx IwguQ56HvJbyI3hy68PeSBBTMJeV4F+KHMoXaSq3KQaO6fCp9/QiTCbB5V7n5blkqxiv pqCSRv4j2qO0JLIwgimZ01gAANHczbnT6wqDDQ0xHquLS62jLeSnmVX2ky1aS4RnMUyb YNOVbDZmP4Wn74xo9rmb3+RjWMUkbIoYqBBnN3h9OTS/4AXtuP0J1eh56mmJQdoveZr0 +qv+UzDnaiimjeXoIpOUuHK+jrnsLBbNoGiTMwli8lE7ITc/JQicIH8bo8HJJh2NRuw8 zIEQ== 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-transfer-encoding; bh=ROqhONIJgzTyxn4JxGvHsyTmhJ0pwJeywYXc3eJWo14=; b=kJDDybSi0P1nl2uPgNxaWscvKPeFYCXBQVInLcnTKsknpgdm5cSRGn1DGtsAQvFyoG 6noSZcghZGjEaf+6vunY4z9A1lQcysECl1ZaLT9dLpa91LPBrLdDfKsdcSTHoHTaY/pJ fCXXntnnhMbub87KMv6e7z3m1EmhVTo+RxoasTi1Paa8gaAE3Vc7R/nJxlHkTWm0dF0F hsu5YzVF1yKY0Xoj2GFjOQVc7HztwfQ4Hr1nn0iGCqp7yf9J3bQ/qbWOloJ9vA379+n7 /kTyn8XRxKXoDeoRK7MyRDghfRgtSWXAPzdycgjRwkmp+JLeoivhSkpY6fBZyBqp3S46 i9rQ== X-Gm-Message-State: ALyK8tJ/n2nVhbGk7cytZKpYc3rlMBxDvK6t6sQYzGOwqWLvT9UcSfwNmqPkGuuby4GJnlRhsK/9fmaYhyb62Q== X-Received: by 10.176.64.69 with SMTP id h63mr6143348uad.125.1467281117766; Thu, 30 Jun 2016 03:05:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.130 with HTTP; Thu, 30 Jun 2016 03:04:47 -0700 (PDT) In-Reply-To: <1A85BA2A-6507-4D04-A18B-FF57BCD05A87@cisco.com> References: <7F2E01F1-A3B1-46B8-953D-D81B7B9CBBCF@gmail.com> <576688E0.1010303@si6networks.com> <57671C97.1040409@si6networks.com> <076793c0712a46018adbeec19f157c98@XCH15-06-11.nw.nos.boeing.com> <26316EE4-F01C-4AB6-8465-FF8245CF8458@cisco.com> <407797e5-a170-b088-aad0-6585140b445d@gmail.com> <1A85BA2A-6507-4D04-A18B-FF57BCD05A87@cisco.com> From: Mark Smith Date: Thu, 30 Jun 2016 20:04:47 +1000 Message-ID: Subject: Re: RFC2460bis - Ticket #9 - Header injection issue To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 10:05:21 -0000 On 30 June 2016 at 03:36, Carlos Pignataro (cpignata) wrote: > >> On Jun 27, 2016, at 11:41 PM, Mark Smith wrote: >> >> On 28 Jun 2016 06:15, "Brian E Carpenter" = wrote: >>> >>> >>> >>> Regards >>> Brian Carpenter >>> http://orcid.org/0000-0001-7924-6182 >>> >>> >>> >>> On 28/06/2016 06:30, Tom Herbert wrote: >>>> On Mon, Jun 27, 2016 at 11:15 AM, Fred Baker (fred) w= rote: >>>>> >>>>>> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E wrote: >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carp= enter >>>>>> >>>>>>> OK... suppose all of us here agree that 'no processing' means 'no i= nsertion, >>>>>>> deleting or changing.' How do we ensure that all readers of 2460bis >>>>>>> understand >>>>>>> this from the text? >>>>>> >>>>>> Instead of "processing," why not say "modifying," or maybe even "ins= pecting and modifying" (with the one exception specified already)? >>>>>> >>>>>> We seem to go around and around on this, because of what "consenting= adults" have been known to do, strictly within their own administrative do= main. Do we need words to the effect? That seems to be the issue. >>>>> >>>>> My understanding is that section 4.2 explicitly allows an option to b= e modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting = from MSB) is set. An example of such a use case would implement RCP or XCP;= the option in the HBH header collects statistical information from the net= work, and the same option as a destination option returns the result to the= sender, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever = Effective Window. So this discussion makes me uncomfortable. >>>>> >>>>> We're discussing changing the size or existence of the header, or the= set of objects it contains, not the contents of an existing object. Right? >>>>> >>>> I think it may raise another interesting question. Does changing a HBH >>>> option include that it can be removed? And if we do allow to removing >>>> HBH options would that then allow removing the HBH EH entirely? There >>>> is a practical aspect to this in that a source network may have good >>>> support for HBH options and they could be used productively within >>>> that network, however when packets egress into the Internet we might >>>> want to strip HBH options and EH to improve reachability of packets. >>> >>> Any of these things breaks IPsec AH, which has a specific exception for >>> value changes in options but not for length changes. >>> >> >> I haven't seen an explanation as to why EH insertion and removal >> within a domain, and its associated complexity, is better than >> tunnelling with the added EH being part of the outer tunnel headers. >> > > I think this is the wrong line of thinking within the context of RFC2460b= is and this discussion. > > It really is not about whether EH insertion is *better than* or *worst th= an* tunneling with the added EH. It is not a competition, So I think broadly it actually is a competition, because ideally we want a single solution that can facilitate all as many similar use cases as possible, and ideally all of them, as well as one that inter-operates with existing specifications and deployed implementations. We want a single clear winner if we can find one, not multiple candidate winners that don't differ that much. To create a new solution to a problem that can probably be solved using existing methods and mechanisms really means that the new solution needs to provide some "compelling" advantage or benefit over the existing method, that justifies and outweighs the newly created costs of the new solution, such as new specifications, new code, possible confusion about which solution to use when they're both possible candidates, and conflict resolution methods or preferences if they happen to be co-deployed. (This is why I've developed quite a strong personal objection to DNS options in RAs - I don't think they provide a compelling enough benefit over deploying stateless DHCP, which can provide DNS as well as many other pretty essential host parameters such as NTP.) I haven't yet seen the "compelling" benefits of inserting EHs that outweighs the corresponding incurred costs, in comparison to the existing methods of adding them via tunnelling that co-exists with existing mechanisms. > and perhaps even na=C3=AFve to assume there is a unique solution for ever= y potential use case. > > To me, the net-net of it is that the proposed text describes the issue an= d a current solution, without overreaching and overprescribing beyond 2460b= is scope. =E2=80=94 Although I=E2=80=99d prefer to s/The current approach/O= ne approach/, I support that text. > The thing I want to see the text do is encourage the use of the existing tunnelling method that doesn't cause PMTUD and similar issues, rather than being neutral about it. I think the 'The current approach' does that. Regards, Mark.