From nobody Mon Feb 1 02:22:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864BE1B3017 for ; Mon, 1 Feb 2016 02:22:09 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INtxJlKoK9Mi for ; Mon, 1 Feb 2016 02:22:07 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928BC1B3015 for ; Mon, 1 Feb 2016 02:22:07 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u11ALuhF068468 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 10:21:56 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56AF31C3.6060801@foobar.org> Date: Mon, 01 Feb 2016 10:21:55 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: joel jaeggli References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> In-Reply-To: <56AEF747.5080400@bogus.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:22:09 -0000 joel jaeggli wrote: > Sometimes a slow forwarding path is not an option > > e.g. the options are fast path or no path. depends on the speed of the link. For anything other than trivially slow edge links, slow forwarding path is non-viable and represents a serious denial of service vector. Nick From nobody Mon Feb 1 05:02:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430C31A0104 for ; Mon, 1 Feb 2016 05:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.133 X-Spam-Level: ** X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuxxNSG0E0aZ for ; Mon, 1 Feb 2016 05:02:30 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE01A00EF for ; Mon, 1 Feb 2016 05:02:30 -0800 (PST) X-SENDER-IP: 10.64.163.154 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.22,380,1449550800"; d="scan'208";a="577738926" Received: from unknown (HELO exchpapp13.corp.twcable.com) ([10.64.163.154]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 01 Feb 2016 08:01:08 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp13.corp.twcable.com (10.64.163.154) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 1 Feb 2016 08:02:03 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1130.005; Mon, 1 Feb 2016 08:02:03 -0500 From: "Howard, Lee" To: Nick Hilliard , joel jaeggli Thread-Topic: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops Thread-Index: AQHRXPC+Tvdk8AFpcEWQiZckccAzxw== Date: Mon, 1 Feb 2016 13:02:03 +0000 Message-ID: References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> In-Reply-To: <56AF31C3.6060801@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22104.005 x-tm-as-result: No--38.181400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:02:32 -0000 On 2/1/16, 5:21 AM, "v6ops on behalf of Nick Hilliard" wrote: >joel jaeggli wrote: >> Sometimes a slow forwarding path is not an option >> >> e.g. the options are fast path or no path. > >depends on the speed of the link. For anything other than trivially >slow edge links, slow forwarding path is non-viable and represents a >serious denial of service vector. Well, I=B9d say it depends on the available capacity of the CPU relative to the speed of the link. I don=B9t care if you=B9re on a big router, if your CPU=B9s already at 90%, you can=B9t slow-path an additional T1. Lee > >Nick > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Feb 1 05:15:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79D71A01F6 for ; Mon, 1 Feb 2016 05:15:47 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuN_3miFTDki for ; Mon, 1 Feb 2016 05:15:46 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B231A0171 for ; Mon, 1 Feb 2016 05:15:45 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u11DFdgW073002 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 13:15:39 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56AF5A7A.6010606@foobar.org> Date: Mon, 01 Feb 2016 13:15:38 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Howard, Lee" References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:15:47 -0000 Howard, Lee wrote: > Well, Išd say it depends on the available capacity of the CPU relative to > the speed of the link. I donšt care if youšre on a big router, if your > CPUšs already at 90%, you canšt slow-path an additional T1. If you're on a big router, there is no slow path. Nick From nobody Mon Feb 1 06:00:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FAF1A90D8 for ; Mon, 1 Feb 2016 06:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwB8zoxxf8nT for ; Mon, 1 Feb 2016 06:00:19 -0800 (PST) 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 334E31A90D7 for ; Mon, 1 Feb 2016 06:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1454335219; x=1455544819; h=date:from:message-id:to:subject; bh=QtLjOIpxNxoRu7d/jLVh8Pn1UXpOGsN9v9gJEc36t7o=; b=i3j65ewIE6M1/5WUhYMorv6JY3YLAC7tIqxiyhaFP+g23wbwaGsE5MyJ 9ntmp+Sy/csCiIRiaUFkKNuMe3DTTU3uvE989LK5oA+/bf/0TD5i3CSWV 6DuIOwG4s2NIVmG/2eor0Xd+knNzpMaTphTZYKrZId9dgoEreoScNayQk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQB0ZK9W/4gNJK1egzqKF6F1AY9nA?= =?us-ascii?q?Q2BY4dEOBQBAQEBAQEBgQqFfTSIewGePJ4eAQEBBwEBAQEBARqPRINuBY4ZiFa?= =?us-ascii?q?BEpspjj4eAQFChA2JRgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,380,1449532800"; d="scan'208";a="233529931" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2016 14:00:18 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u11E0IWM002893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2016 14:00:18 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u11E0HrM009387 for ; Mon, 1 Feb 2016 06:00:17 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u11E0Hsd009385 for v6ops@ietf.org; Mon, 1 Feb 2016 06:00:17 -0800 Date: Mon, 1 Feb 2016 06:00:17 -0800 From: fred@cisco.com Message-Id: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:00:20 -0000 RFC Editor: AUTH48 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption 2015-10-26 draft-ietf-v6ops-siit-dc 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat 2015-10-26 draft-ietf-v6ops-siit-eam RFC Editor: In ISE Review 2016-01-20 draft-ietf-v6ops-mobile-device-profile IESG: AD Evaluation 2016-01-31 draft-bao-v6ops-rfc6145bis IESG: In Last Call 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world WG: Unupdated WG Document 2015-10-19 draft-ietf-v6ops-design-choices WG: Updated WG Document 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host 2016-01-03 draft-ietf-v6ops-host-addr-availability Individual Submission: Unupdated 2015-10-19 draft-xu-v6ops-dslite-redundancy 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack Individual Submission: Updated 2016-01-05 draft-templin-v6ops-pdhost 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment From nobody Mon Feb 1 07:09:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1C1ACD15 for ; Mon, 1 Feb 2016 07:09:46 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8qmfLHNoJiK for ; Mon, 1 Feb 2016 07:09:44 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C911ACD0F for ; Mon, 1 Feb 2016 07:09:43 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u11F9agS075916 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 15:09:37 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56AF752F.8060608@foobar.org> Date: Mon, 01 Feb 2016 15:09:35 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Howard, Lee" References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> <56AF5A7A.6010606@foobar.org> In-Reply-To: <56AF5A7A.6010606@foobar.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:09:46 -0000 Nick Hilliard wrote: > If you're on a big router, there is no slow path. Mikael Abrahamsson and I discussed this off-line. Technically he was correct to point out that there are slow paths available on some large router models. Conversely there are other routers models which don't include a slow path of any form - i.e. packets which cannot be handled in the normal data forwarding plane are blackholed. Regardless of model, all packets which are punted on high performance routers are rate limited to the point that it would be highly inadvisable to depend on this as a viable packet forwarding mechanism, which is why I said that there is no slow path: technically it exists in some cases, but where it does, it is non-viable to the point that it is better to assume that it doesn't exist in the first place. Nick From nobody Mon Feb 1 07:56:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FBB1AD0A3 for ; Mon, 1 Feb 2016 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJkvkIKQj8Gd for ; Mon, 1 Feb 2016 07:56:38 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 ECB531AD0A2 for ; Mon, 1 Feb 2016 07:56:37 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id 128so77740631wmz.1 for ; Mon, 01 Feb 2016 07:56:37 -0800 (PST) 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:content-type; bh=rAJv8n9Hkk+O0MGIjm811/VBHQ+iBPMoZYkIetA/nn4=; b=ecqQD8/RqnonzKhNOmcbTIu7FPVQzAC/TbdufnZGJvjbbZWoUZSAm7feM6ALrWDSbN a1uSU1pIYXFiQS5pGipGzp7eJBxNxBrUy24p4lm9K3RVhrNb6wYEDt2yCSHQafL2qokE Xx6TlPt7+0ejuyH9GCjnZeO/sHTVuN4YmUpjJl8FIbpHITGU7SIWjXc2RAUiazSByQAu 2CLEgXmQjaxepLNoEMeXqslygNNQsd540IBKrepiE2YqED7X/SiAIQY+mNLqbtVmsFkB YR7qoN4lVxhWcXNSzH881qAmU9CHwXWstC3UxQGBd+JZlAG9svnD9l2X8268vLk+Cl7K REjQ== 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-type; bh=rAJv8n9Hkk+O0MGIjm811/VBHQ+iBPMoZYkIetA/nn4=; b=Rg9CTedQ9tFYiEawqIxf3cUHzP37PW36q8giKJaqsBOTMO9YW5rBpCvYZQABHBnaKx 5pMExVTp9i8YzYP6DbFgNpcyGYClx7W3Pkp/hsw37wOOjKVuYHcY8t/+zYawyszCqLkE DF7ENeXI4WOYtSC0ykGtCdB8rpOyghiZBpPol6+gXzZIul4e175S73G20zKj6U0fIqVP Cqej5XNXMK+vlaQ0Se89OPrDmGqJn+eQBJmYhBbaI1jLO2oCVRlcfDW+v/Cq75TVSd0s bQ72lNmjRvPEYAsykAnalF9QjUS+BOa7Hx8IvXb3t6xwHcrJ6ipM5brp03k0BLFZ7VC3 1NlA== X-Gm-Message-State: AG10YOTiCIl1c1gzTxgj+Q+MtAIM7UN6RjT8ReF5QSCIWpTShGo8UFRS6rGE0FAiTBB8aKDYXp5J2AcJyZX2Ww== MIME-Version: 1.0 X-Received: by 10.194.191.229 with SMTP id hb5mr23152220wjc.164.1454342196551; Mon, 01 Feb 2016 07:56:36 -0800 (PST) Received: by 10.194.68.66 with HTTP; Mon, 1 Feb 2016 07:56:36 -0800 (PST) In-Reply-To: <56AF752F.8060608@foobar.org> References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> <56AF5A7A.6010606@foobar.org> <56AF752F.8060608@foobar.org> Date: Mon, 1 Feb 2016 07:56:36 -0800 Message-ID: From: Ca By To: Nick Hilliard Content-Type: multipart/alternative; boundary=047d7b87370a01ed35052ab76e18 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:56:39 -0000 --047d7b87370a01ed35052ab76e18 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 1, 2016 at 7:09 AM, Nick Hilliard wrote: > Nick Hilliard wrote: > > If you're on a big router, there is no slow path. > > Mikael Abrahamsson and I discussed this off-line. Technically he was > correct to point out that there are slow paths available on some large > router models. Conversely there are other routers models which don't > include a slow path of any form - i.e. packets which cannot be handled > in the normal data forwarding plane are blackholed. > > Regardless of model, all packets which are punted on high performance > routers are rate limited to the point that it would be highly > inadvisable to depend on this as a viable packet forwarding mechanism, > which is why I said that there is no slow path: technically it exists in > some cases, but where it does, it is non-viable to the point that it is > better to assume that it doesn't exist in the first place. > > Nick > > +1 CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b87370a01ed35052ab76e18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 1, 2016 at 7:09 AM, Nick Hilliard <nick@foobar.org> wrote:
Nick Hillia= rd wrote:
> If you're on a big router, there is no slow path.

Mikael Abrahamsson and I discussed this off-line.=C2=A0 Technically = he was
correct to point out that there are slow paths available on some large
router models.=C2=A0 Conversely there are other routers models which don= 9;t
include a slow path of any form - i.e. packets which cannot be handled
in the normal data forwarding plane are blackholed.

Regardless of model, all packets which are punted on high performance
routers are rate limited to the point that it would be highly
inadvisable to depend on this as a viable packet forwarding mechanism,
which is why I said that there is no slow path: technically it exists in some cases, but where it does, it is non-viable to the point that it is
better to assume that it doesn't exist in the first place.

Nick


+1=C2=A0

CB=C2=A0
=
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--047d7b87370a01ed35052ab76e18-- From nobody Mon Feb 1 09:55:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115A91B336F for ; Mon, 1 Feb 2016 09:55:33 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpse5djKWPUY for ; Mon, 1 Feb 2016 09:55:27 -0800 (PST) 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 930ED1B336E for ; Mon, 1 Feb 2016 09:55:27 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u11HtFYZ024777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 17:55:15 GMT (envelope-from joelja@bogus.com) To: Ca By , Nick Hilliard References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> <56AF5A7A.6010606@foobar.org> <56AF752F.8060608@foobar.org> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56AF9C02.9070109@bogus.com> Date: Mon, 1 Feb 2016 09:55:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G56ETaq5JWuPUeF8plN7nfOF14EtbfKgv" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:55:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G56ETaq5JWuPUeF8plN7nfOF14EtbfKgv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/1/16 7:56 AM, Ca By wrote: >=20 >=20 > On Mon, Feb 1, 2016 at 7:09 AM, Nick Hilliard > wrote: >=20 > Nick Hilliard wrote: > > If you're on a big router, there is no slow path. >=20 > Mikael Abrahamsson and I discussed this off-line. Technically he w= as > correct to point out that there are slow paths available on some la= rge > router models. Conversely there are other routers models which don= 't > include a slow path of any form - i.e. packets which cannot be hand= led > in the normal data forwarding plane are blackholed. >=20 > Regardless of model, all packets which are punted on high performan= ce > routers are rate limited to the point that it would be highly > inadvisable to depend on this as a viable packet forwarding mechani= sm, > which is why I said that there is no slow path: technically it exis= ts in > some cases, but where it does, it is non-viable to the point that i= t is > better to assume that it doesn't exist in the first place. If you have a rate limit for control traffic of all varieties at ~20-100kpps and asic based path of 14Bpps you're not using the former as part of the forwarding path. if you are a designer of said product, you're not going to allow recourse to CPU forwarding for packets you can't parse because that's a recipie for a meltdown. > Nick >=20 >=20 > +1=20 >=20 > CB=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --G56ETaq5JWuPUeF8plN7nfOF14EtbfKgv 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 iEYEARECAAYFAlavnAMACgkQ8AA1q7Z/VrKRBgCfdzxNTKJ5vPxYCVi7Hrjhu25G HAQAnR696SVjgbJDTeKir4ByjRtj3aIS =32Cm -----END PGP SIGNATURE----- --G56ETaq5JWuPUeF8plN7nfOF14EtbfKgv-- From nobody Mon Feb 1 10:30:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830E31B33E5 for ; Mon, 1 Feb 2016 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4XNojB4I8KB for ; Mon, 1 Feb 2016 10:30:48 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 795831B33DD for ; Mon, 1 Feb 2016 10:30:48 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id u9so28692949ykd.1 for ; Mon, 01 Feb 2016 10:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Zv7EMhgMhYhN0PALkLx15qLtfPcmNsrueFoJ1CW8M7U=; b=Brlsb07Weq66qLuTv59vPPkuyCoAFQs/hiIcZDf2ZNqGfl+oVe7o9mAXjuWEJtMfTP IH6S2yQpyvoFhmEhTRuxxplIRgVPsCiHmuFL3dQmUBoZG5rcZl2PMLL/7Z/0J/fb0HEm vAgFBKgq48EOcdroyQQzJqTbJmIkkSyhX8WYROLjcfmU/yTngg9laZMm73h+hiwej1Ms txR/jkrKHr0G5Nb/FD+RL8fXpgo8WGqf2rK9VBtiy5IJAm1ucnzWZ/flYl0QBskgM7GV KrJEDaQv86zEd4jy0ty5m5WoudEXfHppC5eQ4xkmMC43ayCkSPo+fjzmGMih6RRegXfx HjTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Zv7EMhgMhYhN0PALkLx15qLtfPcmNsrueFoJ1CW8M7U=; b=NV5++SUQyrKIs/LMUmO5ORAWXTZFbRXdmvNAGqrPlq8jMKc3imdr4v3OjSrZGbaszV W+STNia6EBVFJ4yU0IEib8bz7MnIs5KOmGj8TYr/cyvXO2gMGxYWDCi7FreXcASVzpRl JNUTkmu3F7VSXvvsZiZ0ruTWxS3Il5ZN+Od/uB4S+Z6Vy6IqYFT16FwhDl+E0KzBpxpt vt4Ve4aEX3sFs7V6NR3XyaXBMFNl06GHv6vWMnca6eODjSV4fWwpna5BV6q3x1p4JwD7 Ck/doKOnxCn7xXULWz1Q8rDF+QjRDDwf5zhd7YZm/qqi1WL2Sso5RcSMoqJ2AJYjMjgK vT4Q== X-Gm-Message-State: AG10YOQT4Gb3qbPC63i4gfxah/MUi+LLbOodmEf6AYyBGA9t7e3KEXktSIVs3lrrOCr2E/Tt5olgf8TjDFeAE0R0 X-Received: by 10.37.97.210 with SMTP id v201mr7303559ybb.77.1454351447685; Mon, 01 Feb 2016 10:30:47 -0800 (PST) MIME-Version: 1.0 References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> <56AEF747.5080400@bogus.com> <56AF31C3.6060801@foobar.org> <56AF5A7A.6010606@foobar.org> <56AF752F.8060608@foobar.org> <56AF9C02.9070109@bogus.com> In-Reply-To: <56AF9C02.9070109@bogus.com> From: Warren Kumari Date: Mon, 01 Feb 2016 18:30:38 +0000 Message-ID: To: joel jaeggli , Ca By , Nick Hilliard Content-Type: multipart/alternative; boundary=001a1142ed046b44b6052ab99515 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 18:30:50 -0000 --001a1142ed046b44b6052ab99515 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 1, 2016 at 12:55 PM joel jaeggli wrote: > On 2/1/16 7:56 AM, Ca By wrote: > > > > > > On Mon, Feb 1, 2016 at 7:09 AM, Nick Hilliard > > wrote: > > > > Nick Hilliard wrote: > > > If you're on a big router, there is no slow path. > > > > Mikael Abrahamsson and I discussed this off-line. Technically he was > > correct to point out that there are slow paths available on some > large > > router models. Conversely there are other routers models which don't > > include a slow path of any form - i.e. packets which cannot be > handled > > in the normal data forwarding plane are blackholed. > > > > Regardless of model, all packets which are punted on high performance > > routers are rate limited to the point that it would be highly > > inadvisable to depend on this as a viable packet forwarding > mechanism, > > which is why I said that there is no slow path: technically it > exists in > > some cases, but where it does, it is non-viable to the point that it > is > > better to assume that it doesn't exist in the first place. > > If you have a rate limit for control traffic of all varieties at > ~20-100kpps and asic based path of 14Bpps you're not using the former as > part of the forwarding path. if you are a designer of said product, > you're not going to allow recourse to CPU forwarding for packets you > can't parse because that's a recipie for a meltdown. > ... and, even if the vendor might allow it, operators would want a way to disable it. I *so* don't want some monkey on the Internet sending me packets carefully crafted to be punted into the slow path. This means that vendors would need to build slow path forwarding, and lots of tunable knobs to allow operators to choose which packets may take that, and at what rate... "A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." The scientist gave a superior smile before replying, "What is the tortoise standing on?" "You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!" - Hawking, 1988 W > > > Nick > > > > > > +1 > > > > CB > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1142ed046b44b6052ab99515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Feb 1, 2016 at 12:55 PM joel jaeggli <joelja@bogus.com> wrote:
On 2/1/16 7:56 AM, Ca By wrote:
>
>
> On Mon, Feb 1, 2016 at 7:09 AM, Nick Hilliard <nick@foobar.org
> <mailto:nick@f= oobar.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Nick Hilliard wrote:
>=C2=A0 =C2=A0 =C2=A0> If you're on a big router, there is no slo= w path.
>
>=C2=A0 =C2=A0 =C2=A0Mikael Abrahamsson and I discussed this off-line.= =C2=A0 Technically he was
>=C2=A0 =C2=A0 =C2=A0correct to point out that there are slow paths avai= lable on some large
>=C2=A0 =C2=A0 =C2=A0router models.=C2=A0 Conversely there are other rou= ters models which don't
>=C2=A0 =C2=A0 =C2=A0include a slow path of any form - i.e. packets whic= h cannot be handled
>=C2=A0 =C2=A0 =C2=A0in the normal data forwarding plane are blackholed.=
>
>=C2=A0 =C2=A0 =C2=A0Regardless of model, all packets which are punted o= n high performance
>=C2=A0 =C2=A0 =C2=A0routers are rate limited to the point that it would= be highly
>=C2=A0 =C2=A0 =C2=A0inadvisable to depend on this as a viable packet fo= rwarding mechanism,
>=C2=A0 =C2=A0 =C2=A0which is why I said that there is no slow path: tec= hnically it exists in
>=C2=A0 =C2=A0 =C2=A0some cases, but where it does, it is non-viable to = the point that it is
>=C2=A0 =C2=A0 =C2=A0better to assume that it doesn't exist in the f= irst place.

If you have a rate limit for control traffic of all varieties at
~20-100kpps and asic based path of 14Bpps you're not using the former a= s
part of the forwarding path.=C2=A0 if you are a designer of said product, you're not going to allow recourse to CPU forwarding for packets you can't parse because that's a recipie for a meltdown.

... and, even if the vendor might allow it, operators= would want a way to disable it.
I *so* don't want some monke= y on the Internet sending me packets carefully crafted to be punted into th= e slow path.

This means that vendors would need to= build slow path forwarding, and lots of tunable knobs to allow operators t= o choose which packets may take that, and at what rate...=C2=A0
<= br>
"A well-known scientist (some say it was Bertrand R= ussell) once gave a public lecture on astronomy. He described how the earth= orbits around the sun and how the sun, in turn, orbits around the center o= f a vast collection of stars called our galaxy. At the end of the lecture, = a little old lady at the back of the room got up and said: "What you h= ave told us is rubbish. The world is really a flat plate supported on the b= ack of a giant tortoise." The scientist gave a superior smile before r= eplying, "What is the tortoise standing on?" "You're ver= y clever, young man, very clever," said the old lady. "But it'= ;s turtles all the way down!"
- Hawking, 1988
=C2=A0
W

>=C2=A0 =C2=A0 =C2=A0Nick
>
>
> +1
>
> CB
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/v6ops
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a1142ed046b44b6052ab99515-- From nobody Mon Feb 1 13:16:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4565D1B36BF for ; Mon, 1 Feb 2016 13:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eWGm48h1CMe for ; Mon, 1 Feb 2016 13:16:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92771B2DDE for ; Mon, 1 Feb 2016 13:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2087; q=dns/txt; s=iport; t=1454361388; x=1455570988; h=from:to:subject:date:message-id:mime-version; bh=AyOTdVCmAC5hlpdCPcXww8ig/RQLLincconJDR/g2OQ=; b=U0APj0JrsQdBHE9uLDdAcnY4dAT4yEoY6Heqc2sne0DKF6ct+RriO+hV nuJa61gxnk/ikBO2r+5QXOj/k5C22i4FH9qFOExr9o7Q/ztL0uPxZ4Ub0 N9nvee1+wFZL7rBd5GbPG512er1igb+OsdehR6U5S5HAtaIoUEucsGfzG E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAgDRyq9W/5JdJa1egzpSbgWIUrFcD?= =?us-ascii?q?oFkJocoOBQBAQEBAQEBfwuESIELAYEAJwQhiA0OnyqeQQEBAQEBBQEBAQEBARI?= =?us-ascii?q?Ih3yKJ4EPBZZvAYJ5gWNqiASCJYxLjj0BHgFDggIZgVGJWXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,381,1449532800"; d="asc'?scan'208";a="233916377" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2016 21:16:28 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u11LGRwe011173 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Feb 2016 21:16:28 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 15:16:27 -0600 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.1104.009; Mon, 1 Feb 2016 15:16:27 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Hmm. Interesting article... Thread-Index: AQHRXTXPkiUQUGq5CECiLP0wylSOSQ== Date: Mon, 1 Feb 2016 21:16:26 +0000 Message-ID: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.219] Content-Type: multipart/signed; boundary="Apple-Mail=_0C92AF94-76A1-48D8-8C90-297C040D1A3D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 21:16:30 -0000 --Apple-Mail=_0C92AF94-76A1-48D8-8C90-297C040D1A3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttp://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-= been-visited-by-shodan-and-other-scanners/ "Hein said he supports using IPv6 addresses once per connection and = limiting the lifespan of an IPv6 address to a single connection. Once = the connection is closed, the IPv6 address would be deallocated." Thought for today. Wouldn't it be better to divide the set of addresses = in use by a host into two - those that others may use to connect to it = (and are probably advertised in DNS) and those that it uses to connect = to other hosts? In a scan of this kind, if the harvested address didn't = respond to an incoming connection, the scan would yield little or no = value - even with a port scan five seconds later. --Apple-Mail=_0C92AF94-76A1-48D8-8C90-297C040D1A3D 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 iQIVAwUBVq/LKkayAOS/EQ8MAQLDbA/+JX2PZ8bmb5jo2JxnFaVWd111MKHwHFZD xvPvenuZWFj13GYG7wj9/atac34yly6WSA5686wxkDwzUORs6QHBbEFgmFInF5uA WRGBVT4zoj+LGehQ+1CqJisCkqWcRuPky6xEFiYuCLb9YgTGhqHU9pnJ3LvHyd4P iWI9meah91VEYfQMVHq6C9ps3i+vRKt491BaugkpMpV3DJ4r5CjNs8nydRIBRunA 9+pcXLnMH/zRKsiRyBVbtNFOizjNkD7JJMqTmK96T09+OumACsyfpfwvDavOVDTm 3fY8wvH9O5MRz2AlbnGIp+xU+c45rl94K0VJc7XMCaoUlT0E6QJXV5oiEP28+K7L 5GpqLBSDgCjvyYpAkeEXtXLAflPQBrZgQQMj8vRwoNqLPld5JuU6ntiihPxMzBJA UGjn9mIWRvXE9Iir4zCUJIISo+aRCxvAOTX75zO+k4v6gz9uYDsD10Ly5r6gPjts B/4BHESUZkptrv0O+LfHUUXP4IjTXKjszqoYUD7/H9N0K+SZoEjcKGj5uRVA7f35 QyeNMUgRyaAsTPUrVAJtpdtwmwl//e0N2jW1Mc/w2bwYBMFK8tJSSMJmfy4uDixZ 7Pmcz+hFV2JKorO5yDfpC3tVVxox5RW+X6UPc1K0H4+N+cEw9O+CERo200nvtuFE dMzvcBHO58Q= =oDk/ -----END PGP SIGNATURE----- --Apple-Mail=_0C92AF94-76A1-48D8-8C90-297C040D1A3D-- From nobody Mon Feb 1 13:39:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CEB1B371E for ; Mon, 1 Feb 2016 13:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Em8i6s5GVur for ; Mon, 1 Feb 2016 13:39:00 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 761061B3722 for ; Mon, 1 Feb 2016 13:39:00 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id z13so63877852ykd.0 for ; Mon, 01 Feb 2016 13:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=f0EI4XXWCZ4ng1p2aav2UrGfV4pp1IqiWlDf4LIxvSY=; b=tMSZ7I7dBEdIq8+yGS+7qiuuCSrZhY1J3bf63frc7tBmCAFmOWPQ0HQRna5/JFIY0H slMsT+KLKAJgGThFHA61M01Qi1CnR33roJ+Cj1O46mqF1Ou1wuLDJZ2/8fvUD7NX2k4t /LxHY1VpbZ8xG3066tKR9ajXbmUUWFiwUKGCu09mYxEG6EKPIIZAPkRzsbIa622j3dHI oM8OB6u/WSBZQ1ydhWd3u+BpNpiNFZkEtQ73GKAuzPUaCWQ2hhI3yBA/imcENkzDwKng pKUyCoCKB/zQOJjxuZrwXO32ruKgeY6RoG3ATKsMkx0pRMQd928qColxeH+KTFPU3GBd Ah8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=f0EI4XXWCZ4ng1p2aav2UrGfV4pp1IqiWlDf4LIxvSY=; b=LPETBvc0M3ooLuUFvOKifRdPYZ2SvIh3IXGKMGWJRZ5SrsR1R6DDW51nKV1bH44muN Hn2rFxc2CjAhxpyPEORCE4hnv4ooY3TSnbntq7S98tWgF/Vbn+xko7fptvdwc88VKwwq 83OWf4OXgjtyZVyrPQBnDpXkVNBRposkBwFHMw6TPuk0owk21/W1g2NsIwolNwRrlVCF ri2NAadteJhZyyiTlPGjAYbHLW5sDQKoSbpbOiIG9zew7VZQ4r0N0h/KjyIeMEj47IEF g0/718jblMrSpUqYnPAhWxXhneC9jP/xmKiTR51LjkRqhHuX53EVylth3BTWY4jgQkYf 5T1A== X-Gm-Message-State: AG10YOTlmy0JeiRQ2uKRUORatPjTdc8qN9U/HJvl1Q6JMwI9ZGc629JkM3tGm6DVsvQf3hkLL1O9zpd64uHJ7wKI X-Received: by 10.37.35.136 with SMTP id j130mr7500983ybj.40.1454362739707; Mon, 01 Feb 2016 13:38:59 -0800 (PST) MIME-Version: 1.0 References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> In-Reply-To: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> From: Warren Kumari Date: Mon, 01 Feb 2016 21:38:50 +0000 Message-ID: To: "Fred Baker (fred)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a113d3e1c79c484052abc3658 Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 21:39:02 -0000 --001a113d3e1c79c484052abc3658 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) wrote: > > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > > "Hein said he supports using IPv6 addresses once per connection and > limiting the lifespan of an IPv6 address to a single connection. Once the > connection is closed, the IPv6 address would be deallocated." > Thought for today. Wouldn't it be better to divide the set of addresses in > use by a host into two - those that others may use to connect to it (and > are probably advertised in DNS) and those that it uses to connect to other > hosts? In a scan of this kind, if the harvested address didn't respond to > an incoming connection, the scan would yield little or no value - even with > a port scan five seconds later. > Something similar (one address per connection) was suggested during some of the privacy addressing discussions a number of years ago (and it made me sad). Modern machines make a *large* number of connections / sessions, and this would require doing the neighbor discovery dance for every connection, and the router tracking large amounts of state (a slot per connection, not just per machine). The bit that I still don't understand --- in an IPv4 world, you *expect* every machine with an IP address to be scanned, almost constantly. Why should things be different in v6 -- is the "plan" really that machines are secure because no-one can guess their IP (security though obscurity)? W > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113d3e1c79c484052abc3658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Feb 1, 2016 at 4:16 PM Fred Baker (fred) <fred@cisco.com> wrote:
http://arstechnica.com/security/2016/02/using-ipv6-with-l= inux-youve-likely-been-visited-by-shodan-and-other-scanners/

"Hein said he supports using IPv6 addresses once per connection and li= miting the lifespan of an IPv6 address to a single connection. Once the con= nection is closed, the IPv6 address would be deallocated."=C2=A0
Thought for today. Wouldn't it be better to divide the set of addresses= in use by a host into two - those that others may use to connect to it (an= d are probably advertised in DNS) and those that it uses to connect to othe= r hosts? In a scan of this kind, if the harvested address didn't respon= d to an incoming connection, the scan would yield little or no value - even= with a port scan five seconds later.

<= div>Something similar (one address per connection) was suggested during som= e of the privacy addressing discussions a number of years ago (and it made = me sad). Modern machines make a *large* number of connections / sessions, a= nd this would require doing the neighbor discovery dance for every connecti= on, and the router tracking large amounts of state (a slot per connection, = not just per machine).


Th= e bit that I still don't understand =C2=A0--- in an IPv4 world, you *ex= pect* every machine with an IP address to be scanned, almost constantly. Wh= y should things be different in v6 -- is the "plan" really that m= achines are secure because no-one can guess their IP (security though obscu= rity)?=C2=A0

=C2=A0W
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a113d3e1c79c484052abc3658-- From nobody Mon Feb 1 13:45:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02D31B3726 for ; Mon, 1 Feb 2016 13:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.501 X-Spam-Level: X-Spam-Status: No, score=-114.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kldsZn8Gxx-m for ; Mon, 1 Feb 2016 13:45:44 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84991B3725 for ; Mon, 1 Feb 2016 13:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4507; q=dns/txt; s=iport; t=1454363143; x=1455572743; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0R5rfI7BUba0NLNA7V7H5tty14tilvyR6yyn6DIk9Vo=; b=W58Bt3iusWrVs+In7w300UF6PpFubnXlhV4FVemecXzke0KBLi8l+UIO 7m4LdgOm6eHfdrVL0D/a+KyMBk5mGgtucQBqdzc3r4ErfYLlU/7mbPN51 +eKxGFr0cg9umzrah5sBNRojq9FMvTaWNppIZMpmZcmiNUw0fitlT90vL s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAgBy0a9W/5pdJa1egm5MgT8GiFKxX?= =?us-ascii?q?A6BZIYPAoE9OBQBAQEBAQEBgQqEQQEBAQMBeQULAgEIBBQuMiUCBA4FDogFCL4?= =?us-ascii?q?FAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiHfIJKh12BDwWWbwGCeYFjiG6OcI49A?= =?us-ascii?q?R4BQ4NsaogyJBl8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,381,1449532800"; d="asc'?scan'208,217";a="71939758" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2016 21:45:42 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u11LjgI6019441 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 21:45:42 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 15:45:42 -0600 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.1104.009; Mon, 1 Feb 2016 15:45:41 -0600 From: "Fred Baker (fred)" To: Warren Kumari Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPq0lOHFaM0UKosnY0g5wI7g== Date: Mon, 1 Feb 2016 21:45:41 +0000 Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.219] Content-Type: multipart/signed; boundary="Apple-Mail=_79C5EEF4-8AC0-4A42-A4AE-0A8EB753F64E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 21:45:45 -0000 --Apple-Mail=_79C5EEF4-8AC0-4A42-A4AE-0A8EB753F64E Content-Type: multipart/alternative; boundary="Apple-Mail=_371FECDB-7AE5-4AEC-9A01-48AE1E1B5773" --Apple-Mail=_371FECDB-7AE5-4AEC-9A01-48AE1E1B5773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 1, 2016, at 1:38 PM, Warren Kumari wrote: >=20 > Something similar (one address per connection) was suggested during = some of the privacy addressing discussions a number of years ago (and it = made me sad). Modern machines make a *large* number of connections / = sessions, and this would require doing the neighbor discovery dance for = every connection, and the router tracking large amounts of state (a slot = per connection, not just per machine). Well, yes, but the reason given for "and then throw the address away" is = to prevent it from being used if it is harvested. I submit that we can = achieve that more simply - by not accepting incoming connections to = addresses we use for outbound connections. If we make the address go = away, we will still see packets to it, we will just not respond to them. = If we make temporary addresses be used only for outbound connections, we = do the same - but without the level of churn. --Apple-Mail=_371FECDB-7AE5-4AEC-9A01-48AE1E1B5773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 1, 2016, at 1:38 PM, Warren Kumari <warren@kumari.net> = wrote:

Something = similar (one address per connection) was suggested during some of the = privacy addressing discussions a number of years ago (and it made me = sad). Modern machines make a *large* number of connections / sessions, = and this would require doing the neighbor discovery dance for every = connection, and the router tracking large amounts of state (a slot per = connection, not just per machine).

Well, yes, but the reason given for "and then = throw the address away" is to prevent it from being used if it is = harvested. I submit that we can achieve that more simply - by not = accepting incoming connections to addresses we use for outbound = connections. If we make the address go away, we will still see packets = to it, we will just not respond to them. If we make temporary addresses = be used only for outbound connections, we do the same - but without the = level of churn.

= --Apple-Mail=_371FECDB-7AE5-4AEC-9A01-48AE1E1B5773-- --Apple-Mail=_79C5EEF4-8AC0-4A42-A4AE-0A8EB753F64E 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 iQIVAwUBVq/SAEayAOS/EQ8MAQLOGQ/+P9W/cTAZ8LgPLU5/GD5AEHMw1a7z/a18 7GC+XJYWrGasAcIQzMFLsDK6PTF+TpRoxV/lwoVq1beHP+cP9dl3rs+lnO0ICbIX rmh655mibi2RNg+acw/i6XjfW98QN6IYJbL0r3ZPejkUbHRuN84mUXyqA6B82xAU J2tayfjE2H25xkaY28aGR1/yhVGm6PZolNySva81oPm+1iKwjp2eMjX0j0f5lI7K Bo4WBGuWUTE7zliQQZwGVNXxZk5bPVT7ubEo/1ovnst/l3ebzZgk6PjuWhq4naUP KMvv6IgVEGeevrb2rH3y/PtGynOLDka7vQIKXIWreLUUJ+BXKsu7cG8LSZriq0Yc wVQHSzQLwXPVP5UesAMvrd+va0bTL9E+1B8uehYnapl4Fl24RrO0ZlN1EXJ2v9KT B0YEYhV2DyP8fdiNNTmbQT8igxBw72tW4emNZ8I4iyaudSy6f2gBK8QCe7Vh28oz iaXF1NVoWhSz3G5AS2Vf953DTAaAL51VoT5760G4oPt/Kv0AZa74piTTI9eAAbTE 1B22iyjc/H5Q+PpFV5v7fXBgSeJsUs8qCLzFR5QcEag9VAg0u0isvKDNWYBZgHvo vge/+OnrCYE6bGwKt7Kms2uLyhwgjHaPtHIENBte1/rwjkUtyCRSpWI4GvzluC+6 /ji6o+YKOqY= =tu9T -----END PGP SIGNATURE----- --Apple-Mail=_79C5EEF4-8AC0-4A42-A4AE-0A8EB753F64E-- From nobody Mon Feb 1 14:03:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0F1B379A for ; Mon, 1 Feb 2016 14:03:26 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYdNZbCvr8jj for ; Mon, 1 Feb 2016 14:03:24 -0800 (PST) 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 22A081B3796 for ; Mon, 1 Feb 2016 14:03:24 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u11M3JYN026130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 22:03:20 GMT (envelope-from joelja@bogus.com) To: Warren Kumari , "Fred Baker (fred)" , "v6ops@ietf.org" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> From: joel jaeggli Message-ID: <56AFD626.1000802@bogus.com> Date: Mon, 1 Feb 2016 14:03:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1PhU816IHjx8T59jpATRQovJpiq4RQ5LO" Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:03:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1PhU816IHjx8T59jpATRQovJpiq4RQ5LO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/1/16 1:38 PM, Warren Kumari wrote: >=20 >=20 > On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) > wrote: >=20 > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve= -likely-been-visited-by-shodan-and-other-scanners/ >=20 > "Hein said he supports using IPv6 addresses once per connection and= > limiting the lifespan of an IPv6 address to a single connection. > Once the connection is closed, the IPv6 address would be deallocate= d."=20 >=20 > Thought for today. Wouldn't it be better to divide the set of > addresses in use by a host into two - those that others may use to > connect to it (and are probably advertised in DNS) and those that i= t > uses to connect to other hosts? In a scan of this kind, if the > harvested address didn't respond to an incoming connection, the sca= n > would yield little or no value - even with a port scan five seconds= > later. >=20 >=20 > Something similar (one address per connection) was suggested during som= e > of the privacy addressing discussions a number of years ago (and it mad= e > me sad). Modern machines make a *large* number of connections / > sessions, and this would require doing the neighbor discovery dance for= > every connection, and the router tracking large amounts of state (a slo= t > per connection, not just per machine). if on the other hand you delegate a prefix to the machine, you can optimize for that case by using it's link-local as the nexthop for the entire prefix, it can use as many ip's as it want's and you never do any ND for any of them. >=20 > The bit that I still don't understand --- in an IPv4 world, you > *expect* every machine with an IP address to be scanned, almost > constantly. Why should things be different in v6 -- is the "plan" reall= y > that machines are secure because no-one can guess their IP (security > though obscurity)?=20 >=20 > W >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --1PhU816IHjx8T59jpATRQovJpiq4RQ5LO 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 iEYEARECAAYFAlav1iYACgkQ8AA1q7Z/VrLADQCeJ8SeKkq3vKwgzKV5Gd41Oamr OAgAn0Oorie7dlsPPKcUKpMcCInDf+b9 =3pFO -----END PGP SIGNATURE----- --1PhU816IHjx8T59jpATRQovJpiq4RQ5LO-- From nobody Mon Feb 1 14:09:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE91B37A3 for ; Mon, 1 Feb 2016 14:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZL1dkvoWfXK for ; Mon, 1 Feb 2016 14:09:47 -0800 (PST) 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 6CBE51B37A0 for ; Mon, 1 Feb 2016 14:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4261; q=dns/txt; s=iport; t=1454364587; x=1455574187; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d+pX+4OZyxU8Aw00mke87kFdWbbb4q8loZDsgJUNyVw=; b=mbajqHbrY0K9umK1VZqNuZoWxhLbEEjeWWpWiZduJ1+vc/xOyljvI9VM aCQ/Hos+TaFxghbBTluhS5w+qhadVrhiqd1f+fr6EKlblbym/C5+YN5QM shgIaSokwEt0vsfSZgzTrCrbfWAb7WgiZrFIyNpVH01+EKlvE0B1Q4iXj A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAgAA169W/4oNJK1egzpSbQaIUrFcD?= =?us-ascii?q?oFkGA6FaQKBPTgUAQEBAQEBAYEKhEEBAQEDAQEBAWsLBQsCAQgYJwcnCxQRAgQ?= =?us-ascii?q?OBQ6IBQgOvgoBAQEBAQEBAQEBAQEBAQEBAQEBAQENCId8gkqHXYEPBZZvAYJ5g?= =?us-ascii?q?WNqiASCJYxLjj0BHgFDggIZgVFqiDIkGXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,382,1449532800"; d="asc'?scan'208";a="69231081" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2016 22:09:46 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u11M9k4v000349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 22:09:46 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 16:09:45 -0600 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.1104.009; Mon, 1 Feb 2016 16:09:45 -0600 From: "Fred Baker (fred)" To: joel jaeggli Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPq0lOHFaM0UKosnY0g5wI7g== Date: Mon, 1 Feb 2016 22:09:45 +0000 Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> In-Reply-To: <56AFD626.1000802@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.219] Content-Type: multipart/signed; boundary="Apple-Mail=_E53FE6B5-8312-4CEC-B0A9-61C4B3DE9637"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:09:49 -0000 --Apple-Mail=_E53FE6B5-8312-4CEC-B0A9-61C4B3DE9637 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 1, 2016, at 2:03 PM, joel jaeggli wrote: >=20 > On 2/1/16 1:38 PM, Warren Kumari wrote: >>=20 >>=20 >> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) > > wrote: >>=20 >> = http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely= -been-visited-by-shodan-and-other-scanners/ >>=20 >> "Hein said he supports using IPv6 addresses once per connection = and >> limiting the lifespan of an IPv6 address to a single connection. >> Once the connection is closed, the IPv6 address would be = deallocated." >>=20 >> Thought for today. Wouldn't it be better to divide the set of >> addresses in use by a host into two - those that others may use to >> connect to it (and are probably advertised in DNS) and those that = it >> uses to connect to other hosts? In a scan of this kind, if the >> harvested address didn't respond to an incoming connection, the = scan >> would yield little or no value - even with a port scan five = seconds >> later. >>=20 >>=20 >> Something similar (one address per connection) was suggested during = some >> of the privacy addressing discussions a number of years ago (and it = made >> me sad). Modern machines make a *large* number of connections / >> sessions, and this would require doing the neighbor discovery dance = for >> every connection, and the router tracking large amounts of state (a = slot >> per connection, not just per machine). >=20 > if on the other hand you delegate a prefix to the machine, you can > optimize for that case by using it's link-local as the nexthop for the > entire prefix, it can use as many ip's as it want's and you never do = any > ND for any of them. However, that's not the issue the article is point out. It's pointing = out that if a harvested address used for an outbound connection can also = be used for an inbound connection, there is a security vulnerability. Warren suggested making the address go away when it is no longer in use. I'm suggesting making the firewall in the host block incoming = connections to temporary addresses, which has the same effect without = the churn. >> The bit that I still don't understand --- in an IPv4 world, you >> *expect* every machine with an IP address to be scanned, almost >> constantly. Why should things be different in v6 -- is the "plan" = really >> that machines are secure because no-one can guess their IP (security >> though obscurity)? >>=20 >> W >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 --Apple-Mail=_E53FE6B5-8312-4CEC-B0A9-61C4B3DE9637 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 iQIVAwUBVq/XqEayAOS/EQ8MAQJ0tRAAme7YvEDN30CZwJVtc+hO2b2VKXx0cFDY hCimg+HHaZchhkXbDqJil/r8bIXQPj6JYWmTWDZsWKc7LADtxiuBCv/Rjw5F6KYg 5YQk8Pk1zvAUNfD0tZFFiiZCjOWZyGPpLsfIIUOQSR5p8rL+7mM7IZvNgmLJMZ3s KNTreEnZftwBC/5e+0D/LMTylcvxDdcYojsvHeBluO8ag9p0QlzlSZbkZeWfBg6H MOXqetqxWNpaCWWnm90rYhErme8a3QjpTAPFRvlgkRt9aP2qa9P907SZ0P4NvxWC 3WaAfWexkH5fcxbDDu0A70mfxxaLXhwqpVZfjyqxCHPOQIl6ks4Ry2V3ouqL0jIq 5CiHVhT6swFSWjnnnkhj8annr/xBXPBb1olpkZQXTQj0MTgKYIIyKkaKeTISqolI e0hLuplshWHqJZTFMC8USQEL0XgMgbjPeBhR7soQ7bKrJo+RRSZqmn5L9b+Li6aO 1yjYKn7PpsqX5aLl1xjipg+uYCm94HrRdPAwqowOovaM45thWJC6ddAbudJx6GMx PqPgmkdgM9v8Ko8rbDV1y9E/VT08Z538v1JruGaIDXEtGMU+4kl0jiRAcff1kRDw hhRkcMPGXx7WFkwL8VwiBI0qh7QTfaQmpqfYEkk42QfGPnHM3tDVv5PlA2nMk4SW 2IfQFnv/PIs= =1y5m -----END PGP SIGNATURE----- --Apple-Mail=_E53FE6B5-8312-4CEC-B0A9-61C4B3DE9637-- From nobody Mon Feb 1 14:10:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA91B37A3 for ; Mon, 1 Feb 2016 14:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrNaBkE2sL4B for ; Mon, 1 Feb 2016 14:10:51 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4241B3796 for ; Mon, 1 Feb 2016 14:10:51 -0800 (PST) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C40C0DA008E; Mon, 1 Feb 2016 22:10:50 +0000 (UTC) Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Mon, 1 Feb 2016 14:10:50 -0800 From: Ted Lemon To: Warren Kumari , "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPkiUQUGq5CECiLP0wylSOSZ8YPZEA//+CzVs= Date: Mon, 1 Feb 2016 22:10:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A124E1@mbx-03.WIN.NOMINUM.COM> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.233.41.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:10:52 -0000 > The bit that I still don't understand --- in an IPv4 world, you *expect*= every machine with an IP address to be scanned, almost constantly. Why sho= uld things be different in v6 -- is the "plan" really that machines are sec= ure because no-one can guess their IP (security though obscurity)? Yes, this is one of the selling features of IPv6. It's not security throu= gh obscurity any more than using a 2048-bit key instead of a 1024-bit key i= s security through obscurity: its a mechanism for increasing the search spa= ce beyond the capability of the attacker to explore it economically. From nobody Mon Feb 1 14:28:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057111B37A6 for ; Mon, 1 Feb 2016 14:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbJvxTIDZfhi for ; Mon, 1 Feb 2016 14:28:12 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6221B37E1 for ; Mon, 1 Feb 2016 14:28:11 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u11MP3xG027668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Feb 2016 14:25:05 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_1D4F3E77-5399-4C33-B908-44EE97A5D215" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: Date: Mon, 1 Feb 2016 14:25:03 -0800 Message-Id: <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 01 Feb 2016 14:25:05 -0800 (PST) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:28:15 -0000 --Apple-Mail=_1D4F3E77-5399-4C33-B908-44EE97A5D215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It=92s rather amusing watching you guys talk past each other without = realizing that you=92re basically saying mostly the same thing with = slightly different approaches that could actually work together. Approach 1: Address goes poof as soon as it is finished with outbound = connection. Pros: Easily implemented, doesn=92t significantly change = existing codebases. Cons: Absurd excessive neighbor discovery traffic Workaround: Make every host a router. Assign all the temporary = prefixes from a subnet assigned to the loopback interface and route via LL address of ethernet interface(s). Pros: Easily implemented, solves problem Cons: potentially excessive prefix consumption, possibly = very excessive, potential unexpected consequences of host being made into a router, potentially without administrator = realizing that has occurred. (violates principle of least surprise) =09 Approach 2: Address can stay (or not), but temporary addresses are = flagged for outbound only and host-firewall is automatically configured to reject inbound session initiation = packets to that address. Pros: Eliminates ND issues for the most part, efficient, doesn=92t= require every host to become a router. Cons: Significant code changes to most hosts to implement this = functionality, couples a number of previously uncoupled systems, high probability of user confusion (violates principle = of least surprise). The thing that strikes me most about this is that a host which has an = adequate stateful inspection firewall in front of it realy has no more = issue from it=92s IPv6 address being harvested than it does from its IPv4 = address being harvested, so I=92m not seeing how this is news or how it = really represents any sort of inherent vulnerability. Perhaps someone can enlighten me as to how this is some new security = issue we should be concerned about, but for now, it appears to me as if = it is much ado about nothing. Owen > On Feb 1, 2016, at 14:09 , Fred Baker (fred) wrote: >=20 >>=20 >> On Feb 1, 2016, at 2:03 PM, joel jaeggli wrote: >>=20 >> On 2/1/16 1:38 PM, Warren Kumari wrote: >>>=20 >>>=20 >>> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) >> > wrote: >>>=20 >>> = http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely= -been-visited-by-shodan-and-other-scanners/ >>>=20 >>> "Hein said he supports using IPv6 addresses once per connection = and >>> limiting the lifespan of an IPv6 address to a single connection. >>> Once the connection is closed, the IPv6 address would be = deallocated." >>>=20 >>> Thought for today. Wouldn't it be better to divide the set of >>> addresses in use by a host into two - those that others may use to >>> connect to it (and are probably advertised in DNS) and those that = it >>> uses to connect to other hosts? In a scan of this kind, if the >>> harvested address didn't respond to an incoming connection, the = scan >>> would yield little or no value - even with a port scan five = seconds >>> later. >>>=20 >>>=20 >>> Something similar (one address per connection) was suggested during = some >>> of the privacy addressing discussions a number of years ago (and it = made >>> me sad). Modern machines make a *large* number of connections / >>> sessions, and this would require doing the neighbor discovery dance = for >>> every connection, and the router tracking large amounts of state (a = slot >>> per connection, not just per machine). >>=20 >> if on the other hand you delegate a prefix to the machine, you can >> optimize for that case by using it's link-local as the nexthop for = the >> entire prefix, it can use as many ip's as it want's and you never do = any >> ND for any of them. >=20 > However, that's not the issue the article is point out. It's pointing = out that if a harvested address used for an outbound connection can also = be used for an inbound connection, there is a security vulnerability. >=20 > Warren suggested making the address go away when it is no longer in = use. >=20 > I'm suggesting making the firewall in the host block incoming = connections to temporary addresses, which has the same effect without = the churn. >=20 >=20 >>> The bit that I still don't understand --- in an IPv4 world, you >>> *expect* every machine with an IP address to be scanned, almost >>> constantly. Why should things be different in v6 -- is the "plan" = really >>> that machines are secure because no-one can guess their IP (security >>> though obscurity)? >>>=20 >>> W >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_1D4F3E77-5399-4C33-B908-44EE97A5D215 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It=92s rather amusing watching you guys talk past each other = without realizing that you=92re basically saying mostly the same thing = with slightly different approaches that could actually work = together.

Approach = 1: Address goes poof as soon as it is finished with outbound = connection.
Pros: Easily implemented, doesn=92t= significantly change existing codebases.
Cons: = Absurd excessive neighbor discovery traffic
= Workaround: Make every host a router. Assign all the temporary = prefixes from a subnet assigned to the loopback interface and = route
via LL address of = ethernet interface(s).
Pros: Easily implemented, = solves problem
Cons: potentially = excessive prefix consumption, possibly very excessive, potential = unexpected consequences of host being made
= into a router, potentially without administrator realizing that = has occurred. (violates principle of least surprise)
=

Approach= 2: Address can stay (or not), but temporary addresses are flagged for = outbound only and host-firewall
is = automatically configured to reject inbound session initiation packets to = that address.

= Pros: Eliminates ND issues for the most part, efficient, doesn=92t = require every host to become a router.
Cons: = Significant code changes to most hosts to implement this functionality, = couples a number of previously uncoupled systems,
= high probability of user confusion (violates principle of least = surprise).

The = thing that strikes me most about this is that a host which has an = adequate stateful inspection firewall in front of it realy has no more = issue
from it=92s IPv6 address being harvested than = it does from its IPv4 address being harvested, so I=92m not seeing how = this is news or how it really
represents any sort = of inherent vulnerability.

Perhaps someone can enlighten me as to how this is some new = security issue we should be concerned about, but for now, it appears to = me as if it is much ado about nothing.

Owen

On Feb 1, 2016, at 14:09 , Fred Baker (fred) = <fred@cisco.com> = wrote:


On Feb 1, 2016, at 2:03 PM, joel = jaeggli <joelja@bogus.com> wrote:

On= 2/1/16 1:38 PM, Warren Kumari wrote:


On Mon, Feb 1, = 2016 at 4:16 PM Fred Baker (fred) <fred@cisco.com
<mailto:fred@cisco.com>> wrote:

  http://arstechnica.com/security/2016/02/using-ipv6-with-linux-y= ouve-likely-been-visited-by-shodan-and-other-scanners/

  "Hein said he supports using IPv6 = addresses once per connection and
  limiting the = lifespan of an IPv6 address to a single connection.
  Once the connection is closed, the IPv6 address = would be deallocated."

  Thought = for today. Wouldn't it be better to divide the set of
  addresses in use by a host into two - those that = others may use to
  connect to it (and are = probably advertised in DNS) and those that it
  uses to connect to other hosts? In a scan of this = kind, if the
  harvested address didn't respond = to an incoming connection, the scan
  would = yield little or no value - even with a port scan five seconds
  later.


Something similar (one address per connection) was suggested = during some
of the privacy addressing discussions a number = of years ago (and it made
me sad). Modern machines make a = *large* number of connections /
sessions, and this would = require doing the neighbor discovery dance for
every = connection, and the router tracking large amounts of state (a slot
per connection, not just per machine).

if on the other hand you delegate = a prefix to the machine, you can
optimize for that case by = using it's link-local as the nexthop for the
entire = prefix, it can use as many ip's as it want's and you never do any
ND for any of them.

However, that's not the = issue the article is point out. It's pointing out that if a harvested = address used for an outbound connection can also be used for an inbound = connection, there is a security vulnerability.

Warren suggested making the address go = away when it is no longer in use.

I'm suggesting making the firewall in the host = block incoming connections to temporary addresses, which has the same = effect without the churn.


The bit that I still = don't understand  --- in an IPv4 world, you
*expect* = every machine with an IP address to be scanned, almost
constantly. Why should things be different in v6 -- is the = "plan" really
that machines are secure because no-one can = guess their IP (security
though obscurity)?

W

  _______________________________________________
  v6ops mailing list
  v6ops@ietf.org <mailto:v6ops@ietf.org>  https://www.ietf.org/mailman/listinfo/v6ops



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops




_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_1D4F3E77-5399-4C33-B908-44EE97A5D215-- From nobody Mon Feb 1 15:04:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3B1B3872 for ; Mon, 1 Feb 2016 15:04:55 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTCxiHA-uKcf for ; Mon, 1 Feb 2016 15:04:50 -0800 (PST) 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 3F5A41B3871 for ; Mon, 1 Feb 2016 15:04:50 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u11N4kgp026451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 23:04:47 GMT (envelope-from joelja@bogus.com) To: "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56AFE48E.2060606@bogus.com> Date: Mon, 1 Feb 2016 15:04:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="988SptwssIt8f6CUw2EFfrg7pRo2jEaIH" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:04:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --988SptwssIt8f6CUw2EFfrg7pRo2jEaIH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/1/16 2:09 PM, Fred Baker (fred) wrote: >=20 >> On Feb 1, 2016, at 2:03 PM, joel jaeggli wrote: >>=20 >> On 2/1/16 1:38 PM, Warren Kumari wrote: >>>=20 >>>=20 >>> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) >> > wrote: >>>=20 >>> http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-l= ikely-been-visited-by-shodan-and-other-scanners/ >>> >>> >>> >>>=20 "Hein said he supports using IPv6 addresses once per connection and >>> limiting the lifespan of an IPv6 address to a single connection. >>> Once the connection is closed, the IPv6 address would be=20 >>> deallocated." >>>=20 >>> Thought for today. Wouldn't it be better to divide the set of=20 >>> addresses in use by a host into two - those that others may use=20 >>> to connect to it (and are probably advertised in DNS) and those=20 >>> that it uses to connect to other hosts? In a scan of this kind,=20 >>> if the harvested address didn't respond to an incoming=20 >>> connection, the scan would yield little or no value - even with >>> a port scan five seconds later. >>>=20 >>>=20 >>> Something similar (one address per connection) was suggested=20 >>> during some of the privacy addressing discussions a number of=20 >>> years ago (and it made me sad). Modern machines make a *large*=20 >>> number of connections / sessions, and this would require doing=20 >>> the neighbor discovery dance for every connection, and the >>> router tracking large amounts of state (a slot per connection, >>> not just per machine). >>=20 >> if on the other hand you delegate a prefix to the machine, you can >> optimize for that case by using it's link-local as the nexthop >> for the entire prefix, it can use as many ip's as it want's and >> you never do any ND for any of them. >=20 > However, that's not the issue the article is point out. It's > pointing out that if a harvested address used for an outbound > connection can also be used for an inbound connection, there is a > security vulnerability. >=20 > Warren suggested making the address go away when it is no longer in=20 > use. >=20 > I'm suggesting making the firewall in the host block incoming=20 > connections to temporary addresses, which has the same effect > without the churn. it is perhaps reasonable to expect for modern hosts (and devices like CPE) to implement stateful inspection firewalls. Some devices have listening services. it would seem natural for listening services to be bound to some IPs and not others (though all of them is probably also relatively normal). if you're going to use addresses ephemerally it would see reasonable to not accept incoming connections on those IPs. If an ND entry is required for every IP you use that cost gets borne by any router requiring an ND entry until the cache expires irrespective of your intent to answer or not. >=20 >>> The bit that I still don't understand --- in an IPv4 world, you >>> *expect* every machine with an IP address to be scanned, almost >>> constantly. Why should things be different in v6 -- is the >>> "plan" really that machines are secure because no-one can guess >>> their IP (security though obscurity)? >>> W >>>=20 >>> _______________________________________________ v6ops mailing=20 >>> list v6ops@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>>=20 >>> _______________________________________________ v6ops mailing=20 >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >=20 --988SptwssIt8f6CUw2EFfrg7pRo2jEaIH 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 iEYEARECAAYFAlav5I4ACgkQ8AA1q7Z/VrImRQCfRWm5DpJAM5LNCHBbAfeAZ9H2 Q+kAnioNByMs1wXfO2vJSTCUyNdSgf+/ =KUhy -----END PGP SIGNATURE----- --988SptwssIt8f6CUw2EFfrg7pRo2jEaIH-- From nobody Mon Feb 1 15:12:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596271B387F for ; Mon, 1 Feb 2016 15:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMIMSbROR-OB for ; Mon, 1 Feb 2016 15:11:58 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFAE1B2E5F for ; Mon, 1 Feb 2016 15:11:57 -0800 (PST) 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)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 9202D1FCC3C; Mon, 1 Feb 2016 23:11:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9F2A6160047; Mon, 1 Feb 2016 23:12:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8F2EA16004A; Mon, 1 Feb 2016 23:12:10 +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 3SKtHDgOwcwE; Mon, 1 Feb 2016 23:12:10 +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 5108D160047; Mon, 1 Feb 2016 23:12:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 25706414D77A; Tue, 2 Feb 2016 10:11:51 +1100 (EST) To: fred@cisco.com From: Mark Andrews References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> In-reply-to: Your message of "Mon, 01 Feb 2016 06:00:17 -0800." <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> Date: Tue, 02 Feb 2016 10:11:51 +1100 Message-Id: <20160201231151.25706414D77A@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:11:59 -0000 draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed at the v6man and v6ops chairs - should this be a v6man or v6ops? It needs to be fixed and I don't care in which forum it gets done but it needs to be done. Mark In message <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com>, fred@cisco.com writes: > RFC Editor: AUTH48 > 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption > 2015-10-26 draft-ietf-v6ops-siit-dc > 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat > 2015-10-26 draft-ietf-v6ops-siit-eam > > RFC Editor: In ISE Review > 2016-01-20 draft-ietf-v6ops-mobile-device-profile > > IESG: AD Evaluation > 2016-01-31 draft-bao-v6ops-rfc6145bis > > IESG: In Last Call > 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world > > WG: Unupdated WG Document > 2015-10-19 draft-ietf-v6ops-design-choices > > WG: Updated WG Document > 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host > 2016-01-03 draft-ietf-v6ops-host-addr-availability > > Individual Submission: Unupdated > 2015-10-19 draft-xu-v6ops-dslite-redundancy > 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops > 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack > > Individual Submission: Updated > 2016-01-05 draft-templin-v6ops-pdhost > 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment > 2016-01-03 draft-xli-v6ops-cernet-deployment > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 1 16:22:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0C01A1A1D for ; Mon, 1 Feb 2016 16:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i9_LGdCgVlr for ; Mon, 1 Feb 2016 16:22:08 -0800 (PST) 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 6F8721A1A1C for ; Mon, 1 Feb 2016 16:22:06 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id l66so95669011wml.0 for ; Mon, 01 Feb 2016 16:22:06 -0800 (PST) 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:content-type; bh=I5CpYNFhB/3ZH0fOnarHxi/IqfY4nN2o4k0hFh4gD9A=; b=YiykT83xNonP37Sv8rj/209fwvDIXZdfvLx+YvKunS0S5Bod+jQXGyA90fYtOIfw0x +8g5DWYHUyp3TnqmQxDE622x/5b0J9WUoP2USh2xhAActYYlep9yT5eUZKZ2k7CuhMph KxlNgrzy5K/X1rnsPBwsAUjsfAdRCm/h6SBFjsR7t/NsMDNK35ACVTtKH/D7wMeP4yuP LxoyMboidfkfHMbYva48ufG1vSYUxPt81m9rZyqpilh8CvBsBjIVXAk0NqYE6jXqU3+e ddOXbPy8jE2eiiACM1b9QTJOCujq2YI0OlGbFXUAj/2Q8oS30KhkbT8EFOhpIWsMjbDe R6aw== 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-type; bh=I5CpYNFhB/3ZH0fOnarHxi/IqfY4nN2o4k0hFh4gD9A=; b=hxc3fBMzyLFbpfaBNMkhkyS0mmdZ4HnIUdl/w3acG4SJrPJwcQSDvgqZTt2p8aFoS/ CU1yxA6N0UlTjCGmSAK9+0Hk3EL141KMhtdRlGdqoloF/o5nGZFuzZBxmzmRJyP3PLzL 5v9JmXovRaihB6vIfZOqMq59GcP5mDUzpYxDBDhYfMvSRcR5iLQA0T6gzs6tsvY7ICi/ s9zdpNaqWZ5pd7sKqxI7DYgc0p1URu6Wnnt73DKHYbtPpUUG6cYbulhMr6bGZ5FUT9AZ 4fZ76c52LQ/fj92EYKIVIzIMHCLLQez+1J2TOccSljAtdjF23ElcBI8dwlEgJW4dHNkA F/tQ== X-Gm-Message-State: AG10YOS/3inFYttWebfghOHeh5QsNnvkR0iACwEerMWELwAHMFhyRW3py1TfBrg8gdACxZiUkKmH03m6gcPf7w== MIME-Version: 1.0 X-Received: by 10.194.76.144 with SMTP id k16mr24940627wjw.78.1454372524913; Mon, 01 Feb 2016 16:22:04 -0800 (PST) Received: by 10.194.68.66 with HTTP; Mon, 1 Feb 2016 16:22:04 -0800 (PST) In-Reply-To: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> Date: Mon, 1 Feb 2016 16:22:04 -0800 Message-ID: From: Ca By To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7bfceebcb7fe0f052abe7d58 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 00:22:10 -0000 --047d7bfceebcb7fe0f052abe7d58 Content-Type: text/plain; charset=UTF-8 On Monday, February 1, 2016, Fred Baker (fred) wrote: > > > On Feb 1, 2016, at 2:03 PM, joel jaeggli > wrote: > > > > On 2/1/16 1:38 PM, Warren Kumari wrote: > >> > >> > >> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) > >> >> wrote: > >> > >> > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > >> > >> "Hein said he supports using IPv6 addresses once per connection and > >> limiting the lifespan of an IPv6 address to a single connection. > >> Once the connection is closed, the IPv6 address would be > deallocated." > >> > >> Thought for today. Wouldn't it be better to divide the set of > >> addresses in use by a host into two - those that others may use to > >> connect to it (and are probably advertised in DNS) and those that it > >> uses to connect to other hosts? In a scan of this kind, if the > >> harvested address didn't respond to an incoming connection, the scan > >> would yield little or no value - even with a port scan five seconds > >> later. > >> > >> > >> Something similar (one address per connection) was suggested during some > >> of the privacy addressing discussions a number of years ago (and it made > >> me sad). Modern machines make a *large* number of connections / > >> sessions, and this would require doing the neighbor discovery dance for > >> every connection, and the router tracking large amounts of state (a slot > >> per connection, not just per machine). > > > > if on the other hand you delegate a prefix to the machine, you can > > optimize for that case by using it's link-local as the nexthop for the > > entire prefix, it can use as many ip's as it want's and you never do any > > ND for any of them. > > However, that's not the issue the article is point out. It's pointing out > that if a harvested address used for an outbound connection can also be > used for an inbound connection, there is a security vulnerability. > > Warren suggested making the address go away when it is no longer in use. > > I'm suggesting making the firewall in the host block incoming connections > to temporary addresses, which has the same effect without the churn. > > Why is this firewall only for temp addresses ? If the host is not listening on that port, why do you need a fw? At the end of the day, these are app issues (shodan tries default password ) and network should stay out of it. > > >> The bit that I still don't understand --- in an IPv4 world, you > >> *expect* every machine with an IP address to be scanned, almost > >> constantly. Why should things be different in v6 -- is the "plan" really > >> that machines are secure because no-one can guess their IP (security > >> though obscurity)? > >> > >> W > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > > --047d7bfceebcb7fe0f052abe7d58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, February 1, 2016, Fred Baker (fred) <fred@cisco.com> wrote:

> On Feb 1, 2016, at 2:03 PM, joel jaeggli <joelja@bo= gus.com> wrote:
>
> On 2/1/16 1:38 PM, Warren Kumari wrote:
>>
>>
>> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) <fred@cisco.com
>> <mailto:fred@cisco.com>> wrote:
>>
>>=C2=A0 =C2=A0 http://arstechnica.com/security/2016/02/using-ipv6-with= -linux-youve-likely-been-visited-by-shodan-and-other-scanners/
>>
>>=C2=A0 =C2=A0 "Hein said he supports using IPv6 addresses once= per connection and
>>=C2=A0 =C2=A0 limiting the lifespan of an IPv6 address to a single = connection.
>>=C2=A0 =C2=A0 Once the connection is closed, the IPv6 address would= be deallocated."
>>
>>=C2=A0 =C2=A0 Thought for today. Wouldn't it be better to divid= e the set of
>>=C2=A0 =C2=A0 addresses in use by a host into two - those that othe= rs may use to
>>=C2=A0 =C2=A0 connect to it (and are probably advertised in DNS) an= d those that it
>>=C2=A0 =C2=A0 uses to connect to other hosts? In a scan of this kin= d, if the
>>=C2=A0 =C2=A0 harvested address didn't respond to an incoming c= onnection, the scan
>>=C2=A0 =C2=A0 would yield little or no value - even with a port sca= n five seconds
>>=C2=A0 =C2=A0 later.
>>
>>
>> Something similar (one address per connection) was suggested durin= g some
>> of the privacy addressing discussions a number of years ago (and i= t made
>> me sad). Modern machines make a *large* number of connections / >> sessions, and this would require doing the neighbor discovery danc= e for
>> every connection, and the router tracking large amounts of state (= a slot
>> per connection, not just per machine).
>
> if on the other hand you delegate a prefix to the machine, you can
> optimize for that case by using it's link-local as the nexthop for= the
> entire prefix, it can use as many ip's as it want's and you ne= ver do any
> ND for any of them.

However, that's not the issue the article is point out. It's pointi= ng out that if a harvested address used for an outbound connection can also= be used for an inbound connection, there is a security vulnerability.

Warren suggested making the address go away when it is no longer in use.
I'm suggesting making the firewall in the host block incoming connectio= ns to temporary addresses, which has the same effect without the churn.


Why is this firewall only for temp add= resses ?

If the host is not listening on that port= , why do you need a fw?

At the end of the day, the= se are app issues (shodan tries default password ) and network should stay = out of it.=C2=A0=C2=A0

>> The bit that I still don't understand=C2=A0 --- in an IPv4 wor= ld, you
>> *expect* every machine with an IP address to be scanned, almost >> constantly. Why should things be different in v6 -- is the "p= lan" really
>> that machines are secure because no-one can guess their IP (securi= ty
>> though obscurity)?
>>
>> W
>>
>>=C2=A0 =C2=A0 _______________________________________________
>>=C2=A0 =C2=A0 v6ops mailing list
>>=C2=A0 =C2=A0 v6ops@ietf.org <mailto:v6ops@ietf.org>
>>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>

--047d7bfceebcb7fe0f052abe7d58-- From nobody Tue Feb 2 00:39:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1846B1A89F6 for ; Mon, 1 Feb 2016 23:56:51 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMXzY5jsOGMk for ; Mon, 1 Feb 2016 23:56:50 -0800 (PST) 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 F40EA1A89E9 for ; Mon, 1 Feb 2016 23:56:49 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 D8164206A7E; Tue, 2 Feb 2016 08:56:46 +0100 (CET) To: Owen DeLong , "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B06129.7090301@si6networks.com> Date: Tue, 2 Feb 2016 04:56:25 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:56:51 -0000 On 02/01/2016 07:25 PM, Owen DeLong wrote: [...] > > The thing that strikes me most about this is that a host which has an > adequate stateful inspection firewall in front of it realy has no more issue > from it’s IPv6 address being harvested than it does from its IPv4 > address being harvested, so I’m not seeing how this is news or how it really > represents any sort of inherent vulnerability. > > Perhaps someone can enlighten me as to how this is some new security > issue we should be concerned about, but for now, it appears to me as if > it is much ado about nothing. Maybe in that in IPv4 you typically have a NAT in front of your node, where in IPv6 you don't necessarily have a fw? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 00:39:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A111A8A41 for ; Tue, 2 Feb 2016 00:01:34 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2FPY83sEpNd for ; Tue, 2 Feb 2016 00:01:32 -0800 (PST) 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 5B76E1A8A15 for ; Tue, 2 Feb 2016 00:01:32 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 70E27206A7C; Tue, 2 Feb 2016 09:01:28 +0100 (CET) To: Ca By , "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B06233.9070809@si6networks.com> Date: Tue, 2 Feb 2016 05:00:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:01:34 -0000 On 02/01/2016 09:22 PM, Ca By wrote: [....] > > However, that's not the issue the article is point out. It's > pointing out that if a harvested address used for an outbound > connection can also be used for an inbound connection, there is a > security vulnerability. > > Warren suggested making the address go away when it is no longer in use. > > I'm suggesting making the firewall in the host block incoming > connections to temporary addresses, which has the same effect > without the churn. > > > Why is this firewall only for temp addresses ? > > If the host is not listening on that port, why do you need a fw? Among other reasons, because of this sort of thing: -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 00:39:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274FC1AC3CD; Tue, 2 Feb 2016 00:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBLn0DqrxOkF; Tue, 2 Feb 2016 00:36:07 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79221AC3CC; Tue, 2 Feb 2016 00:36:07 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F36E3D7884; Tue, 2 Feb 2016 00:36:05 -0800 (PST) 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=MseW3nzPW1TKnPG9gx8hJSGO+2o=; b= ENxSOrfYSmGAn+lGnJbviA7Ccfpoc2op1AVPlfodqBvyZKzQRwRtl8rhbH8lWIC4 LuZGaoE/NLYhPITivCq+MPpAFwUqcxxnlqoAUFvtOBSNXh4r3j7unpDTY00+byQ4 scd3vhcBkhUT9AkTFeZljqRBro8JNPkAlhQhoZ6dxYs= 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=jLevplR6VBrhWZmdhIFthXa3Tk RFzVzzJo4Hdsv/mdpwtCBVPGI13NXRBGhvu/1m60WMOQrnjT1eT3QklolS22h3j4 F3dmfDRrrENXf+YJD7PHZ9EGB3UEH/n1N8FsPdknvdEAb18vASVxoee++mu/ThY4 Y2fzXrEAOJt5pmRSo= Received: from h.hanazo.no (unknown [173.38.220.53]) (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 8376CD7882; Tue, 2 Feb 2016 00:36:05 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 00E65FC74D8; Tue, 2 Feb 2016 09:36:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_19273F70-E38D-4231-BB1C-CF5BDAE3F7EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160202035520.9932E415A9C9@rock.dv.isc.org> Date: Tue, 2 Feb 2016 09:36:02 +0100 Message-Id: References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> <20160202035520.9932E415A9C9@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org WG" , 6man WG Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:36:10 -0000 --Apple-Mail=_19273F70-E38D-4231-BB1C-CF5BDAE3F7EC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mark, >> When you say "v6man", I assume you mean "6man". > > yep. > >> I'm a little lost. I don't see the words "chair" or "question" in the = >> draft. Could you be more specific about what your question is? > > Which WG should take ownership of the problem space in this draft? is this an implementation bug, specification bug or both? Best regards, Ole > >>> On Feb 1, 2016, at 3:11 PM, Mark Andrews wrote: >>> =20 >>> =20 >>> draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed >>> at the v6man and v6ops chairs - should this be a v6man or v6ops? It >>> needs to be fixed and I don't care in which forum it gets done but it >>> needs to be done. >>> =20 >>> Mark >>> =20 >>> In message <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com>, = >> fred@cisco.com writes: >>>> RFC Editor: AUTH48 >>>> 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption >>>> 2015-10-26 draft-ietf-v6ops-siit-dc >>>> 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat >>>> 2015-10-26 draft-ietf-v6ops-siit-eam >>>> =20 >>>> RFC Editor: In ISE Review >>>> 2016-01-20 draft-ietf-v6ops-mobile-device-profile >>>> =20 >>>> IESG: AD Evaluation >>>> 2016-01-31 draft-bao-v6ops-rfc6145bis >>>> =20 >>>> IESG: In Last Call >>>> 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world >>>> =20 >>>> WG: Unupdated WG Document >>>> 2015-10-19 draft-ietf-v6ops-design-choices >>>> =20 >>>> WG: Updated WG Document >>>> 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host >>>> 2016-01-03 draft-ietf-v6ops-host-addr-availability >>>> =20 >>>> Individual Submission: Unupdated >>>> 2015-10-19 draft-xu-v6ops-dslite-redundancy >>>> 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops >>>> 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack >>>> =20 >>>> Individual Submission: Updated >>>> 2016-01-05 draft-templin-v6ops-pdhost >>>> 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment >>>> 2016-01-03 draft-xli-v6ops-cernet-deployment >>>> =20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> >> --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89 >> 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 >> >> iQIVAwUBVrAnTkayAOS/EQ8MAQL9Ug//e/6aNfv+AC2Iv2qAp6MjcIYyRcqRZLew >> hhXABkYFTk+/FPHe57xZ4W7h4eEpJ7L8Fha+M+tEzB1ydNc/n/3NsThP6iZCsIYE >> lemKravU5zMVEvGLeWoaj9YUdKXzlqgIT6TjcE/0wuyUS6a5MotVMXqLKNkwbwg5 >> IIX1lZNeSWmc7dtWUIeh9/UzgzlGap9Nd0+MhQVoWvPXgNv4Xvq9AhFSOZsz3r1L >> dtiOGn6cwypfrNleDt7D62jtWpmtyM/R7CjDBVhEhDVXyEiEt5/BfPnfB8e5+Ozt >> +PvIPw7rPe3Y6tg37kZLTySOiHiJ0UDPCwk7B3KQtYlnfKjFmQ0w8aad+I9Gw7x6 >> FtUuMZZn5GDzkzR1dpBMr9J2KGjtwO7szDo8C/ZONEfwzTkXwepvxfZoW8eQuTIu >> E09eFvtUmmpE5w3K9sU/8ku8h+rtNf85GO5rozDwGBlflZAnRHpE61UZZqHAenBm >> HZIdLBxpZ56RQYzCN+ifrjR4ELTIfI0tUWVJSUWuW34hTpYfLFxWvi+BLLwnDbyC >> brKIPmBtpks6HKctM/D4YBDiLC0/ZvvsmlWnzCX1ZxdkzZNm0Ah0rSvSP7I/wICA >> x6tcJPMrUehuA13koaI++2SE7mI87wZb8DygbnxobCgwRwKJz2JgjATFPoV3Asyz >> whJD47Pn2t8= >> =0jdz >> -----END PGP SIGNATURE----- >> >> --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_19273F70-E38D-4231-BB1C-CF5BDAE3F7EC 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 iQIcBAEBCgAGBQJWsGpyAAoJEL7aWKiYQt92O7sQAJzx6xjmS0K7pNjzzU1WoSxT /PCAbCin7vnDMqbk8758z16l6F1pbZ1gWNkIPagiCMHbgAkSwkGU1Fj+j4qEWvcY EeF/1rcCbQNcWqGQZuopabI9uEHxMbvVKpPPmRwLPwq9UUIgimpYn2cyYg1umZU9 3stWAq/XrYH7BND96Pyb8hbFI660UqyfJJrmyRVxH+SrGboEF5JyI+sGEgFIqe3b RzY/6tJWtyFqtTlaq8ooqWQsNcWsaz0opbM5dvYY8/VshznSbKSEPxcCDq98hSnm kZKYJYG+ttWpkhTVwMAM6jso/WGw5eaSdzf5jpu1atZE69+IXYa60/aIbjpwaKQg KjA13wd59mywEqwr+R2HcjNDCU3x2twkV6vWXlIjh933TusOjYsloFcPX3U9rtwZ 1k3Nlc61Gl2uXd7B3RT5hnHli2BaWV7WYdwWeAxVdlzn18lf/dXVnGvDlWQ8cTDu VInpjJtloXitwd0Cp7m6P+j2BevlFceYRw/H2GP7yeviuRl5q8o9/43ZA/nxsvRg G+j2ZGrXTw9QzeP/QeKdvxncPh2rZdxS5iVo8k6c3eld1/TwLoYnrvkhL0NkmknD 60ZPNIjpktABM6zDM3Qosky6JyAWP4Bn7NIDlkHgl3IjsWmCHQCvHj6B8bzblfQb aiwCeoX2d+QQgd6eIYJu =UHdx -----END PGP SIGNATURE----- --Apple-Mail=_19273F70-E38D-4231-BB1C-CF5BDAE3F7EC-- From nobody Tue Feb 2 00:39:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096EE1ACDFA; Mon, 1 Feb 2016 19:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsKtAFx6lL_A; Mon, 1 Feb 2016 19:49:36 -0800 (PST) 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 86DD01ACDF6; Mon, 1 Feb 2016 19:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3339; q=dns/txt; s=iport; t=1454384976; x=1455594576; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KOj6kmKAY4KUfzRC7x9cR/SAkh6uBJuTRsi6+uH3MzE=; b=eqAEYRXcwok0Q7iaYUiQPvZl6ONU2ldAbHVcilzJasxfwPzTF8pOyDbP wG4HANdZOs4cctA5DKcXyx2EKJ0BgSVhLXP1a7veMRWIm1ZpmO6xPArMc L9GFX3VpIv0b+MNzXhRFllh0zbv3LTuvh/MtnQT3uIvfi7TfAfwMW+/9V 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgD9JbBW/5hdJa1egzpSbQaIU7FfD?= =?us-ascii?q?oFkGAqFbQKBNTgUAQEBAQEBAYEKhEEBAQEDAQEBAWsLBQkCAgEIGC4bDAslAgQ?= =?us-ascii?q?OBQ6IBQgOvgQBAQEBAQEBAQEBAQEBAQEBAQEBAQENBAQEh3iCSoddgQ8FlnEBg?= =?us-ascii?q?nmBY4hugVuNFYpsg1EBHgFDg2xqAYhufAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,383,1449532800"; d="asc'?scan'208";a="233236157" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 03:49:35 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u123nZcZ012197 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 03:49:35 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 21:49:34 -0600 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.1104.009; Mon, 1 Feb 2016 21:49:34 -0600 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] State of play Thread-Index: AQHRXWy7WKRnV1axq0Cue0ZfkN2Y9w== Date: Tue, 2 Feb 2016 03:49:34 +0000 Message-ID: <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> In-Reply-To: <20160201231151.25706414D77A@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.81] Content-Type: multipart/signed; boundary="Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , IPv6 IPv6 List Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 03:49:38 -0000 --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii When you say "v6man", I assume you mean "6man". I'm a little lost. I don't see the words "chair" or "question" in the = draft. Could you be more specific about what your question is? > On Feb 1, 2016, at 3:11 PM, Mark Andrews wrote: >=20 >=20 > draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed > at the v6man and v6ops chairs - should this be a v6man or v6ops? It > needs to be fixed and I don't care in which forum it gets done but it > needs to be done. >=20 > Mark >=20 > In message <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com>, = fred@cisco.com writes: >> RFC Editor: AUTH48 >> 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption >> 2015-10-26 draft-ietf-v6ops-siit-dc >> 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat >> 2015-10-26 draft-ietf-v6ops-siit-eam >>=20 >> RFC Editor: In ISE Review >> 2016-01-20 draft-ietf-v6ops-mobile-device-profile >>=20 >> IESG: AD Evaluation >> 2016-01-31 draft-bao-v6ops-rfc6145bis >>=20 >> IESG: In Last Call >> 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world >>=20 >> WG: Unupdated WG Document >> 2015-10-19 draft-ietf-v6ops-design-choices >>=20 >> WG: Updated WG Document >> 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host >> 2016-01-03 draft-ietf-v6ops-host-addr-availability >>=20 >> Individual Submission: Unupdated >> 2015-10-19 draft-xu-v6ops-dslite-redundancy >> 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops >> 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack >>=20 >> Individual Submission: Updated >> 2016-01-05 draft-templin-v6ops-pdhost >> 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment >> 2016-01-03 draft-xli-v6ops-cernet-deployment >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89 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 iQIVAwUBVrAnTkayAOS/EQ8MAQL9Ug//e/6aNfv+AC2Iv2qAp6MjcIYyRcqRZLew hhXABkYFTk+/FPHe57xZ4W7h4eEpJ7L8Fha+M+tEzB1ydNc/n/3NsThP6iZCsIYE lemKravU5zMVEvGLeWoaj9YUdKXzlqgIT6TjcE/0wuyUS6a5MotVMXqLKNkwbwg5 IIX1lZNeSWmc7dtWUIeh9/UzgzlGap9Nd0+MhQVoWvPXgNv4Xvq9AhFSOZsz3r1L dtiOGn6cwypfrNleDt7D62jtWpmtyM/R7CjDBVhEhDVXyEiEt5/BfPnfB8e5+Ozt +PvIPw7rPe3Y6tg37kZLTySOiHiJ0UDPCwk7B3KQtYlnfKjFmQ0w8aad+I9Gw7x6 FtUuMZZn5GDzkzR1dpBMr9J2KGjtwO7szDo8C/ZONEfwzTkXwepvxfZoW8eQuTIu E09eFvtUmmpE5w3K9sU/8ku8h+rtNf85GO5rozDwGBlflZAnRHpE61UZZqHAenBm HZIdLBxpZ56RQYzCN+ifrjR4ELTIfI0tUWVJSUWuW34hTpYfLFxWvi+BLLwnDbyC brKIPmBtpks6HKctM/D4YBDiLC0/ZvvsmlWnzCX1ZxdkzZNm0Ah0rSvSP7I/wICA x6tcJPMrUehuA13koaI++2SE7mI87wZb8DygbnxobCgwRwKJz2JgjATFPoV3Asyz whJD47Pn2t8= =0jdz -----END PGP SIGNATURE----- --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89-- From nobody Tue Feb 2 00:39:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744E11A6F0E; Mon, 1 Feb 2016 19:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pigOEC5K4yY5; Mon, 1 Feb 2016 19:55:27 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07E01A6F0B; Mon, 1 Feb 2016 19:55:27 -0800 (PST) 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)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id F04B31FCAD4; Tue, 2 Feb 2016 03:55:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C8F6216004B; Tue, 2 Feb 2016 03:55:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BC38416004A; Tue, 2 Feb 2016 03:55:40 +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 6hMTg9nFbU-l; Tue, 2 Feb 2016 03:55:40 +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 41F54160047; Tue, 2 Feb 2016 03:55:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9932E415A9C9; Tue, 2 Feb 2016 14:55:20 +1100 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> In-reply-to: Your message of "Tue, 02 Feb 2016 03:49:34 -0000." <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> Date: Tue, 02 Feb 2016 14:55:20 +1100 Message-Id: <20160202035520.9932E415A9C9@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org WG" , IPv6 IPv6 List Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 03:55:34 -0000 In message <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com>, "Fred Baker (fred) " writes: > > When you say "v6man", I assume you mean "6man". yep. > I'm a little lost. I don't see the words "chair" or "question" in the = > draft. Could you be more specific about what your question is? Which WG should take ownership of the problem space in this draft? Mark > > On Feb 1, 2016, at 3:11 PM, Mark Andrews wrote: > >=20 > >=20 > > draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed > > at the v6man and v6ops chairs - should this be a v6man or v6ops? It > > needs to be fixed and I don't care in which forum it gets done but it > > needs to be done. > >=20 > > Mark > >=20 > > In message <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com>, = > fred@cisco.com writes: > >> RFC Editor: AUTH48 > >> 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption > >> 2015-10-26 draft-ietf-v6ops-siit-dc > >> 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat > >> 2015-10-26 draft-ietf-v6ops-siit-eam > >>=20 > >> RFC Editor: In ISE Review > >> 2016-01-20 draft-ietf-v6ops-mobile-device-profile > >>=20 > >> IESG: AD Evaluation > >> 2016-01-31 draft-bao-v6ops-rfc6145bis > >>=20 > >> IESG: In Last Call > >> 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world > >>=20 > >> WG: Unupdated WG Document > >> 2015-10-19 draft-ietf-v6ops-design-choices > >>=20 > >> WG: Updated WG Document > >> 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host > >> 2016-01-03 draft-ietf-v6ops-host-addr-availability > >>=20 > >> Individual Submission: Unupdated > >> 2015-10-19 draft-xu-v6ops-dslite-redundancy > >> 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops > >> 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack > >>=20 > >> Individual Submission: Updated > >> 2016-01-05 draft-templin-v6ops-pdhost > >> 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment > >> 2016-01-03 draft-xli-v6ops-cernet-deployment > >>=20 > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89 > 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 > > iQIVAwUBVrAnTkayAOS/EQ8MAQL9Ug//e/6aNfv+AC2Iv2qAp6MjcIYyRcqRZLew > hhXABkYFTk+/FPHe57xZ4W7h4eEpJ7L8Fha+M+tEzB1ydNc/n/3NsThP6iZCsIYE > lemKravU5zMVEvGLeWoaj9YUdKXzlqgIT6TjcE/0wuyUS6a5MotVMXqLKNkwbwg5 > IIX1lZNeSWmc7dtWUIeh9/UzgzlGap9Nd0+MhQVoWvPXgNv4Xvq9AhFSOZsz3r1L > dtiOGn6cwypfrNleDt7D62jtWpmtyM/R7CjDBVhEhDVXyEiEt5/BfPnfB8e5+Ozt > +PvIPw7rPe3Y6tg37kZLTySOiHiJ0UDPCwk7B3KQtYlnfKjFmQ0w8aad+I9Gw7x6 > FtUuMZZn5GDzkzR1dpBMr9J2KGjtwO7szDo8C/ZONEfwzTkXwepvxfZoW8eQuTIu > E09eFvtUmmpE5w3K9sU/8ku8h+rtNf85GO5rozDwGBlflZAnRHpE61UZZqHAenBm > HZIdLBxpZ56RQYzCN+ifrjR4ELTIfI0tUWVJSUWuW34hTpYfLFxWvi+BLLwnDbyC > brKIPmBtpks6HKctM/D4YBDiLC0/ZvvsmlWnzCX1ZxdkzZNm0Ah0rSvSP7I/wICA > x6tcJPMrUehuA13koaI++2SE7mI87wZb8DygbnxobCgwRwKJz2JgjATFPoV3Asyz > whJD47Pn2t8= > =0jdz > -----END PGP SIGNATURE----- > > --Apple-Mail=_99008B0B-2380-47D5-A518-D24FACDEAD89-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 2 00:39:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA21A6F57; Mon, 1 Feb 2016 20:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CishmxmrqkX6; Mon, 1 Feb 2016 20:10:54 -0800 (PST) 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 887371A6F61; Mon, 1 Feb 2016 20:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5327; q=dns/txt; s=iport; t=1454386254; x=1455595854; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rKi1783Vq9rh696lnOH00aZJnCI9RnSiSPkyZ0UkSPI=; b=WutFRvguxOp7MIeNLgjnkm/mbgBTLhYeDKmbArRHpZn5U27sMjtbR/ss 9hkDF2XvRzHolvbXeNSgHv0oZwTKKd6M9+iHBkjTC+VMI8GLNDRsih9Ve +N5VLu6Ie0/+W8D6naDZivpBO6TvXkquhfcqmYqytZDAY7o2EzaQrnSbl Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgB0K7BW/4sNJK1egzpSbQaIU7FfD?= =?us-ascii?q?oFkGAqFbQKBNjgUAQEBAQEBAYEKhEEBAQEDAQEBAWsLBQkCAgEIGC4bDAslAgQ?= =?us-ascii?q?KBAUOiAUIDr14AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQgEh3gIgkKEEwEBW4Jtg?= =?us-ascii?q?Q8FjSWJTAGCeYFjaogEgVtKjEuKbINRAR4BQ4NsagGIOjR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,383,1449532800"; d="asc'?scan'208";a="69151054" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 04:10:53 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u124ArxG011943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 04:10:53 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 22:10:52 -0600 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.1104.009; Mon, 1 Feb 2016 22:10:52 -0600 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] State of play Thread-Index: AQHRXWy7WKRnV1axq0Cue0ZfkN2Y9w== Date: Tue, 2 Feb 2016 04:10:52 +0000 Message-ID: References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> <20160202035520.9932E415A9C9@rock.dv.isc.org> In-Reply-To: <20160202035520.9932E415A9C9@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.81] Content-Type: multipart/signed; boundary="Apple-Mail=_C3A52B19-0A1F-40FC-8A7D-B9FD9111C660"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , IPv6 IPv6 List Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 04:11:03 -0000 --Apple-Mail=_C3A52B19-0A1F-40FC-8A7D-B9FD9111C660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would guess it belongs in 6man, but I'll let the 6man chairs decide = whether they agree. > On Feb 1, 2016, at 7:55 PM, Mark Andrews wrote: >=20 >=20 > In message <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com>, "Fred = Baker (fred) > " writes: >>=20 >> When you say "v6man", I assume you mean "6man". >=20 > yep. >=20 >> I'm a little lost. I don't see the words "chair" or "question" in the = =3D >> draft. Could you be more specific about what your question is? >=20 > Which WG should take ownership of the problem space in this draft? >=20 > Mark >=20 >>> On Feb 1, 2016, at 3:11 PM, Mark Andrews wrote: >>> =3D20 >>> =3D20 >>> draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question = directed >>> at the v6man and v6ops chairs - should this be a v6man or v6ops? It >>> needs to be fixed and I don't care in which forum it gets done but = it >>> needs to be done. >>> =3D20 >>> Mark >>> =3D20 >>> In message <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com>, =3D >> fred@cisco.com writes: >>>> RFC Editor: AUTH48 >>>> 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption >>>> 2015-10-26 draft-ietf-v6ops-siit-dc >>>> 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat >>>> 2015-10-26 draft-ietf-v6ops-siit-eam >>>> =3D20 >>>> RFC Editor: In ISE Review >>>> 2016-01-20 draft-ietf-v6ops-mobile-device-profile >>>> =3D20 >>>> IESG: AD Evaluation >>>> 2016-01-31 draft-bao-v6ops-rfc6145bis >>>> =3D20 >>>> IESG: In Last Call >>>> 2016-01-28 draft-ietf-v6ops-ipv6-ehs-in-real-world >>>> =3D20 >>>> WG: Unupdated WG Document >>>> 2015-10-19 draft-ietf-v6ops-design-choices >>>> =3D20 >>>> WG: Updated WG Document >>>> 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host >>>> 2016-01-03 draft-ietf-v6ops-host-addr-availability >>>> =3D20 >>>> Individual Submission: Unupdated >>>> 2015-10-19 draft-xu-v6ops-dslite-redundancy >>>> 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops >>>> 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack >>>> =3D20 >>>> Individual Submission: Updated >>>> 2016-01-05 draft-templin-v6ops-pdhost >>>> 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment >>>> 2016-01-03 draft-xli-v6ops-cernet-deployment >>>> =3D20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >>=20 >> --Apple-Mail=3D_99008B0B-2380-47D5-A518-D24FACDEAD89 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: attachment; filename=3D"signature.asc" >> Content-Type: application/pgp-signature; name=3D"signature.asc" >> Content-Description: Message signed with OpenPGP using GPGMail >>=20 >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - http://gpgtools.org >>=20 >> iQIVAwUBVrAnTkayAOS/EQ8MAQL9Ug//e/6aNfv+AC2Iv2qAp6MjcIYyRcqRZLew >> hhXABkYFTk+/FPHe57xZ4W7h4eEpJ7L8Fha+M+tEzB1ydNc/n/3NsThP6iZCsIYE >> lemKravU5zMVEvGLeWoaj9YUdKXzlqgIT6TjcE/0wuyUS6a5MotVMXqLKNkwbwg5 >> IIX1lZNeSWmc7dtWUIeh9/UzgzlGap9Nd0+MhQVoWvPXgNv4Xvq9AhFSOZsz3r1L >> dtiOGn6cwypfrNleDt7D62jtWpmtyM/R7CjDBVhEhDVXyEiEt5/BfPnfB8e5+Ozt >> +PvIPw7rPe3Y6tg37kZLTySOiHiJ0UDPCwk7B3KQtYlnfKjFmQ0w8aad+I9Gw7x6 >> FtUuMZZn5GDzkzR1dpBMr9J2KGjtwO7szDo8C/ZONEfwzTkXwepvxfZoW8eQuTIu >> E09eFvtUmmpE5w3K9sU/8ku8h+rtNf85GO5rozDwGBlflZAnRHpE61UZZqHAenBm >> HZIdLBxpZ56RQYzCN+ifrjR4ELTIfI0tUWVJSUWuW34hTpYfLFxWvi+BLLwnDbyC >> brKIPmBtpks6HKctM/D4YBDiLC0/ZvvsmlWnzCX1ZxdkzZNm0Ah0rSvSP7I/wICA >> x6tcJPMrUehuA13koaI++2SE7mI87wZb8DygbnxobCgwRwKJz2JgjATFPoV3Asyz >> whJD47Pn2t8=3D >> =3D0jdz >> -----END PGP SIGNATURE----- >>=20 >> --Apple-Mail=3D_99008B0B-2380-47D5-A518-D24FACDEAD89-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --Apple-Mail=_C3A52B19-0A1F-40FC-8A7D-B9FD9111C660 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 iQIVAwUBVrAsS0ayAOS/EQ8MAQKmUxAAn2dICp04V9RurE2NarL2QdKwWDhGcK0+ q0OoEYxOl1YbLWZzHwuNEBRPL3Xg/HtPMKRYkT5ARheT5d5h9tAInR5ztZ0LYD/9 +xqMlfZBDXYEXAW8HHw+gCtKQCrWN414uUTJc3ITOwO/86nCnSWO4mPE3ZpYs9pB HnY//keYgoMf20v0cMWOo1nhKQY0Tbt73sNCYgz/GFY/ffXABd3KtmrL4w2wJ/Mt XQskls7oGBNrkBc1RLxNpFYKtV1+2x9wwOfefkm1JYCj59FnIsRji2Bz0qrTX0kG cgCpHF5+BO/SZHw76je/u7KSPlv7ZE315Vuye73X+2hZ9wS6AWbxak+OlpytjWj3 IIzmhe+vjAm5QfSjAixtt1jJxpt0sxHxiCoSkSKi0bUMmDIYXbsfG+NcXgW2nMb/ zfXw3tRvJCgq0J9gizPEJQtnK0SGWr3/ag1oZG9fCOkG9aJ2d21JCSeRyINo83Kn lQfuBeOMo3BsTQip6P1JXp7Y4TesACxQjH5mst0e2bVtkIxrNwePZRj0lzfFVXsW s7exSjK0pdnAhVOoaEMfkWaWeIDETbl6KP99ZHVc620TIeBwlTTSIWGb32WK8mha cgiDu9N9FJxhZ40eWtcFmNBGH34bKha+ksElBzqrj1YNZBSB9ZWJQWzbiBK2PwFD ZPJ4x07ybS8= =XrJS -----END PGP SIGNATURE----- --Apple-Mail=_C3A52B19-0A1F-40FC-8A7D-B9FD9111C660-- From nobody Tue Feb 2 00:39:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3011A0027 for ; Mon, 1 Feb 2016 23:56:37 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPBe-Jobz98w for ; Mon, 1 Feb 2016 23:56:35 -0800 (PST) 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 905631A89E9 for ; Mon, 1 Feb 2016 23:56:35 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 26018206A72; Tue, 2 Feb 2016 08:56:31 +0100 (CET) To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B05EF1.7010309@si6networks.com> Date: Tue, 2 Feb 2016 04:46:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:56:38 -0000 On 02/01/2016 06:16 PM, Fred Baker (fred) wrote: > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > > "Hein said he supports using IPv6 addresses once per connection and > limiting the lifespan of an IPv6 address to a single connection. Once > the connection is closed, the IPv6 address would be deallocated." > > Thought for today. Wouldn't it be better to divide the set of > addresses in use by a host into two - those that others may use to > connect to it (and are probably advertised in DNS) and those that it > uses to connect to other hosts? In a scan of this kind, if the > harvested address didn't respond to an incoming connection, the scan > would yield little or no value - even with a port scan five seconds > later. Sounds like temporary addresses (RFC4941) vs stable addresses (RFC7217 or traditional slaac), with the only difference in that a listening socket shouldn't be bound to wildcard, or wildcard should not imply temp addr... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 00:39:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617D1A89E9 for ; Mon, 1 Feb 2016 23:56:41 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8wof2G_LhXE for ; Mon, 1 Feb 2016 23:56:40 -0800 (PST) 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 1E9971A0027 for ; Mon, 1 Feb 2016 23:56:40 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 38C44206A7E; Tue, 2 Feb 2016 08:56:36 +0100 (CET) To: Warren Kumari , "Fred Baker (fred)" , "v6ops@ietf.org" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B05F9A.6080407@si6networks.com> Date: Tue, 2 Feb 2016 04:49:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:56:41 -0000 On 02/01/2016 06:38 PM, Warren Kumari wrote: > > > The bit that I still don't understand --- in an IPv4 world, you > *expect* every machine with an IP address to be scanned, almost > constantly. Why should things be different in v6 -- is the "plan" really > that machines are secure because no-one can guess their IP (security > though obscurity)? Addresses can actually be guessed. See -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 00:39:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827A1A89E9 for ; Mon, 1 Feb 2016 23:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfFeQk1Pz9Fb for ; Mon, 1 Feb 2016 23:56:45 -0800 (PST) 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 B3BDE1A0027 for ; Mon, 1 Feb 2016 23:56:45 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 0B1EB206A72; Tue, 2 Feb 2016 08:56:41 +0100 (CET) To: "Fred Baker (fred)" , joel jaeggli References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B06092.2000302@si6networks.com> Date: Tue, 2 Feb 2016 04:53:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:56:47 -0000 On 02/01/2016 07:09 PM, Fred Baker (fred) wrote: > >> On Feb 1, 2016, at 2:03 PM, joel jaeggli wrote: >> >> On 2/1/16 1:38 PM, Warren Kumari wrote: >>> >>> >>> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) >> > wrote: >>> >>> http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ >>> >>> "Hein said he supports using IPv6 addresses once per connection and >>> limiting the lifespan of an IPv6 address to a single connection. >>> Once the connection is closed, the IPv6 address would be deallocated." >>> >>> Thought for today. Wouldn't it be better to divide the set of >>> addresses in use by a host into two - those that others may use to >>> connect to it (and are probably advertised in DNS) and those that it >>> uses to connect to other hosts? In a scan of this kind, if the >>> harvested address didn't respond to an incoming connection, the scan >>> would yield little or no value - even with a port scan five seconds >>> later. >>> >>> >>> Something similar (one address per connection) was suggested during some >>> of the privacy addressing discussions a number of years ago (and it made >>> me sad). Modern machines make a *large* number of connections / >>> sessions, and this would require doing the neighbor discovery dance for >>> every connection, and the router tracking large amounts of state (a slot >>> per connection, not just per machine). >> >> if on the other hand you delegate a prefix to the machine, you can >> optimize for that case by using it's link-local as the nexthop for the >> entire prefix, it can use as many ip's as it want's and you never do any >> ND for any of them. > > However, that's not the issue the article is point out. It's pointing out that if a harvested address used for an outbound connection can also be used for an inbound connection, there is a security vulnerability. > > Warren suggested making the address go away when it is no longer in use. > > I'm suggesting making the firewall in the host block incoming connections to temporary addresses, which has the same effect without the churn. I agee wth you on the desired outcome, but wonder if this should rather be a policy of the host itself (i.e., temp addrs simply not used for incomming connections.. e.g., wildcard not implying it, or a setsockopt() to override that) rather than a policy enforced at the firewall... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 00:46:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65661AC400; Tue, 2 Feb 2016 00:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS9UX9InjmAw; Tue, 2 Feb 2016 00:46:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A901AC3F9; Tue, 2 Feb 2016 00:46:42 -0800 (PST) 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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id BD3AA34930F; Tue, 2 Feb 2016 08:46:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9826B160043; Tue, 2 Feb 2016 08:46:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 877E016005C; Tue, 2 Feb 2016 08:46:59 +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 HuIuds2IJF44; Tue, 2 Feb 2016 08:46:59 +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 1BB7D160043; Tue, 2 Feb 2016 08:46:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 296134160605; Tue, 2 Feb 2016 19:46:37 +1100 (EST) To: otroan@employees.org From: Mark Andrews References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> <61DE78D0-8B8D-4BD3-B6B4-5275B118D6F5@cisco.com> <20160202035520.9932E415A9C9@rock.dv.isc.org> In-reply-to: Your message of "Tue, 02 Feb 2016 09:36:02 +0100." Date: Tue, 02 Feb 2016 19:46:37 +1100 Message-Id: <20160202084637.296134160605@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org WG" , 6man WG Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:46:44 -0000 In message , otroan@employees.org writes: > > Mark, > > >> When you say "v6man", I assume you mean "6man". > > > > yep. > > > >> I'm a little lost. I don't see the words "chair" or "question" in the = > >> draft. Could you be more specific about what your question is? > > > > Which WG should take ownership of the problem space in this draft? > > is this an implementation bug, specification bug or both? Possibly both as implementers failed to apply the simple logic of if the mtu is limited then the tcp segment size also limited. If limit is applied prior to the MSS negotiation then that too is also limited. It's all a matter of how much hand holding should there be which is a judgement call. Mark > Best regards, > Ole -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 2 01:26:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC31ACD37 for ; Tue, 2 Feb 2016 01:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDY1oaHQl0K4 for ; Tue, 2 Feb 2016 01:25:56 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 F10221ACD36 for ; Tue, 2 Feb 2016 01:25:55 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id n1so92962410vkb.3 for ; Tue, 02 Feb 2016 01:25:55 -0800 (PST) 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:content-type; bh=P99NxSUO0v73qCICMDrwlu+/aZgXZeUalUzEFeyzcNw=; b=0XPIL0MsE/XpJLx9+rnAOllrIpY06dGIM7of6gVgPTvVkV/tGkzZwIfywvj/AHdBpl I9tk8Zp9jpKHoqRwtSa3rINEXfn0BtqyrUupStJEdYfUPoF3AX+I+VKDZmX5oOecZqjE MmHSWoHs+SLKvMFObYoj7jFgl4AyXcfgVA9qMkbcZRGlUGRFKrrA1ak1h231SI/M/3dy fKs+WGlM4mR5YARmMON6xH/ig2GHqSNZ5/irpdKUKFG8b/264i7hjwEoqf/y1wKGa+9T XLaKsoZic489AcyZyCpkxUFCJkbdq4CmhFadyLl1W2CKau9uMoHQfQA0dWjgY2/tkDjz WH0g== 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-type; bh=P99NxSUO0v73qCICMDrwlu+/aZgXZeUalUzEFeyzcNw=; b=DkAkoUqGcC+TGyUtkcCPc/Ik2zII7IrNIkk8sZyv1kXkZhUjeUj0lm1u0/L01cea3Y NrCA5sBROJLrszcY1PXjlq5lWd5GSMqnYuUUtWX6O8o6VbAppiUvTbUVJT+/hdqZK1NQ Q0qQU+iveDaG0fIm1wZJYqGM3rzyuGQj0mBw7d8N+plr/KQyZ3obt7Sl4sN9uCBjk7Pp D6xFXFzcFzU8l/RtCNf/dplneE0TIOwUGwoT7Ng1b5Xz0AsSZf8+2T57lKoPaIw+TZ4C wKyUqQZH/DgTaPpAPBJoCnCg5V9O3i8cA3rJU0oJg9t6Bblr/qeu2Wj7k9p/2keyml6R gX4Q== X-Gm-Message-State: AG10YOT854fES07N0jXP61EU8IHr3XAWu65OsyKsrsyuKGcJhycW8ZI4r1b2nVF7iLlDJ6kXgyJYJL+HamuHNQ== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr19416243vkg.133.1454405155040; Tue, 02 Feb 2016 01:25:55 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 01:25:54 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 01:25:54 -0800 (PST) In-Reply-To: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> Date: Tue, 2 Feb 2016 20:25:54 +1100 Message-ID: From: Mark Smith To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a1143d338a03118052ac6167e Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:25:58 -0000 --001a1143d338a03118052ac6167e Content-Type: text/plain; charset=UTF-8 On 2 Feb 2016 8:16 am, "Fred Baker (fred)" wrote: > > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > > "Hein said he supports using IPv6 addresses once per connection and limiting the lifespan of an IPv6 address to a single connection. Once the connection is closed, the IPv6 address would be deallocated." > I think the unstated but implied concern in this article is that the hosts whose addresses are recorded are completely open and vulnerable to port scans once their address has been discovered. In other words, IPv6 hosts do not have host based firewalls of any type at all - they've been totally relying on obscurity on a large address for all protection. I think that is a false concern. I think the absence of NAT "firewalls" and such easy host mobility will have created a strong incentive for host OS developers to make their hosts Internet "proof" by default (for example Windows has had a host firewall enabled by default since Windows XP service pack 2, released more than a decade ago). There seems to have developed such an absolute faith in network firewalls always being present and working 100% successfully that many people haven't noticed that hosts have developed those capabilities too, and those capabilities are what have been protecting their hosts when they're moved and attached to far less trustworthy networks like cafe, hotel, shopping centre and conference networks. The article doesn't mention anything, and I haven't had a look yet, but what has Shodan actually discovered on the IPv6 hosts it was able to scan? Is there really a problem, and how severe is it? > Thought for today. Wouldn't it be better to divide the set of addresses in use by a host into two - those that others may use to connect to it (and are probably advertised in DNS) and those that it uses to connect to other hosts? In a scan of this kind, if the harvested address didn't respond to an incoming connection, the scan would yield little or no value - even with a port scan five seconds later. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1143d338a03118052ac6167e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 Feb 2016 8:16 am, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
> http://arstechn= ica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by= -shodan-and-other-scanners/
>
> "Hein said he supports using IPv6 addresses once per connection a= nd limiting the lifespan of an IPv6 address to a single connection. Once th= e connection is closed, the IPv6 address would be deallocated."
>

I think the unstated but implied concern in this article is = that the hosts whose addresses are recorded are completely open and vulnera= ble to port scans once their address has been discovered. In other words, I= Pv6 hosts do not have host based firewalls of any type at all - they've= been totally relying on obscurity on a large address for all protection.

I think that is a false concern. I think the absence of NAT = "firewalls" and such easy host mobility will have created a stron= g incentive for host OS developers to make their hosts Internet "proof= " by default (for example Windows has had a host firewall enabled by d= efault since Windows XP service pack 2, released more than a decade ago).

There seems to have developed such an absolute faith in netw= ork firewalls always being present and working 100% successfully that many = people haven't noticed that hosts have developed those capabilities too= , and those capabilities are what have been protecting their hosts when the= y're moved and attached to far less trustworthy networks like cafe, hot= el, shopping centre and conference networks.

The article doesn't mention anything, and I haven't = had a look yet, but what has Shodan actually discovered on the IPv6 hosts i= t was able to scan? Is there really a problem, and how severe is it?

> Thought for today. Wouldn't it be better to divide = the set of addresses in use by a host into two - those that others may use = to connect to it (and are probably advertised in DNS) and those that it use= s to connect to other hosts? In a scan of this kind, if the harvested addre= ss didn't respond to an incoming connection, the scan would yield littl= e or no value - even with a port scan five seconds later.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a1143d338a03118052ac6167e-- From nobody Tue Feb 2 01:26:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C4D1ACD3B for ; Tue, 2 Feb 2016 01:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYZfOd_T48TN for ; Tue, 2 Feb 2016 01:25:58 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 226BC1ACD36 for ; Tue, 2 Feb 2016 01:25:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E97C14016D; Tue, 2 Feb 2016 10:25:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMvlELNtIjXn; Tue, 2 Feb 2016 10:25:54 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E237440012; Tue, 2 Feb 2016 10:25:53 +0100 (CET) Message-ID: <56B07629.6080308@globis.net> Date: Tue, 02 Feb 2016 10:26:01 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> In-Reply-To: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> Content-Type: multipart/alternative; boundary="------------090600050700070609080004" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:26:01 -0000 This is a multi-part message in MIME format. --------------090600050700070609080004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Fred Baker (fred) wrote: > http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ > > "Hein said he supports using IPv6 addresses once per connection and limiting the lifespan of an IPv6 address to a single connection. Once the connection is closed, the IPv6 address would be deallocated." > > Thought for today. Wouldn't it be better to divide the set of addresses in use by a host into two - those that others may use to connect to it (and are probably advertised in DNS) and those that it uses to connect to other hosts? In a scan of this kind, if the harvested address didn't respond to an incoming connection, the scan would yield little or no value - even with a port scan five seconds later. There was a message on the NTP pool list very recently (http://www.pool.ntp.org/en/) saying that Shodan was harvesting addresses from communications with public NTP servers. The NTP servers were being inserted into the public pool (as correctly functioning NTP servers) and the Shodan scans were being initiated from other apparently unrelated addresses. So it looks like they were simply passively monitoring the NTP communications to harvest target addresses for a scanning mill. Obviously a lot of machines use the NTP pool (at boot time). Rotating source addresses on the NTP client could have potential impact on the NTP server, as the server would see "more" clients, and generally the server maintains some state for these. [denial of service attack on peer stats anyone?] Also not so easy to statefully firewall UDP communications, unless you specifically bind the NTP client to a particular address used exclusively for NTP, and have the client application ignore all unexpected inbound messages. So in short, this looks like an application level issue to me. Applications need to only bind to the correct addresses. And clients need to correctly filter inbound (reply) messages. Another approach might be to build a distributed defence. If you could set up honeypot NTP clients that only sent outbound packets to the pool servers using specific 'nonce generated' client-addresses, and then checked if these specific addresses were being scanned some time later, you could identify which NTP servers were being used for address harvesting, and also which addresses were being used as scanners. Then a public DNSBL could potentially be used for configuring firewalls in a similar way to how spammers are blocked for SMTP, or the NTP servers used for harvesting thrown out of the pool. -- regards, RayH --------------090600050700070609080004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Fred Baker (fred) wrote:
http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/

"Hein said he supports using IPv6 addresses once per connection and limiting the lifespan of an IPv6 address to a single connection. Once the connection is closed, the IPv6 address would be deallocated."

Thought for today. Wouldn't it be better to divide the set of addresses in use by a host into two - those that others may use to connect to it (and are probably advertised in DNS) and those that it uses to connect to other hosts? In a scan of this kind, if the harvested address didn't respond to an incoming connection, the scan would yield little or no value - even with a port scan five seconds later.
There was a message on the NTP pool list very recently (http://www.pool.ntp.org/en/) saying that Shodan was harvesting addresses from communications with public NTP servers.

The NTP servers were being inserted into the public pool (as correctly functioning NTP servers) and the Shodan scans were being initiated from other apparently unrelated addresses. So it looks like they were simply passively monitoring the NTP communications to harvest target addresses for a scanning mill. Obviously a lot of machines use the NTP pool (at boot time).

Rotating source addresses on the NTP client could have potential impact on the NTP server, as the server would see "more" clients, and generally the server maintains some state for these. [denial of service attack on peer stats anyone?]

Also not so easy to statefully firewall UDP communications, unless you specifically bind the NTP client to a particular address used exclusively for NTP, and have the client application ignore all unexpected inbound messages.

So in short, this looks like an application level issue to me.
Applications need to only bind to the correct addresses.
And clients need to correctly filter inbound (reply) messages.


Another approach might be to build a distributed defence.

If you could set up honeypot NTP clients that only sent outbound packets to the pool servers using specific 'nonce generated' client-addresses, and then checked if these specific addresses were being scanned some time later, you could identify which NTP servers were being used for address harvesting, and also which addresses were being used as scanners. Then a public DNSBL could potentially be used for configuring firewalls in a similar way to how spammers are blocked for SMTP, or the NTP servers used for harvesting thrown out of the pool.


--
regards,
RayH
--------------090600050700070609080004-- From nobody Tue Feb 2 01:51:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32AF1ACD45 for ; Tue, 2 Feb 2016 01:51:33 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFFPd8CyylUu for ; Tue, 2 Feb 2016 01:51:27 -0800 (PST) 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 C09911ACD25 for ; Tue, 2 Feb 2016 01:51:27 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 C13FD206A81; Tue, 2 Feb 2016 10:51:23 +0100 (CET) To: "Ray Hunter (v6ops)" , "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56B07629.6080308@globis.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B07BF7.3050303@si6networks.com> Date: Tue, 2 Feb 2016 06:50:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B07629.6080308@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:51:33 -0000 On 02/02/2016 06:26 AM, Ray Hunter (v6ops) wrote: > > So in short, this looks like an application level issue to me. > Applications need to only bind to the correct addresses. > And clients need to correctly filter inbound (reply) messages. This is non-trivial. e.g., say you hav configured multiple static addresses (different prefixes)... it's not trivial to find all of them, left alone actually bind() only such subset. that's why at some point we were planning an update to an existing API RFC... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 03:15:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE041ADBFC for ; Tue, 2 Feb 2016 03:15:30 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCr0BcnID3_P for ; Tue, 2 Feb 2016 03:15:29 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1181B2850 for ; Tue, 2 Feb 2016 03:15:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 93631401A9; Tue, 2 Feb 2016 12:15:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjTB4sczQL1B; Tue, 2 Feb 2016 12:15:25 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C39E24016D; Tue, 2 Feb 2016 12:15:25 +0100 (CET) Message-ID: <56B08FD4.5010606@globis.net> Date: Tue, 02 Feb 2016 12:15:32 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Fernando Gont References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56B07629.6080308@globis.net> <56B07BF7.3050303@si6networks.com> In-Reply-To: <56B07BF7.3050303@si6networks.com> Content-Type: multipart/alternative; boundary="------------040605080808040701080708" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 11:15:31 -0000 This is a multi-part message in MIME format. --------------040605080808040701080708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit > Fernando Gont > 2 Feb 2016 10:50 > > This is non-trivial. e.g., say you hav configured multiple static > addresses (different prefixes)... it's not trivial to find all of them, > left alone actually bind() only such subset. > > that's why at some point we were planning an update to an existing API > RFC... > Well it may not be trivial, but I do think it needs attention. As a starting point, bind to wildcard should not bind to temporary addresses, and connect should not send on static addresses. That's really not much more than the existing convention of binding to port <1024 requiring root. Then after that, IMVHO you'll probably be looking more at issues around mapping machine name + service name -> server address + server port e.g. using DNS SD, instead of separate DNS + /etc/services; rather than extensively changing the existing socket API. Then the OS could perform the appropriate binding(s), as well as registering the appropriate name(s), without too much intervention by the application server code. These binding issues are going to pop up on modern highly mobile devices anyway, regardless of the scanning threat. e.g. I don't want my mobile phone offering a bulk photo transfer service on the 4g port, but I'd quite like the voice to failover between 4g and wifi, and the name service really needs updated as I move into wifi radio range of my friend's house. -- regards, RayH --------------040605080808040701080708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

2 Feb 2016 10:50

This is non-trivial. e.g., say you hav configured multiple static
addresses (different prefixes)... it's not trivial to find all of them,
left alone actually bind() only such subset.

that's why at some point we were planning an update to an existing API
RFC...

Well it may not be trivial, but I do think it needs attention.

As a starting point, bind to wildcard should not bind to temporary addresses, and connect should not send on static addresses. That's really not much more than the existing convention of binding to port <1024 requiring root.

Then after that, IMVHO you'll probably be looking more at issues around mapping machine name + service name -> server address + server port e.g. using DNS SD, instead of separate DNS + /etc/services; rather than extensively changing the existing socket API. Then the OS could perform the appropriate binding(s), as well as registering the appropriate name(s), without too much intervention by the application server code.

These binding issues are going to pop up on modern highly mobile devices anyway, regardless of the scanning threat. e.g. I don't want my mobile phone offering a bulk photo transfer service on the 4g port, but I'd quite like the voice to failover between 4g and wifi, and the name service really needs updated as I move into wifi radio range of my friend's house.

--
regards,
RayH
--------------040605080808040701080708-- From nobody Tue Feb 2 03:51:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D25C1B2A25 for ; Tue, 2 Feb 2016 03:51:55 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnLjmBPGcOgk for ; Tue, 2 Feb 2016 03:51:53 -0800 (PST) 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 5FAFB1B2A23 for ; Tue, 2 Feb 2016 03:51:53 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 23E0C206A7B; Tue, 2 Feb 2016 12:51:49 +0100 (CET) To: "Ray Hunter (v6ops)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56B07629.6080308@globis.net> <56B07BF7.3050303@si6networks.com> <56B08FD4.5010606@globis.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B094B3.9060006@si6networks.com> Date: Tue, 2 Feb 2016 08:36:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B08FD4.5010606@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 11:51:55 -0000 On 02/02/2016 08:15 AM, Ray Hunter (v6ops) wrote: > > >> Fernando Gont >> 2 Feb 2016 10:50 >> >> This is non-trivial. e.g., say you hav configured multiple static >> addresses (different prefixes)... it's not trivial to find all of them, >> left alone actually bind() only such subset. >> >> that's why at some point we were planning an update to an existing API >> RFC... >> > Well it may not be trivial, but I do think it needs attention. Agreed. > As a starting point, bind to wildcard should not bind to temporary > addresses, and connect should not send on static addresses. That's > really not much more than the existing convention of binding to port > <1024 requiring root. Agreed > Then after that, IMVHO you'll probably be looking more at issues around > mapping machine name + service name -> server address + server port e.g. > using DNS SD, instead of separate DNS + /etc/services; rather than > extensively changing the existing socket API. I'd that, besides some possible tweaking, the issue is that apps should be using a higher-level api. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 03:54:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0C1B2A24 for ; Tue, 2 Feb 2016 03:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-PiCcv0FAIa for ; Tue, 2 Feb 2016 03:54:26 -0800 (PST) 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 CFBEE1B2A25 for ; Tue, 2 Feb 2016 03:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2568; q=dns/txt; s=iport; t=1454414065; x=1455623665; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Zl2YHRgUN7CtALd0PeUAgVzyoz31w+qHXhk+kwug48E=; b=T9ms4oLM/5Qoab20/W31CMWfYT+077rJLn1PEm45ChL5dVRQL51OS462 WjpkkIRvLVnOkDaZazRpETtdmnya/WlR2K+zU29i9Uz3ElRY6cC6VQkuS y7IV5KAtpjzdvKVJwYx9lS7+c5V664wiSWWe2Y5SE0O8ReQUvmYj9tvgi w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAgD6l7BW/5hdJa1egzqBPwaIU7FqD?= =?us-ascii?q?oFkhg0CgUM4FAEBAQEBAQGBCoRBAQEBAwF5BQsCAQgOCi4yJQIEDgUOiAUIvhs?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQENCId8CIJCh12BDwWWcQGCeYFjiG6OcY4+A?= =?us-ascii?q?R4BQ4NkaogyJBl8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="asc'?scan'208";a="232528131" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 11:54:25 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u12BsPEu008231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 11:54:25 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 05:54:24 -0600 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.1104.009; Tue, 2 Feb 2016 05:54:24 -0600 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPq0lOHFaM0UKosnY0g5wI7g== Date: Tue, 2 Feb 2016 11:54:24 +0000 Message-ID: <07317398-E07E-48D0-B2B0-902DE5DC395A@cisco.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <56B06092.2000302@si6networks.com> In-Reply-To: <56B06092.2000302@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.81] Content-Type: multipart/signed; boundary="Apple-Mail=_4FF722E8-DCDD-4AAE-BC82-CDCC11B016E2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 11:54:27 -0000 --Apple-Mail=_4FF722E8-DCDD-4AAE-BC82-CDCC11B016E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 1, 2016, at 11:53 PM, Fernando Gont = wrote: >=20 >> Warren suggested making the address go away when it is no longer in = use. >>=20 >> I'm suggesting making the firewall in the host block incoming = connections to temporary addresses, which has the same effect without = the churn. >=20 > I agee wth you on the desired outcome, but wonder if this should = rather > be a policy of the host itself (i.e., temp addrs simply not used for > incomming connections.. e.g., wildcard not implying it, or a > setsockopt() to override that) rather than a policy enforced at the > firewall... We're saying the same thing. The host firewall is in the host. I don't know what else to call it; the = thing that looks at packets coming in and decides whether to present = them to an application. A comment was made that if the port is closed (there is no application = currently using the port) the host won't respond. Actually not true; per = spec, it responds "port unreachable". And if the port happens to be = open, it will in fact respond. However, if we were to somehow say that remote hosts are not permitted = to open a session *to* a temporary address, there's no question. --Apple-Mail=_4FF722E8-DCDD-4AAE-BC82-CDCC11B016E2 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 iQIVAwUBVrCY70ayAOS/EQ8MAQLhnQ/9F3xyh4YpVbGhEV4tlqeKFTK7xgyZhiEB 212vANxXGs5kqTtJB2exBfUxJXWf/U9TRajwvYMoXA40YHWBEzRuJsI+yHHY10J1 KVlAfvESW1nq3y3g/5JGYZgJ9GVtof+E4vlj/hLkNxOqZe8vzHiflTqrL3au2pU+ 9HU9xgQRd77a6tfWuRLjh3eTkCjkRWJwr3r4yAMF9F8HSLUyqMir6mhtLgBtcSxF obTUYPI/mxmxfGZzw9Qm8qgPx2YeNwcYtePyUCp9F3cCfQ00ayL+4PVb023WN343 Ubv/8K0MhL8oDIfwmbMj/NLo1XAX04zZ2soPJoGuES9zJK4clRiv6iC+h3VqEfAf W7hjo09xHJy++P9WfP0LfiVMk9JzDKfGveDmRIw7p9e9jliZTS6XlmF5r85xzWR5 ThCbbTtSmuo3aZrlrGUidbzFroj1EWUGbJ8V2dgmD+AMmhKBQNcicjAbodzSREc+ I2qWGAlkift6v5P5fJpAHUHUylh7+awrbhXxfw3KnLVPXgTvNKf75SyhD1SGCwif H9pwRSIV/FUBzK7b3GV0gWV4dRiQT5dG+AGCBW6wEkz4NbiPPxRZqw+L4isDydCr eNIk7tob76KPAHeZbVlWPDaiQgKigyrGgiij0VjBCdNzadEay5o1/+XsSZ0Gk59C IvrkIJ7Dukg= =d6EE -----END PGP SIGNATURE----- --Apple-Mail=_4FF722E8-DCDD-4AAE-BC82-CDCC11B016E2-- From nobody Tue Feb 2 03:56:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D239E1B2A32 for ; Tue, 2 Feb 2016 03:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.501 X-Spam-Level: X-Spam-Status: No, score=-114.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IuDnsPG5brB for ; Tue, 2 Feb 2016 03:56:41 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531771B2A25 for ; Tue, 2 Feb 2016 03:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3828; q=dns/txt; s=iport; t=1454414201; x=1455623801; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d9QDQV/H0GiY92SZ6Teyj5Mv1+dVTUKFH05cGKcGUXQ=; b=VOcU5xqLD372iC1gsCV8CV1TyygTe0eNzP6KJC3ORKqSH6NT1TfWBG0Z +kXueBCv5e6wRmd5TUMDZrzgC7dMU8rIfTzDOWlSJYGQyL4oNSAsphmQz p65fBOqR3OYEwY7Kpdm5sXWkM4Ffahd84C8UMttbgpJyqQd4PJ2iRG39g g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgCjmLBW/5RdJa1egm5MgT8GiFOxa?= =?us-ascii?q?g6BZIYNAoFDOBQBAQEBAQEBgQqEQQEBAQMBeQULAgEIBBQuIRElAgQOBQ6HeAM?= =?us-ascii?q?KCLlfDYQxAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiHfIJKgjeFJoEPBZZxAYJ5g?= =?us-ascii?q?WOGe4FzjnGGfodAAR4BQ4NkaohvfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="asc'?scan'208,217";a="67171127" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 11:56:40 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u12Buegr030272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 11:56:40 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 05:56:39 -0600 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.1104.009; Tue, 2 Feb 2016 05:56:39 -0600 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPq0lOHFaM0UKosnY0g5wI7g== Date: Tue, 2 Feb 2016 11:56:39 +0000 Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.81] Content-Type: multipart/signed; boundary="Apple-Mail=_C10C0DD2-8134-4D05-86D7-E684365FBDC3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 11:56:43 -0000 --Apple-Mail=_C10C0DD2-8134-4D05-86D7-E684365FBDC3 Content-Type: multipart/alternative; boundary="Apple-Mail=_384BAA4F-596E-4E51-B7CB-A96ADE9B7644" --Apple-Mail=_384BAA4F-596E-4E51-B7CB-A96ADE9B7644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 2, 2016, at 1:25 AM, Mark Smith wrote: >=20 > The article doesn't mention anything, and I haven't had a look yet, = but what has Shodan actually discovered on the IPv6 hosts it was able to = scan? Is there really a problem, and how severe is it? As you say, that's not clear. The port scan, however, covers 115 ports = (unspecified). One might guess that there has been some level of = success, or they wouldn't be doing it. --Apple-Mail=_384BAA4F-596E-4E51-B7CB-A96ADE9B7644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 2, 2016, at 1:25 AM, Mark Smith <markzzzsmith@gmail.com> wrote:

The article doesn't mention anything, and I = haven't had a look yet, but what has Shodan actually discovered on the = IPv6 hosts it was able to scan? Is there really a problem, and how = severe is it?

As = you say, that's not clear. The port scan, however, covers 115 ports = (unspecified). One might guess that there has been some level of = success, or they wouldn't be doing it.
= --Apple-Mail=_384BAA4F-596E-4E51-B7CB-A96ADE9B7644-- --Apple-Mail=_C10C0DD2-8134-4D05-86D7-E684365FBDC3 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 iQIVAwUBVrCZdkayAOS/EQ8MAQLTRRAAxGGxzTUGnYiTAhXJsWa0VbOLIJr5LKn8 Yod3f16cZTk7YZxPa0+IHiuq1cPTuEdhuK82F0ghtqcjA81H60l0YJrNegYtcNg8 Xa1egp5EIMztDRLLFqiCcR4zKhlLxET4ASGs84mVQSfaB0vOKJjZXnv91en/vs0G mAn5J0Vl++vwi9ZVpehbR34LCvqBi5onRQHxXT5AXf8Fzqol8iOr0Y9LAg6P5xjW IWIXL/Ti2AKlDM81wIadQ3cKsRgPnfc2rHD/iPuEIIlF2TATnreKH8GmO+UD90L+ N5vM2VPfyR8rISTMHpY9QQBPPCoM4HO+V8ndDZCgMnhYc/DxnHM1fIxpF4vyDhM9 bDB4A6XiwQa3Nwf8iX77Y96L5QyghrdkJtC0OuPsIkhJX0N0enE4Yy8k3GAncL4a kb/qfdbbJkK5z+24rdZ1YMF0qJEcHXeZBJ8FauG4+Js8WW8cgfyzDcJJziWxt7x6 HfRUyQfKPZY06dDMHdZZyWXTPT8FRpXqWhAILjsgvv8+jhM5HxJkZhfyMI677P4R FdXRxborqGH1aFSK2v2pUgiVgnS/Cc8YbCrOJo3FRklQLcoDYub5xW7BFrukieMm fc63WaIpEm/R1DiPAX/6Uogp3OpuL7DrSuBzW4777PmFqrOcijcTjNlsUd1lXxxf QImBcS9O984= =a5xO -----END PGP SIGNATURE----- --Apple-Mail=_C10C0DD2-8134-4D05-86D7-E684365FBDC3-- From nobody Tue Feb 2 04:14:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3481A88B4 for ; Tue, 2 Feb 2016 04:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJcW9YraiHDG for ; Tue, 2 Feb 2016 04:14:27 -0800 (PST) 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 4F9751A88AD for ; Tue, 2 Feb 2016 04:14:27 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 73837206A7B; Tue, 2 Feb 2016 13:14:24 +0100 (CET) To: "Fred Baker (fred)" References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <56B06092.2000302@si6networks.com> <07317398-E07E-48D0-B2B0-902DE5DC395A@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B09D93.90304@si6networks.com> Date: Tue, 2 Feb 2016 09:14:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <07317398-E07E-48D0-B2B0-902DE5DC395A@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 12:14:32 -0000 On 02/02/2016 08:54 AM, Fred Baker (fred) wrote: > >> On Feb 1, 2016, at 11:53 PM, Fernando Gont >> wrote: >> >>> Warren suggested making the address go away when it is no longer >>> in use. >>> >>> I'm suggesting making the firewall in the host block incoming >>> connections to temporary addresses, which has the same effect >>> without the churn. >> >> I agee wth you on the desired outcome, but wonder if this should >> rather be a policy of the host itself (i.e., temp addrs simply not >> used for incomming connections.. e.g., wildcard not implying it, or >> a setsockopt() to override that) rather than a policy enforced at >> the firewall... > > We're saying the same thing. > > The host firewall is in the host. I don't know what else to call it; > the thing that looks at packets coming in and decides whether to > present them to an application. I'm saying that, besides this functionality being implemented in a host-based firewall, the API should provide the means for enabling the "only listen on stable address, only send connection requests from the temp addr".... or maybe even default to this, and allow to override such default with "listen on all interfaces, connect from whataver saddr-selection we should be connecting from". > A comment was made that if the port is closed (there is no > application currently using the port) the host won't respond. > Actually not true; per spec, it responds "port unreachable". And if > the port happens to be open, it will in fact respond. 1) You're right: that's not true. 2) Even if that was the case, the firewall would reduce the attack surface. -- e.g., in the advisory I posted, the firewall would prevent the breach, while the "closed port" wouldn't. > However, if we were to somehow say that remote hosts are not > permitted to open a session *to* a temporary address, there's no > question. Even than, right now that is not really the case. IN that respect, temp addrs are just an addr, as the stable one. (i.e., that what actually happens... not that it *should* happen)... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 05:22:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16271B2AB5 for ; Tue, 2 Feb 2016 05:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ_g6E5h9hbp for ; Tue, 2 Feb 2016 05:22:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 544391B2AB3 for ; Tue, 2 Feb 2016 05:22:21 -0800 (PST) Received: from [IPv6:2620::930:0:c5e:9fd9:ce78:1d5e] ([IPv6:2620:0:930:0:c5e:9fd9:ce78:1d5e]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u12DKHnJ007336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 05:20:17 -0800 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (13D15) In-Reply-To: <56B06129.7090301@si6networks.com> Date: Tue, 2 Feb 2016 05:20:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> To: Fernando Gont X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 05:20:18 -0800 (PST) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:22:27 -0000 > On Feb 1, 2016, at 23:56, Fernando Gont wrote: >=20 >> On 02/01/2016 07:25 PM, Owen DeLong wrote: >> [...] >>=20 >> The thing that strikes me most about this is that a host which has an >> adequate stateful inspection firewall in front of it realy has no more is= sue >> from it=A1=AFs IPv6 address being harvested than it does from its IPv4 >> address being harvested, so I=A1=AFm not seeing how this is news or how i= t really >> represents any sort of inherent vulnerability. >>=20 >> Perhaps someone can enlighten me as to how this is some new security >> issue we should be concerned about, but for now, it appears to me as if >> it is much ado about nothing. >=20 > Maybe in that in IPv4 you typically have a NAT in front of your node, > where in IPv6 you don't necessarily have a fw? >=20 If you're running a host without any sort of filter, that's really not a pro= blem we should be solving at the network level. That's more of an educationa= l problem. Owen From nobody Tue Feb 2 05:31:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DF01A9037 for ; Tue, 2 Feb 2016 05:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPO4rW-f1nMM for ; Tue, 2 Feb 2016 05:31:25 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 82EDA1A902A for ; Tue, 2 Feb 2016 05:31:24 -0800 (PST) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 4633C15EC2C for ; Tue, 2 Feb 2016 14:31:22 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 1F4683858C3 for ; Tue, 2 Feb 2016 14:31:22 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id EB42D8BBB; Tue, 2 Feb 2016 14:31:21 +0100 (CET) Date: Tue, 2 Feb 2016 14:31:21 +0100 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160202133121.GH94027@ernw.de> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:31:28 -0000 Owen, On Tue, Feb 02, 2016 at 05:20:16AM -0800, Owen DeLong wrote: > > > If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem. that's a very interesting statement, taking the end-to-end principle into account, which IPv6 strives to realize/bring back. Further I didn't have the impression so far that the Internet of Things necessarily included filtering. My parents currently furnishing their smart home weren't either. thanks Enno > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Feb 2 06:33:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B781B2B7E for ; Tue, 2 Feb 2016 06:33:45 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_39mK-2uiIO for ; Tue, 2 Feb 2016 06:33:39 -0800 (PST) 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 7B5161AC409 for ; Tue, 2 Feb 2016 06:33:39 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 14160206A7B; Tue, 2 Feb 2016 15:33:35 +0100 (CET) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B0BE2B.5050408@si6networks.com> Date: Tue, 2 Feb 2016 11:33:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 14:33:45 -0000 On 02/02/2016 10:20 AM, Owen DeLong wrote: > >> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >> >>> On 02/01/2016 07:25 PM, Owen DeLong wrote: >>> [...] >>> >>> The thing that strikes me most about this is that a host which has an >>> adequate stateful inspection firewall in front of it realy has no more issue >>> from itĄŻs IPv6 address being harvested than it does from its IPv4 >>> address being harvested, so IĄŻm not seeing how this is news or how it really >>> represents any sort of inherent vulnerability. >>> >>> Perhaps someone can enlighten me as to how this is some new security >>> issue we should be concerned about, but for now, it appears to me as if >>> it is much ado about nothing. >> >> Maybe in that in IPv4 you typically have a NAT in front of your node, >> where in IPv6 you don't necessarily have a fw? >> > > If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem. There's a reason for deploying network-based firewalls: -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 06:36:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5C1A9034 for ; Tue, 2 Feb 2016 06:36:16 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gY8Y5eKZDpz for ; Tue, 2 Feb 2016 06:36:14 -0800 (PST) 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 DDB721A86EF for ; Tue, 2 Feb 2016 06:36:13 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 EAE98206A7B; Tue, 2 Feb 2016 15:36:10 +0100 (CET) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B0BEBA.1050203@si6networks.com> Date: Tue, 2 Feb 2016 11:35:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 14:36:16 -0000 On 02/02/2016 10:20 AM, Owen DeLong wrote: > > >> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >> >>> On 02/01/2016 07:25 PM, Owen DeLong wrote: >>> [...] >>> >>> The thing that strikes me most about this is that a host which has an >>> adequate stateful inspection firewall in front of it realy has no more issue >>> from itĄŻs IPv6 address being harvested than it does from its IPv4 >>> address being harvested, so IĄŻm not seeing how this is news or how it really >>> represents any sort of inherent vulnerability. >>> >>> Perhaps someone can enlighten me as to how this is some new security >>> issue we should be concerned about, but for now, it appears to me as if >>> it is much ado about nothing. >> >> Maybe in that in IPv4 you typically have a NAT in front of your node, >> where in IPv6 you don't necessarily have a fw? >> > > If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem. Besides, in th IoT world, the "host" may be a network-connected lamp with some crappy-and-impopssible-to-upgrade-or-even-adminisiter firmware... ... i.e., you will need the network based firewall. In fact, in many scenarios that's easier to administer, etc. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 07:24:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76821B2C3D for ; Tue, 2 Feb 2016 07:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmyrrw9M7LPH for ; Tue, 2 Feb 2016 07:24:14 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 131601B2C3C for ; Tue, 2 Feb 2016 07:24:13 -0800 (PST) X-SENDER-IP: 10.64.163.156 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.22,385,1449550800"; d="scan'208";a="1004590066" Received: from unknown (HELO exchpapp15.corp.twcable.com) ([10.64.163.156]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 02 Feb 2016 10:22:56 -0500 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp15.corp.twcable.com (10.64.163.156) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 2 Feb 2016 10:24:11 -0500 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1130.005; Tue, 2 Feb 2016 10:24:11 -0500 From: "Howard, Lee" To: Fernando Gont , Owen DeLong Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPkiUQUGq5CECiLP0wylSOSZ8YC0YAgAAG1gCAAAHNgIAABEeAgACfo4CAAFp8AIAAFGSA//+6aYA= Date: Tue, 2 Feb 2016 15:24:11 +0000 Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> In-Reply-To: <56B0BE2B.5050408@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22106.002 x-tm-as-result: No--35.813500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <680575C6DA2F6F42A35520E1A87C13CB@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:24:18 -0000 On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" wrote: >On 02/02/2016 10:20 AM, Owen DeLong wrote: >> >>> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >>> >>> Maybe in that in IPv4 you typically have a NAT in front of your node, >>> where in IPv6 you don't necessarily have a fw? >>> >> >> If you're running a host without any sort of filter, that's really not >>a problem we should be solving at the network level. That's more of an >>educational problem. > >There's a reason for deploying network-based firewalls: > > There is an unaddressed tension here. I think one view is that IPv6 should be deployed without firewalls so all hosts are reachable from arbitrary other hosts on the Internet. I think the other view is that all/most/many hosts should be protected by a stateful firewall. I don=B9t know that we can resolve this tension in v6ops, but I want to mak= e it explicit. Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Tue Feb 2 07:33:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7103C1B2C63; Tue, 2 Feb 2016 07:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyFjnXj_9ZBk; Tue, 2 Feb 2016 07:33:40 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F311D1B2C62; Tue, 2 Feb 2016 07:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2746; q=dns/txt; s=iport; t=1454427220; x=1455636820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ojPjOxx85GbR8NdHGqoEfB9pv4Fp9f3rf1E2xG9AMuY=; b=KG2dr3NUFHxcqlpmb5BFqUzL0NjZYEjpwCcVHo+KCKdrLTziTUFa6e6M LauJHoBgSsz/TBrnSY4HVBQXgRKmbVG6vr5Sv++EL1xlwV+4MpTaSDEqZ 2T28kWn2ZEAktiZOqSvdcuWs1546Zho7oiIvNH7PGGro3ojkxs6yPpYdW g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAgBzy7BW/4oNJK1egzqBPwaIU7FsD?= =?us-ascii?q?oFkhg0CgUU4FAEBAQEBAQGBCoRCAQEEeRACAQgYLjIlAgQOBQ6IDb5oAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBDQiHfIJKh12BDwWWcQGCeYFjiG6BW4dohS6OPgEeA?= =?us-ascii?q?UODZGqIb3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,385,1449532800"; d="asc'?scan'208";a="72204171" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 15:33:39 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u12FXdao025625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 15:33:39 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 09:33:38 -0600 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.1104.009; Tue, 2 Feb 2016 09:33:38 -0600 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [v6ops] State of play Thread-Index: AQHRXc8WWKRnV1axq0Cue0ZfkN2Y9w== Date: Tue, 2 Feb 2016 15:33:38 +0000 Message-ID: References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org> In-Reply-To: <20160201231151.25706414D77A@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.51.158] Content-Type: multipart/signed; boundary="Apple-Mail=_7EC40467-66AA-40E0-82A3-F4EBF66B4D46"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list , IPv6 IPv6 List Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:33:41 -0000 --Apple-Mail=_7EC40467-66AA-40E0-82A3-F4EBF66B4D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2016, at 3:11 PM, Mark Andrews wrote: > draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed > at the v6man and v6ops chairs - should this be a v6man or v6ops? It > needs to be fixed and I don't care in which forum it gets done but it > needs to be done. OK, I have now actually read the draft, rather than looking through it = for what you described as an open question to the chairs embedded in it. I suspect you might actually be looking at intarea. In any event, I disagree with the proposal in the draft, which is that = TCP should look at whether "use min MTU" is set. Yes, if it is set, that = should be observed; I'm not sure why an implementation would offer the = flag without considering it. However, if I understand the question, the = key point is that the Maximum Segment Size offered in the TCP MSS should = be a size that can be sent on the interface in question using the IP = variant selected, and any options or extension headers that need to be = present, not whether a given flag is set in a not-actually-standard API. = If folks are offering an MSS value that can't be supported, they have an = implementation bug, regardless of whether they are checking for the = flag. Can you describe the implementation? Is this Apple, Microsoft, Linux, = FreeBSD, Android, something else? Give us a test for reproducing the = fault? --Apple-Mail=_7EC40467-66AA-40E0-82A3-F4EBF66B4D46 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 iQIVAwUBVrDMUUayAOS/EQ8MAQIBhRAAhWMoZEryg3/o87/3SxFBG4Xkq+R+XcNU KbaiwFbuf7zKaUDo32ubP1ZgXghOvvUEVbuKKN/VoVN4RUF4apZclj7WV0Kq+rXV o9DEHWbp5OojfPJxJyvXV0eXm3aN0nuCEY7gBxw2CUnMKcjhdxTnYsPnuISG8OdI YjwzRWxZF3leI1t8ScX7fHKW2ssEuZ7n/b9btrRmbv+2CYIegyQvbj6wjZi+oUxj XyVrXtTZKpMP1c0mi6PrFdLbinKtxuVn2wmzEihrvHzYj79eV/nbdj93Tu2K9bcn /hELdBeedYzbO74lg/tsf/6gYa8ada8qCeekB98hPH7tt4WRALozYtkE/P+kSpnn FKP42+lDshW9DOUjapnXcVqyFNOP1S7c77TTQyML29HIGofD4yDujkBTgoqoDxm6 jwlw273Cb6EhmqKh+VjiH1W94Ya0Sg7P1pjXo5zXO/chXWiQZD0/8OooaTLW1EFX 0WMZhOFs4QbGn5kydVm8qOy5yjmdhJrh8DoB32oUSvOQYbrkHwxDuehTTmQF+fFc TzLsSTLkuirIWxsDw+X1P6urr4KT9faD8Zd8YqjqkwQ3X/PdTb7xKjcexoZJaNmF UZ6PK8AuB8wnhlGaGrdtoPrvqwP+OnttDguUEu37meHFl5CpftzAmZPc0gR6FYA8 tj0x7VAKKzQ= =Btvy -----END PGP SIGNATURE----- --Apple-Mail=_7EC40467-66AA-40E0-82A3-F4EBF66B4D46-- From nobody Tue Feb 2 07:36:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E43E1B2C72 for ; Tue, 2 Feb 2016 07:36:07 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emzTY7DxnuM8 for ; Tue, 2 Feb 2016 07:36:04 -0800 (PST) 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 5CCCB1B2C62 for ; Tue, 2 Feb 2016 07:36:02 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 7BDCA206A7B; Tue, 2 Feb 2016 16:35:59 +0100 (CET) To: "Howard, Lee" , Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B0CC7E.1000005@si6networks.com> Date: Tue, 2 Feb 2016 12:34:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:36:07 -0000 On 02/02/2016 12:24 PM, Howard, Lee wrote: > > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" > wrote: > >> On 02/02/2016 10:20 AM, Owen DeLong wrote: >>> >>>> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >>>> >>>> Maybe in that in IPv4 you typically have a NAT in front of your node, >>>> where in IPv6 you don't necessarily have a fw? >>>> >>> >>> If you're running a host without any sort of filter, that's really not >>> a problem we should be solving at the network level. That's more of an >>> educational problem. >> >> There's a reason for deploying network-based firewalls: >> >> > > There is an unaddressed tension here. > I think one view is that IPv6 should be deployed without firewalls so all > hosts are reachable from arbitrary other hosts on the Internet. The folk busted by the recent ICMPv6-based freebsd exploit has a good example regarding why you don't want to be reachable by everyone when you don't really need that. "Need to know basis", "principle of least privilege"... i.e., you are not allowed to do and something that you're not really required to do... > I think the other view is that all/most/many hosts should be protected by > a stateful firewall. > > I donšt know that we can resolve this tension in v6ops, but I want to make > it explicit. Folks aiming at end to end connectivity have traditionally assumed that the "host" is some sort of computer (laptop, tablet, etc.) whereas "host" really becomes any crappy device that becomes IPv6-enabled... possibly with sloppy code, unmanaged, and possibly not even possible to upgrade. -- No.. you don't want that stuff eachable from anyone in the Internet. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 2 08:09:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF71B2CDC for ; Tue, 2 Feb 2016 08:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM-USzL0O2_S for ; Tue, 2 Feb 2016 08:09:17 -0800 (PST) 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 131111B2CD8 for ; Tue, 2 Feb 2016 08:09:10 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id l66so124271005wml.0 for ; Tue, 02 Feb 2016 08:09:09 -0800 (PST) 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:content-type; bh=KZxA1IoWhaMAG645gCG/5PKoRyCPz8teaWOgWqv/KnU=; b=tgRz7FyPGHA8yOJwkIjYUi04r6CzkNjfmEhE7KAomneXYnilFkbJxoe7ylcUn7JprO Q7Pqeu0Z7vAkawTnJN4HXgOwcdSpKxvspMDu05zqfKX2qHw+rzRfwJ3yjgclpvzhRSbQ cntYT14aXOhuEJgxLE5ORN7RL34cz/wyWd16KjxO2cU/Sj+uH7vQPiNud1KEKOTx7s/4 VPv+CecpqnhKCehptGdir/0PncwqIR1zeCt9JR4KBiGparitA0PlCZuYoI4CRXYefazw oNmQn7M2KBNa6DCkTKbxG8SlyhTih6VHGO9iD1gz4zXpjJqqwQfOvo4ZDq/2L2NpopvJ 5I9A== 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-type; bh=KZxA1IoWhaMAG645gCG/5PKoRyCPz8teaWOgWqv/KnU=; b=mhoJsQqpHn7z0/sIvw/54mMJg31K8UcNZB8/6/LExBqV0MnIHj3DfbRSrobawOQAvN LEpmkKeyTH8bnc8OLw/uIfaXJskt6EZcOloupxWGi5CDOiHLEI4UiOsBLKdXgyKSxdRL AeIAt1HIQz+fFrb6DQwsBU2p45UO5wvYwNfCaxe3nA+uMievVNmL0eId3/Q2GDIyvY9e sMhVXmlZ3Ijn/VaPis/HvrQrMCGMnnov6a1WCMNvGMUePJTaehb9cMSIFafMPeB9e2GX LwU/bXg20ooC405mZxSGhg1eKY2nOYDl7syq1FKitDi6CUYthaa3BuknGlmLH3VWB5pw otig== X-Gm-Message-State: AG10YOSN1mmhP+WtFKNC6Pmhe8ySRhSUfgFxcvMuVbXntTMbP4Biqjwx/IRdew5hu9jp5a8hTfN24hcHgZoXdQ== MIME-Version: 1.0 X-Received: by 10.194.76.144 with SMTP id k16mr28992796wjw.78.1454429348573; Tue, 02 Feb 2016 08:09:08 -0800 (PST) Received: by 10.194.68.66 with HTTP; Tue, 2 Feb 2016 08:09:08 -0800 (PST) In-Reply-To: <56B0CC7E.1000005@si6networks.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <56B0CC7E.1000005@si6networks.com> Date: Tue, 2 Feb 2016 08:09:08 -0800 Message-ID: From: Ca By To: Fernando Gont Content-Type: multipart/alternative; boundary=047d7bfceebcac3d1d052acbb854 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:09:19 -0000 --047d7bfceebcac3d1d052acbb854 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 2, 2016 at 7:34 AM, Fernando Gont wrote= : > On 02/02/2016 12:24 PM, Howard, Lee wrote: > > > > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" > > wrote: > > > >> On 02/02/2016 10:20 AM, Owen DeLong wrote: > >>> > >>>> On Feb 1, 2016, at 23:56, Fernando Gont > wrote: > >>>> > >>>> Maybe in that in IPv4 you typically have a NAT in front of your node= , > >>>> where in IPv6 you don't necessarily have a fw? > >>>> > >>> > >>> If you're running a host without any sort of filter, that's really no= t > >>> a problem we should be solving at the network level. That's more of a= n > >>> educational problem. > >> > >> There's a reason for deploying network-based firewalls: > >> > >> > > > > There is an unaddressed tension here. > > I think one view is that IPv6 should be deployed without firewalls so a= ll > > hosts are reachable from arbitrary other hosts on the Internet. > > The folk busted by the recent ICMPv6-based freebsd exploit has a good > example regarding why you don't want to be reachable by everyone when > you don't really need that. > > Except for everyone with a FreeBSD based network based firewalls. In my experience, firewalls are a single point of failure that are generally more prone to attacks (state exhaustion, ALG mishandling bugs and associated platform crashes, ...) than anything else. A firewall is a host, so it has all those same host issues you speak of. The biggest sources of network based DDoS today that is crushing the internet daily ....is generally labeled a "home firewall" ...these firewalls seem to expose UDP 1900, Chargen, NTP, and others.... The label says firewall. So, excuse me if i don't think firewalls do what you think they do in the real world. In my experience, they are the vector of the worst attacks and concentrate the risk of a site going off-line into a single box that is more vulnerable (since it is running exotic ALGs, UPNP, PCP ...) than any other box CB > "Need to know basis", "principle of least privilege"... i.e., you are > not allowed to do and something that you're not really required to do... > > > > I think the other view is that all/most/many hosts should be protected = by > > a stateful firewall. > > > > I don=C2=B9t know that we can resolve this tension in v6ops, but I want= to > make > > it explicit. > > Folks aiming at end to end connectivity have traditionally assumed that > the "host" is some sort of computer (laptop, tablet, etc.) whereas > "host" really becomes any crappy device that becomes IPv6-enabled... > possibly with sloppy code, unmanaged, and possibly not even possible to > upgrade. -- No.. you don't want that stuff eachable from anyone in the > Internet. > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7bfceebcac3d1d052acbb854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 7:34 AM, Fernando Gont <fgont@si6networks.c= om> wrote:
On 02/02/2016 12:24 PM, Howard, Lee wrote:
>
> On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont"
> <v6ops-bounces@ietf.org on behalf of fgont@si6networks.= com> wrote:
>
>> On 02/02/2016 10:20 AM, Owen DeLong wrote:
>>>
>>>> On Feb 1, 2016, at 23:56, Fernando Gont <fgont@si6networks.com> wrote:
>>>>
>>>> Maybe in that in IPv4 you typically have a NAT in front of= your node,
>>>> where in IPv6 you don't necessarily have a fw?
>>>>
>>>
>>> If you're running a host without any sort of filter, that&= #39;s really not
>>> a problem we should be solving at the network level. That'= s more of an
>>> educational problem.
>>
>> There's a reason for deploying network-based firewalls:
>> <https://tools.ietf.o= rg/html/draft-gont-opsawg-firewalls-analysis-01>
>>
>
> There is an unaddressed tension here.
> I think one view is that IPv6 should be deployed without firewalls so = all
> hosts are reachable from arbitrary other hosts on the Internet.

The folk busted by the recent ICMPv6-based freebsd exploit has a goo= d
example regarding why you don't want to be reachable by everyone when you don't really need that.


Except for everyone with a FreeBSD bas= ed network based firewalls.

In my experience, fire= walls are a single point of failure that are generally more prone to attack= s (state exhaustion, ALG mishandling bugs and associated platform crashes, = ...) than anything else.=C2=A0 A firewall is a host, so it has all those sa= me host issues you speak of.

The biggest sources o= f network based DDoS today that is crushing the internet daily ....is gener= ally labeled a "home firewall" ...these firewalls seem to expose = UDP 1900, Chargen, NTP, and others.... The label says firewall.
<= br>
So, excuse me if i don't think firewalls do what you thin= k they do in the real world.=C2=A0 In my experience, they are the vector of= the worst attacks and concentrate the risk of a site going off-line into a= single box that is more vulnerable (since it is running exotic ALGs, UPNP,= PCP ...) =C2=A0than any other box

CB
= =C2=A0
"Need to know basis", "principle of least privilege"...= i.e., you are
not allowed to do and something that you're not really required to do..= .


> I think the other view is that all/most/many hosts should be protected= by
> a stateful firewall.
>
> I don=C2=B9t know that we can resolve this tension in v6ops, but I wan= t to make
> it explicit.

Folks aiming at end to end connectivity have traditionally assumed t= hat
the "host" is some sort of computer (laptop, tablet, etc.) wherea= s
"host" really becomes any crappy device that becomes IPv6-enabled= ...
possibly with sloppy code, unmanaged, and possibly not even possible to
upgrade. -- No.. you don't want that stuff eachable from anyone in the<= br> Internet.


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




____________________________= ___________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--047d7bfceebcac3d1d052acbb854-- From nobody Tue Feb 2 08:17:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163D21B2CE0 for ; Tue, 2 Feb 2016 08:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLt3__PWJ_KK for ; Tue, 2 Feb 2016 08:17:34 -0800 (PST) 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 943EA1ABD3F for ; Tue, 2 Feb 2016 08:17:34 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id l66so124645001wml.0 for ; Tue, 02 Feb 2016 08:17:34 -0800 (PST) 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:content-type; bh=J792942H65BjfvlKC/e5r0JpnW3XnkA2Pb3PkfzNVUE=; b=E1DCx8gNiL4+wrerne5hoHvCOP+pFABrGwB65srfQFHqpTvZZz5/IwWPPJRmDoJEe2 k05Wbo8VOm9u1GmKb+WKvStZiWddHKZ8A/WeTBAfKbgJo+AQbO3Ea4aDpguosFcwjMIE 9a2RuRnBJym2gbYuAFAHmUUl9aox52zqAlSdTzv8Qwbxm/zDNXX+uN25cDysrJoJvj1k Tgy8J9JRzBr48dLHRsQK0M/FITGr9lTS9OtEGCQdC3RORTSwv7yJZc/XuaTivGQLjpvn jnuM7CkedkK5yc2MIVvKFC5/TkNbNuY8h2yTVXmFVJOwhRCAYtmCgNdeGYK/RHQrC5hK 5qvQ== 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-type; bh=J792942H65BjfvlKC/e5r0JpnW3XnkA2Pb3PkfzNVUE=; b=RCRS3mHWUyMAI03Pl7OvxuXdiQW2h1CqNwoh8CrOJUSKNA7eF5cSZpQpiDrBPEZZgb mSFSvgpW0J4KJnPvodml/3krW/tWDUtPtyXrNDYGVhhOBIkv/o9cXOj8OLEthmhZSjS7 5vJKV7vtRWlkqiwaQ4fcYoYGVU2NAHK/vDAmx49ZL4RnXgiJ8qNz3x4hTe3vxB1lOH6r O0G8GujYg+7VAdeOH88g5x21fncd8CprK3JOVFeroCkgU6juPOz9g0f1n4KbzEourcBr FLca1dQVYx+gQaQA5cxYvO502zQ4FyVf8K8KyNneh82VC7DLx7A6v78W9GEuNtjKhzBy EUsQ== X-Gm-Message-State: AG10YOScpnVK+0maFtnvoHupU/bwI8/z9bjZln/fh7h3mdORenZ4SMo5+DIu8eRLdQkDiP0EA5Bffhm82zu91A== MIME-Version: 1.0 X-Received: by 10.28.11.73 with SMTP id 70mr18476248wml.40.1454429852934; Tue, 02 Feb 2016 08:17:32 -0800 (PST) Received: by 10.194.68.66 with HTTP; Tue, 2 Feb 2016 08:17:32 -0800 (PST) In-Reply-To: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <56B0CC7E.1000005@si6networks.com> Date: Tue, 2 Feb 2016 08:17:32 -0800 Message-ID: From: Ca By To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11444c24bc29cd052acbd681 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:17:37 -0000 --001a11444c24bc29cd052acbd681 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 2, 2016 at 8:09 AM, Ca By wrote: > > > On Tue, Feb 2, 2016 at 7:34 AM, Fernando Gont > wrote: > >> On 02/02/2016 12:24 PM, Howard, Lee wrote: >> > >> > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" >> > wrote: >> > >> >> On 02/02/2016 10:20 AM, Owen DeLong wrote: >> >>> >> >>>> On Feb 1, 2016, at 23:56, Fernando Gont >> wrote: >> >>>> >> >>>> Maybe in that in IPv4 you typically have a NAT in front of your nod= e, >> >>>> where in IPv6 you don't necessarily have a fw? >> >>>> >> >>> >> >>> If you're running a host without any sort of filter, that's really n= ot >> >>> a problem we should be solving at the network level. That's more of = an >> >>> educational problem. >> >> >> >> There's a reason for deploying network-based firewalls: >> >> >> >> >> > >> > There is an unaddressed tension here. >> > I think one view is that IPv6 should be deployed without firewalls so >> all >> > hosts are reachable from arbitrary other hosts on the Internet. >> >> The folk busted by the recent ICMPv6-based freebsd exploit has a good >> example regarding why you don't want to be reachable by everyone when >> you don't really need that. >> >> > Except for everyone with a FreeBSD based network based firewalls. > > In my experience, firewalls are a single point of failure that are > generally more prone to attacks (state exhaustion, ALG mishandling bugs a= nd > associated platform crashes, ...) than anything else. A firewall is a > host, so it has all those same host issues you speak of. > > The biggest sources of network based DDoS today that is crushing the > internet daily ....is generally labeled a "home firewall" ...these > firewalls seem to expose UDP 1900, Chargen, NTP, and others.... The label > says firewall. > > So, excuse me if i don't think firewalls do what you think they do in the > real world. In my experience, they are the vector of the worst attacks a= nd > concentrate the risk of a site going off-line into a single box that is > more vulnerable (since it is running exotic ALGs, UPNP, PCP ...) than an= y > other box > > CB > Oh, and they also create really nice backdoors into something you call the "trusted area" http://arstechnica.com/security/2016/01/et-tu-fortinet-hard-coded-password-= raises-new-backdoor-eavesdropping-fears/ Fortinet, Juniper, Nearly every home router.... So...tell me... where do you come up with this idea that firewalls help? There is a lot of evidence they make things worse. Firewalls have the following *fundamental* architectural failings 0. Long history of being seriously owned, including recent backdoor issues. 1. They make users feel falsely secure so they make bad assumption about the "secure network" 2. Commonly hit with state exhaustion attacks 3. Architecturally they are generally deployed as a single door to the network, so they are a single point of failure....even more hilarious is when a vendor sells an high-availability pair and the state bug is reflect from the HOT node to the standby node and they both crash 4. They do advanced stateful packet fiddling, which is highly error prone (UPNP, PCP, other ALGs) I have been hit with evey one of the above. CB > > >> "Need to know basis", "principle of least privilege"... i.e., you are >> not allowed to do and something that you're not really required to do... >> >> >> > I think the other view is that all/most/many hosts should be protected >> by >> > a stateful firewall. >> > >> > I don=C2=B9t know that we can resolve this tension in v6ops, but I wan= t to >> make >> > it explicit. >> >> Folks aiming at end to end connectivity have traditionally assumed that >> the "host" is some sort of computer (laptop, tablet, etc.) whereas >> "host" really becomes any crappy device that becomes IPv6-enabled... >> possibly with sloppy code, unmanaged, and possibly not even possible to >> upgrade. -- No.. you don't want that stuff eachable from anyone in the >> Internet. >> >> >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --001a11444c24bc29cd052acbd681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 2, 2016 at 8:09 AM, Ca By <cb.list6@gmail.com> wrote:


On Tue, Feb 2, 2016 at = 7:34 AM, Fernando Gont <fgont@si6networks.com> wrote:
On 02/02/2016 12:24 PM, Howard, Lee wrote:
>
> On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont"
> <v6ops-= bounces@ietf.org on behalf of fgont@si6networks.com> wrote:
>
>> On 02/02/2016 10:20 AM, Owen DeLong wrote:
>>>
>>>> On Feb 1, 2016, at 23:56, Fernando Gont <fgont@si6networks.com> = wrote:
>>>>
>>>> Maybe in that in IPv4 you typically have a NAT in front of= your node,
>>>> where in IPv6 you don't necessarily have a fw?
>>>>
>>>
>>> If you're running a host without any sort of filter, that&= #39;s really not
>>> a problem we should be solving at the network level. That'= s more of an
>>> educational problem.
>>
>> There's a reason for deploying network-based firewalls:
>> <https://tools.ietf.o= rg/html/draft-gont-opsawg-firewalls-analysis-01>
>>
>
> There is an unaddressed tension here.
> I think one view is that IPv6 should be deployed without firewalls so = all
> hosts are reachable from arbitrary other hosts on the Internet.

The folk busted by the recent ICMPv6-based freebsd exploit has a goo= d
example regarding why you don't want to be reachable by everyone when you don't really need that.


Except for everyone with a Free= BSD based network based firewalls.

In my experienc= e, firewalls are a single point of failure that are generally more prone to= attacks (state exhaustion, ALG mishandling bugs and associated platform cr= ashes, ...) than anything else.=C2=A0 A firewall is a host, so it has all t= hose same host issues you speak of.

The biggest so= urces of network based DDoS today that is crushing the internet daily ....i= s generally labeled a "home firewall" ...these firewalls seem to = expose UDP 1900, Chargen, NTP, and others.... The label says firewall.

So, excuse me if i don't think firewalls do what y= ou think they do in the real world.=C2=A0 In my experience, they are the ve= ctor of the worst attacks and concentrate the risk of a site going off-line= into a single box that is more vulnerable (since it is running exotic ALGs= , UPNP, PCP ...) =C2=A0than any other box

CB

Oh, and they also create really nice backdoo= rs into something you call the "trusted area"=C2=A0

Fortinet, Junip= er, Nearly every home router....

So...tell me... w= here do you come up with this idea that firewalls help? =C2=A0
There is a lot of evidence they make things worse.=C2=A0 Firew= alls have the following *fundamental* architectural failings

=
0. Long history of being seriously owned, including recent backd= oor issues.

1. They make users feel falsely secure= so they make bad assumption about the "secure network"

2. Commonly hit with state exhaustion attacks
3.=C2=A0 Architecturally they are generally deployed as a singl= e door to the network, so they are a single point of failure....even more h= ilarious is when a vendor sells an high-availability pair and the state bug= is reflect from the HOT node to the standby node and they both crash
=

4.=C2=A0 They do advanced stateful packet fiddling, whi= ch is highly error prone (UPNP, PCP, other ALGs)

I= have been hit with evey one of the above. =C2=A0

= CB=C2=A0
=
=C2=A0
"Need to know basis", "principle of least privilege"...= i.e., you are
not allowed to do and something that you're not really required to do..= .


> I think the other view is that all/most/many hosts should be protected= by
> a stateful firewall.
>
> I don=C2=B9t know that we can resolve this tension in v6ops, but I wan= t to make
> it explicit.

Folks aiming at end to end connectivity have traditionally assumed t= hat
the "host" is some sort of computer (laptop, tablet, etc.) wherea= s
"host" really becomes any crappy device that becomes IPv6-enabled= ...
possibly with sloppy code, unmanaged, and possibly not even possible to
upgrade. -- No.. you don't want that stuff eachable from anyone in the<= br> Internet.


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




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--001a11444c24bc29cd052acbd681-- From nobody Tue Feb 2 09:45:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB8F1B2DCB for ; Tue, 2 Feb 2016 09:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7XADcX__7MC for ; Tue, 2 Feb 2016 09:45:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3A1B2DB7 for ; Tue, 2 Feb 2016 09:45:41 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u12Hi2V3025666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 09:44:39 -0800 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <56B0BE2B.5050408@si6networks.com> Date: Tue, 2 Feb 2016 09:44:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <10DF2D0B-4E24-432C-9770-FE395066D12C@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 09:44:39 -0800 (PST) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:45:47 -0000 > On Feb 2, 2016, at 06:33 , Fernando Gont = wrote: >=20 > On 02/02/2016 10:20 AM, Owen DeLong wrote: >>=20 >>> On Feb 1, 2016, at 23:56, Fernando Gont = wrote: >>>=20 >>>> On 02/01/2016 07:25 PM, Owen DeLong wrote: >>>> [...] >>>>=20 >>>> The thing that strikes me most about this is that a host which has = an >>>> adequate stateful inspection firewall in front of it realy has no = more issue >>>> from it=A1=AFs IPv6 address being harvested than it does from its = IPv4 >>>> address being harvested, so I=A1=AFm not seeing how this is news or = how it really >>>> represents any sort of inherent vulnerability. >>>>=20 >>>> Perhaps someone can enlighten me as to how this is some new = security >>>> issue we should be concerned about, but for now, it appears to me = as if >>>> it is much ado about nothing. >>>=20 >>> Maybe in that in IPv4 you typically have a NAT in front of your = node, >>> where in IPv6 you don't necessarily have a fw? >>>=20 >>=20 >> If you're running a host without any sort of filter, that's really = not a problem we should be solving at the network level. That's more of = an educational problem. >=20 > There's a reason for deploying network-based firewalls: > A network-based firewall is one form of filter. I=A1=AFm not sure why = you think my statement was antithetical to that. Owen From nobody Tue Feb 2 09:46:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4D1B2DBA for ; Tue, 2 Feb 2016 09:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQUy-jIWJTiS for ; Tue, 2 Feb 2016 09:46:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFCA1B2DB7 for ; Tue, 2 Feb 2016 09:46:14 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u12Hi2V2025666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 09:44:03 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <20160202133121.GH94027@ernw.de> Date: Tue, 2 Feb 2016 09:44:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> To: Enno Rey X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 09:44:03 -0800 (PST) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:46:16 -0000 > On Feb 2, 2016, at 05:31 , Enno Rey wrote: >=20 > Owen, >=20 > On Tue, Feb 02, 2016 at 05:20:16AM -0800, Owen DeLong wrote: >>=20 >>=20 >> If you're running a host without any sort of filter, that's really = not a problem we should be solving at the network level. That's more of = an educational problem. >=20 > that's a very interesting statement, taking the end-to-end principle = into account, which IPv6 strives to realize/bring back. Why? There=E2=80=99s nothing about filters that interferes with the = end-to-end principle. A Stateful inspection firewall that doesn=E2=80=99t mangle the packet = header is perfectly acceptable in an end-to-end world. Whether it=E2=80=99= s a network-level firewall, a host-level firewall, both, etc. > Further I didn't have the impression so far that the Internet of = Things necessarily included filtering. My parents currently furnishing = their smart home weren't either. Again, you are making a lot of assumptions about the meaning of my = statement that are not contained in my actual statement. I hope my = response above clarifies this and allows you a cleaner perspective. Owen From nobody Tue Feb 2 09:47:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7071B2DB7 for ; Tue, 2 Feb 2016 09:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAfooRFP6_Jj for ; Tue, 2 Feb 2016 09:47:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A56E71B29E9 for ; Tue, 2 Feb 2016 09:47:05 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u12Hk3VJ025995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 09:46:04 -0800 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <56B0BEBA.1050203@si6networks.com> Date: Tue, 2 Feb 2016 09:46:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9E55768C-BCDC-475E-BB53-3435FB9359C4@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BEBA.1050203@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 09:46:04 -0800 (PST) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:47:07 -0000 > On Feb 2, 2016, at 06:35 , Fernando Gont = wrote: >=20 > On 02/02/2016 10:20 AM, Owen DeLong wrote: >>=20 >>=20 >>> On Feb 1, 2016, at 23:56, Fernando Gont = wrote: >>>=20 >>>> On 02/01/2016 07:25 PM, Owen DeLong wrote: >>>> [...] >>>>=20 >>>> The thing that strikes me most about this is that a host which has = an >>>> adequate stateful inspection firewall in front of it realy has no = more issue >>>> from it=A1=AFs IPv6 address being harvested than it does from its = IPv4 >>>> address being harvested, so I=A1=AFm not seeing how this is news or = how it really >>>> represents any sort of inherent vulnerability. >>>>=20 >>>> Perhaps someone can enlighten me as to how this is some new = security >>>> issue we should be concerned about, but for now, it appears to me = as if >>>> it is much ado about nothing. >>>=20 >>> Maybe in that in IPv4 you typically have a NAT in front of your = node, >>> where in IPv6 you don't necessarily have a fw? >>>=20 >>=20 >> If you're running a host without any sort of filter, that's really = not a problem we should be solving at the network level. That's more of = an educational problem. >=20 > Besides, in th IoT world, the "host" may be a network-connected lamp > with some crappy-and-impopssible-to-upgrade-or-even-adminisiter = firmware=A1=A6 If your lamp doesn=A1=AFt have a firewall with a packet filter or = stateful inspection in front of it, then you deserve your house blinking = radically at all hours of the day or night=A1=A6 However, I said =A1=B0without any sort of filter=A1=B1. Not =A1=B0without = a host-based filter=A1=B1, so I=A1=AFm still unclear on how this is a = relevant response to what I said. Owen From nobody Tue Feb 2 10:32:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBAD1B2EBC for ; Tue, 2 Feb 2016 10:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6ZBBogIUkRg for ; Tue, 2 Feb 2016 10:32:03 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743881B2ECD for ; Tue, 2 Feb 2016 10:32:03 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u12IVosv016881; Tue, 2 Feb 2016 18:31:50 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u12IVosv016881 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1454437911; bh=s507OKHpBft5DADWqi1W5UO52ns=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=XxxPjg1NaMi9a2Jb8C7vipUjfKYhLdnklMgqFRG+Dzv2+qqhhCGn3Y9I6sAzYBxiD iN9dGbe6L47suIH27YMARqoFI3cbQdKnmTICBRjGEKRwdycKZ9pyG1N2n8yhclVuDx XqgVhkVkAj1Z8pQRYx3N7rX7LQUvPO5/0Iu8Uwvk= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s11IVo2230811112iQ ret-id none; Tue, 02 Feb 2016 18:31:51 +0000 Received: from [192.168.0.10] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u12IVjF0019607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 18:31:46 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Tim Chown In-Reply-To: Date: Tue, 2 Feb 2016 18:31:45 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <7A88E510-8A39-4765-A762-E855B9ACBDFF@ecs.soton.ac.uk> To: Howard Lee X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s11IVo223081111200; tid=s11IVo2230811112iQ; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u12IVosv016881 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:32:05 -0000 > On 2 Feb 2016, at 15:24, Howard, Lee wrote: >=20 >=20 > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" > wrote: >>=20 >> There's a reason for deploying network-based firewalls: >> >>=20 >=20 > There is an unaddressed tension here. > I think one view is that IPv6 should be deployed without firewalls so = all > hosts are reachable from arbitrary other hosts on the Internet. > I think the other view is that all/most/many hosts should be protected = by > a stateful firewall. >=20 > I don=C2=B9t know that we can resolve this tension in v6ops, but I = want to make > it explicit. Well, we=E2=80=99ve seen a few firewall models put forward in v6ops. RFC = 6092 seems to have been generally well received. It may well be the only one that = made it to RFC status? e.g. draft-ietf-v6ops-balanced-ipv6-security-01 stopped = at that=20 version.=20 Tim= From nobody Tue Feb 2 10:45:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73861B2EF9 for ; Tue, 2 Feb 2016 10:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQFPuDjqgVal for ; Tue, 2 Feb 2016 10:45:22 -0800 (PST) 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 E72AA1B2F20 for ; Tue, 2 Feb 2016 10:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1454438721; x=1455648321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tyxpC+HPez2Kwx15QvGMOvlEvUaX8WtRbbpwdiojDZA=; b=DOh4V4BZeCpOv+dLAmHiOpZmWEP77RLlRPKqp5MBnbi7qLAIQbrfS8+e nkQK9ZZzgiq/s7CcXGv3t/y3/HNppjB2pusHK/j7X6TPH685ihSkioOrN 9pbvHKzthd+qTJuKx656TN0CEYH8YJy7dDjTCe+s12rtxJxCW5ri1RFvt A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgB4+LBW/4UNJK1eDoMsgT8GiFOxb?= =?us-ascii?q?Q6BZIYNAoFJOBQBAQEBAQEBgQqEQQEBAQMBI0IUBQsCAQgOCioCAjIlAgQOBQ6?= =?us-ascii?q?IBQiwRo54AQEBAQEBAQEBAQEBAQEBAQEBAQEOCId8gkqEAYMxK4EPBZZxAYJ5g?= =?us-ascii?q?WOIbo5xjj4BHgFDgyk7aohvfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,385,1449532800"; d="asc'?scan'208";a="232332584" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 18:45:21 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u12IjLtj017553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 18:45:21 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 12:45:20 -0600 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.1104.009; Tue, 2 Feb 2016 12:45:20 -0600 From: "Fred Baker (fred)" To: Tim Chown Thread-Topic: [v6ops] Hmm. Interesting article... Thread-Index: AQHRXTXPq0lOHFaM0UKosnY0g5wI7g== Date: Tue, 2 Feb 2016 18:45:20 +0000 Message-ID: <1FE3E9E6-57B8-40E8-AE4D-5CA181F07F88@cisco.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <7A88E510-8A39-4765-A762-E855B9ACBDFF@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.51.158] Content-Type: multipart/signed; boundary="Apple-Mail=_2EFFAA14-29DD-41A5-98A7-8F68F1E979DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:45:27 -0000 --Apple-Mail=_2EFFAA14-29DD-41A5-98A7-8F68F1E979DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 2, 2016, at 10:31 AM, Tim Chown wrote: >=20 >> There is an unaddressed tension here. >> I think one view is that IPv6 should be deployed without firewalls so = all >> hosts are reachable from arbitrary other hosts on the Internet. >> I think the other view is that all/most/many hosts should be = protected by >> a stateful firewall. >>=20 >> I don=C2=B9t know that we can resolve this tension in v6ops, but I = want to make >> it explicit. >=20 > Well, we=E2=80=99ve seen a few firewall models put forward in v6ops. = RFC 6092 seems > to have been generally well received. It may well be the only one that = made it > to RFC status? e.g. draft-ietf-v6ops-balanced-ipv6-security-01 stopped = at that > version. That is explicitly why Fernando and I are trying to have a firewall = discussion in opsawg (draft-gont-opsawg-firewalls-analysis). RFC 6092 is = certainly a common firewall model (modeling a NAT's behavior), but I = would say that the consensus supporting it was "rough". The other = firewall models proposed (draft-ietf-v6ops-balanced-ipv6-security, = draft-vyncke-advanced-ipv6-security) basically pushed towards = firewall-as-a-service, and as such gutted the filter function. I'll refer us to that discussion if we want to go general on firewall = functionality. My question here was essentially about finding a simple rule = *on*the*host* that might obviate a lot of attacks and probing. The = conclusion that I draw is that I can do anything I want as long as I = don't change anything, and yes, my suggestion is a change. I actually do = think there may be value in it, however. --Apple-Mail=_2EFFAA14-29DD-41A5-98A7-8F68F1E979DF 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 iQIVAwUBVrD5PkayAOS/EQ8MAQIfFw/8CNhD8cQEHV8IsUG1ivYnRyHvVvfD0wE6 nhtz/DPzC/VG4L1iDUl+MPSxz6BEl50eWyv+qf7YUbW/d8M6+vsh/7cUB6Uze0YZ 8wbukjl0+sTBV7wcVGMBuTbsFGRBaoTFdtjG+l7Yd4wLr62pJJY1Z3AhIM1Bikon RqjDgjHUaXU7YOSEk/TsWjeGj0wX0v5Zm35TnBgZ52181qEsyvkQgo8quR58HTBE SL5ljn9K0vokS49A2nNXCU6pwS/Zv+DIZhVbsICyPKHsh63pV7jR8N9GXVw+7wkN +1Xd8AXpKbq/JuAzp9WVFVB4NYrw8G59E4hk1SxKr9wPmyJekiZQswrPUL2EEXJT KXyygSpp3uuRzLldbezABANE2eaC4OK86KxKiNAC0yOJ5jtksFBJ251qPFY31/jT M3KawT/zFFQFEGfU3494RNG+80IZ9XU+GPTq04d5jS5Gm2HmAah7zPJoniTOfT8v wdGdbVZPhh6wAws8IeCazwfUMQEbRZXhYvJFMjnr1metxPHgQZ+Yn+m4xE+goUWw JZsm67MrARTpoColEJT29iKX3SVrO8HEtZuMjupJQJxbBBDpjgV8ZgnoY9RDrNFI 3DhtaKHIUHOnl3gFyWX70teVl1NZ91JAHY9Zyv8KrCc/LdvBAWeuNIWhBAmRmQro Aq6xHCt3+CE= =XCe0 -----END PGP SIGNATURE----- --Apple-Mail=_2EFFAA14-29DD-41A5-98A7-8F68F1E979DF-- From nobody Tue Feb 2 11:36:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8A1B2FEB for ; Tue, 2 Feb 2016 11:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4vHWygHfyBk for ; Tue, 2 Feb 2016 11:36:53 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 C33291B2FDA for ; Tue, 2 Feb 2016 11:36:52 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e64so105837593vkg.0 for ; Tue, 02 Feb 2016 11:36:52 -0800 (PST) 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:content-type; bh=luQUrHZGnAlyC84yZfL5D0WsrHC8W30RTva46k8UAe0=; b=QkZTEFg+Uhq2fF/f9VAS1Ko7jmBXBSANaijcSWBe0+LwPg8PVE0rWdaG7b870pCkUh PcD0PuUIaRkYbP9zFS/VFxvC82D0YZ4fC1CzrX7+dEMTIvDACqZWvvJ2OEUi2hQWtM5a DMVk1T9CizsYPHbEbjhjNZ80b5BpWGqraxq7PXDi3GGuT8W6TStzp5qpUT056gp78pBd LCsGkJze8bThlbZthpW6i2zMr/0bAJIF8Df6JHpu+G+4Q90qZf1EJV6Q0wki5kTV691e flBZt3hhLzpYbmpDABSr7ghi0hFMcTYjDRaZ9fM+jNET9O6VAA2eBlW9eq83ICwNFZad DmEw== 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-type; bh=luQUrHZGnAlyC84yZfL5D0WsrHC8W30RTva46k8UAe0=; b=YAH+UMOpMBuz4HHlWxrvK6H5w6GdUfebNs2XXOuuPUtN9zjXsa3rEhnJX8lV6jA39h yh6EvhIRLybTlLktMTLte/2wsZsgwMN0d/MU1bFgywP963poz9I+s2/a+t2ilMctM4ON Yi1NzxrnvA9jgpkoPsn2S/k0aqcCANOoGNX39H0+DcUxJEckxxTfCsRhondyCx4XMrtO rnhTJSLKd+kQHQO0CrtTqqRoMqgEqxBMbRr0Dcg0Djgf7FBe25+H2vBYsdDt7Alv55+J ZZSWNyBWuQSO7mN08yvCucYygSLg5kvnUh6TA04q8lwEeekZqCMidZO4LU2NTP0+vakw Is7Q== X-Gm-Message-State: AG10YOThlQVG9uJ3uLq8kXtJhsxOhelPDMakYA2mqHyoaGXac/U1941EK1OVe30y2f3CEoJPg+fzv2d4cIwBhQ== MIME-Version: 1.0 X-Received: by 10.31.107.194 with SMTP id k63mr19515773vki.27.1454441811869; Tue, 02 Feb 2016 11:36:51 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 11:36:51 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 11:36:51 -0800 (PST) In-Reply-To: <20160202133121.GH94027@ernw.de> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> Date: Wed, 3 Feb 2016 06:36:51 +1100 Message-ID: From: Mark Smith To: Enno Rey Content-Type: multipart/alternative; boundary=001a114786c28b05aa052ace9f6e Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:36:55 -0000 --001a114786c28b05aa052ace9f6e Content-Type: text/plain; charset=UTF-8 On 3 Feb 2016 12:31 AM, "Enno Rey" wrote: > > Owen, > > On Tue, Feb 02, 2016 at 05:20:16AM -0800, Owen DeLong wrote: > > > > > > If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem. > > that's a very interesting statement, taking the end-to-end principle into account, which IPv6 strives to realize/bring back. The end-to-end principle effectively asserts that hosts should be performing their own filtering/security. e2e is saying that hosts shouldn't rely on the network to perform functions the hosts themselves have to most and greatest interest in being performed, which includes protecting against malicious traffic that arrives over the network. The end to end reachability that IPv6 aims to restore is a network property. It doesn't mean that a host must accept and trust all packets that arrive over the network. It doesn't preclude security functions being performed in the network, but it means they shouldn't be a mandatory part of the architecture, shouldn't be assumed to be there and assumed to be consistently equivalent and "perfect" for the individual hosts' and their applications requirements. Hosts have the greatest interest in their own security so they need to make the greatest effort to ensure it is done and done well. > Further I didn't have the impression so far that the Internet of Things necessarily included filtering. My parents currently furnishing their smart home weren't either. > It should, similar to how nobody would build a house without putting locks on the door. Your parents should be able to trust device vendors to buy "Internet proof" devices if the device has even the slightest possibility of being attached to the Internet. The alternative is to have a big sticker on the box that says "must be behind a network firewall", which might get a vendor out of some of their device robustness responsibility, but isn't really looking after their customer well. Regards, Mark. > thanks > > Enno > > > > > > > > > > > > Owen > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114786c28b05aa052ace9f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 Feb 2016 12:31 AM, "Enno Rey" <erey@ernw.de> wrote:
>
> Owen,
>
> On Tue, Feb 02, 2016 at 05:20:16AM -0800, Owen DeLong wrote:
> >
> >
> > If you're running a host without any sort of filter, that'= ;s really not a problem we should be solving at the network level. That'= ;s more of an educational problem.
>
> that's a very interesting statement, taking the end-to-end princip= le into account, which IPv6 strives to realize/bring back.

The end-to-end principle effectively asserts that hosts shou= ld be performing their own filtering/security.

e2e is saying that hosts shouldn't rely on the network t= o perform functions the hosts themselves have to most and greatest interest= in being performed, which includes protecting against malicious traffic th= at arrives over the network.

The end to end reachability that IPv6 aims to restore is a n= etwork property. It doesn't mean that a host must accept and trust all = packets that arrive over the network.

It doesn't preclude security functions being performed i= n the network, but it means they shouldn't be a mandatory part of the a= rchitecture, shouldn't be assumed to be there and assumed to be consist= ently equivalent and "perfect" for the individual hosts' and = their applications requirements.

Hosts have the greatest interest in their own security so th= ey need to make the greatest effort to ensure it is done and done well.

> Further I didn't have the impression so far that th= e Internet of Things necessarily included filtering. My parents currently f= urnishing their smart home weren't either.
>

It should, similar to how nobody would build a house without= putting locks on the door.

Your parents should be able to trust device vendors to buy &= quot;Internet proof" devices if the device has even the slightest poss= ibility of being=C2=A0 attached to the Internet.

The alternative is to have a big sticker on the box that say= s "must be behind a network firewall", which might get a vendor o= ut of some of their device robustness responsibility, but isn't really = looking after their customer well.

Regards,
Mark.

> thanks
>
> Enno
>
>
>
>
>
>
>
>
> >
> > Owen
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> =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=3D= =3D=3D=3D=3D=3D=3D=3D
> Blog: www.insinuator.net || = Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> =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=3D= =3D=3D=3D=3D=3D=3D=3D
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a114786c28b05aa052ace9f6e-- From nobody Tue Feb 2 11:47:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2001B3015 for ; Tue, 2 Feb 2016 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtFfaswC2W6G for ; Tue, 2 Feb 2016 11:47:50 -0800 (PST) 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 415461B3014 for ; Tue, 2 Feb 2016 11:47:49 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e6so105092807vkh.2 for ; Tue, 02 Feb 2016 11:47:49 -0800 (PST) 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:content-type; bh=zCgI/MqmB9d6n26gFuV9GbJR1n4Ry1FuJ9URFnna3rU=; b=o54MGttPwoHxJK9hjKS2reO3txYU6d8jef9OFDHsiNIm+HHnGnA73KN5eyvhPX9Mvg UiGVXtxUdgSmYdH3LFRMBfYAu18q4GhCRHRKiyqbnydEJKd9Z4a/4uXuu9PwOaPY41Xl /QIonHA7QDUSGo7S7eTKXODKjWS8+dprC5cX9uG98gCacTcrFdboWj1kI/wbeX+RnoN8 mlA8c6eF7wvhB0LUnJYzKAS7EINMEfsjucaX8qKIcVRDzSt48ZcskBwSX2xhwM5SsmQz P489AIS8h+YtWlArV5ciXdcyW1Np9kvc3ty7TjkwRQaDm/7lqBjc8aSmopsXnVx7p0Jj HqYA== 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-type; bh=zCgI/MqmB9d6n26gFuV9GbJR1n4Ry1FuJ9URFnna3rU=; b=f4Z83ieJKuPYldTYZVbhS2Y/0JqfOraaE3QqaxYynXZaWpUpRyOLHbeObnX/tgye1u n2IS7hXMgHpD7ivs6cmBh7vmK1ujhu+LE+6+5ItTjY68BZtCr6MWnNDL97uLYl9bjlhk M24pp6W64S9odLTmMbiCtJqMLCG2Io01UTMmiI++WLUOZgRiIF5NSjxuWCHprDVJXKt7 qcQtaAFzYZMZfG59CUUZkSG9MG+xXrPMUretT5WiQtJjGcHXb3s1xUXtjj4mdHQeZjr1 7OJKPIRQkIePxPJCBjXkTp1WPyNxIAkn/JBPvtu88V6zcyDqdjmdpD49AUiqQ6PQRuMy ZlSg== X-Gm-Message-State: AG10YOTwp/Dg5pSM6W4fmp0ZNc+umBV6RYbXHfW/WqHCzgr3I2rx+9sH5lPi+oH8j7vip6vMbmaCM9K4YYWYLg== MIME-Version: 1.0 X-Received: by 10.31.159.136 with SMTP id i130mr21551062vke.144.1454442468398; Tue, 02 Feb 2016 11:47:48 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 11:47:48 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 11:47:48 -0800 (PST) In-Reply-To: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <56B0CC7E.1000005@si6networks.com> Date: Wed, 3 Feb 2016 06:47:48 +1100 Message-ID: From: Mark Smith To: Ca By Content-Type: multipart/alternative; boundary=001a1142ed96acdac6052acec6ea Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:47:52 -0000 --001a1142ed96acdac6052acec6ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 Feb 2016 3:09 AM, "Ca By" wrote: > > > > On Tue, Feb 2, 2016 at 7:34 AM, Fernando Gont wrote: >> >> On 02/02/2016 12:24 PM, Howard, Lee wrote: >> > >> > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont" >> > wrote: >> > >> >> On 02/02/2016 10:20 AM, Owen DeLong wrote: >> >>> >> >>>> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >> >>>> >> >>>> Maybe in that in IPv4 you typically have a NAT in front of your node, >> >>>> where in IPv6 you don't necessarily have a fw? >> >>>> >> >>> >> >>> If you're running a host without any sort of filter, that's really not >> >>> a problem we should be solving at the network level. That's more of an >> >>> educational problem. >> >> >> >> There's a reason for deploying network-based firewalls: >> >> >> >> >> > >> > There is an unaddressed tension here. >> > I think one view is that IPv6 should be deployed without firewalls so all >> > hosts are reachable from arbitrary other hosts on the Internet. >> >> The folk busted by the recent ICMPv6-based freebsd exploit has a good >> example regarding why you don't want to be reachable by everyone when >> you don't really need that. >> > > Except for everyone with a FreeBSD based network based firewalls. > > In my experience, firewalls are a single point of failure that are generally more prone to attacks (state exhaustion, ALG mishandling bugs and associated platform crashes, ...) than anything else. A firewall is a host, so it has all those same host issues you speak of. > > The biggest sources of network based DDoS today that is crushing the internet daily ....is generally labeled a "home firewall" ...these firewalls seem to expose UDP 1900, Chargen, NTP, and others.... The label says firewall. > > So, excuse me if i don't think firewalls do what you think they do in the real world. In my experience, they are the vector of the worst attacks and concentrate the risk of a site going off-line into a single box that is more vulnerable (since it is running exotic ALGs, UPNP, PCP ...) than any other box > Which I think is evidence that host level security is now actually more effective in many cases than CPE/firewall security. The attackers are going after the weakest link. Regards, Mark. > CB > >> >> "Need to know basis", "principle of least privilege"... i.e., you are >> not allowed to do and something that you're not really required to do... >> >> >> > I think the other view is that all/most/many hosts should be protected by >> > a stateful firewall. >> > >> > I don=C2=B9t know that we can resolve this tension in v6ops, but I wan= t to make >> > it explicit. >> >> Folks aiming at end to end connectivity have traditionally assumed that >> the "host" is some sort of computer (laptop, tablet, etc.) whereas >> "host" really becomes any crappy device that becomes IPv6-enabled... >> possibly with sloppy code, unmanaged, and possibly not even possible to >> upgrade. -- No.. you don't want that stuff eachable from anyone in the >> Internet. >> >> >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1142ed96acdac6052acec6ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 Feb 2016 3:09 AM, "Ca By" <cb.list6@gmail.com> wrote:
>
>
>
> On Tue, Feb 2, 2016 at 7:34 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>
>> On 02/02/2016 12:24 PM, Howard, Lee wrote:
>> >
>> > On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont&qu= ot;
>> > <v6ops-bounces@i= etf.org on behalf of fgont@si6= networks.com> wrote:
>> >
>> >> On 02/02/2016 10:20 AM, Owen DeLong wrote:
>> >>>
>> >>>> On Feb 1, 2016, at 23:56, Fernando Gont <fgont@si6networks.com> wrote: >> >>>>
>> >>>> Maybe in that in IPv4 you typically have a NAT in= front of your node,
>> >>>> where in IPv6 you don't necessarily have a fw= ?
>> >>>>
>> >>>
>> >>> If you're running a host without any sort of filt= er, that's really not
>> >>> a problem we should be solving at the network level. = That's more of an
>> >>> educational problem.
>> >>
>> >> There's a reason for deploying network-based firewall= s:
>> >> <https://tools.ietf.org/html/draft-gont-opsawg-fi= rewalls-analysis-01>
>> >>
>> >
>> > There is an unaddressed tension here.
>> > I think one view is that IPv6 should be deployed without fire= walls so all
>> > hosts are reachable from arbitrary other hosts on the Interne= t.
>>
>> The folk busted by the recent ICMPv6-based freebsd exploit has a g= ood
>> example regarding why you don't want to be reachable by everyo= ne when
>> you don't really need that.
>>
>
> Except for everyone with a FreeBSD based network based firewalls.
>
> In my experience, firewalls are a single point of failure that are gen= erally more prone to attacks (state exhaustion, ALG mishandling bugs and as= sociated platform crashes, ...) than anything else.=C2=A0 A firewall is a h= ost, so it has all those same host issues you speak of.
>
> The biggest sources of network based DDoS today that is crushing the i= nternet daily ....is generally labeled a "home firewall" ...these= firewalls seem to expose UDP 1900, Chargen, NTP, and others.... The label = says firewall.
>
> So, excuse me if i don't think firewalls do what you think they do= in the real world.=C2=A0 In my experience, they are the vector of the wors= t attacks and concentrate the risk of a site going off-line into a single b= ox that is more vulnerable (since it is running exotic ALGs, UPNP, PCP ...)= =C2=A0than any other box
>

Which I think is evidence that host level security is now ac= tually more effective in many cases than CPE/firewall security. The attacke= rs are going after the weakest link.

Regards,
Mark.

> CB
> =C2=A0
>>
>> "Need to know basis", "principle of least privilege= "... i.e., you are
>> not allowed to do and something that you're not really require= d to do...
>>
>>
>> > I think the other view is that all/most/many hosts should be = protected by
>> > a stateful firewall.
>> >
>> > I don=C2=B9t know that we can resolve this tension in v6ops, = but I want to make
>> > it explicit.
>>
>> Folks aiming at end to end connectivity have traditionally assumed= that
>> the "host" is some sort of computer (laptop, tablet, etc= .) whereas
>> "host" really becomes any crappy device that becomes IPv= 6-enabled...
>> possibly with sloppy code, unmanaged, and possibly not even possib= le to
>> upgrade. -- No.. you don't want that stuff eachable from anyon= e in the
>> Internet.
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks= .com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a1142ed96acdac6052acec6ea-- From nobody Tue Feb 2 13:13:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDD01B3151 for ; Tue, 2 Feb 2016 13:13:38 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvbtqs4X8QcA for ; Tue, 2 Feb 2016 13:13:35 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (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 B0A181B3150 for ; Tue, 2 Feb 2016 13:13:35 -0800 (PST) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 12C4615EC2C for ; Tue, 2 Feb 2016 22:13:32 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8CAD43B2B95 for ; Tue, 2 Feb 2016 22:13:31 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id 7B59E8E52; Tue, 2 Feb 2016 22:13:31 +0100 (CET) Date: Tue, 2 Feb 2016 22:13:31 +0100 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160202211331.GA95817@ernw.de> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B10835.7070604@alvarezp.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:13:38 -0000 Hi, > On 02/02/2016 09:44 AM, Owen DeLong wrote: > >>> If you're running a host without any sort of filter, that's > >>> really not a problem we should be solving at the network level. > >>> That's more of an educational problem. > >> > >> that's a very interesting statement, taking the end-to-end > >> principle into account, which IPv6 strives to realize/bring back. > > > > Why? There???s nothing about filters that interferes with the > > end-to-end principle. > > > > A Stateful inspection firewall that doesn???t mangle the packet header > > is perfectly acceptable in an end-to-end world. Whether it???s a > > network-level firewall, a host-level firewall, both, etc. a network-level "stateful inspection" firewall keeps track of, well, state. doing so "in the network" is a - from my understanding - fundamental violation of the e2e principle, not least as it impedes "survivability in the face of failure". best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Feb 2 13:35:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE95D1B3220 for ; Tue, 2 Feb 2016 13:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcNJFCYTSDjx for ; Tue, 2 Feb 2016 13:35:57 -0800 (PST) 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 1C6401B2FB3 for ; Tue, 2 Feb 2016 13:35:57 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e185so1153672vkb.1 for ; Tue, 02 Feb 2016 13:35:57 -0800 (PST) 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:content-type; bh=zgrVbxUaFT5lhEMo4A8hKtKSTyLmxorz5MQOgZ8R/QU=; b=QR3N8ISSSzvGUmjj5c4lzVWLB7PBZd8Xmbz1B7SjPKNIAWMc1Jk+i31CF5uJxi9OMh PRLkVFGkb4aHCKG+u3mHK2D/M6HhB1MCTEQf6lgDTFcSXFdp0lVDbcVvu5P0mSTg5uT0 L9Jc++hM8VLcgwa3MPeEKNPJN4Uda7UF8OWGWmK9zmQpb80d8ErOeyk+src6SN90F36y /jek/GihB6p3KjTXS+JiCZyb5b3VXK7DcglyuTjD8nTDLraQJLIYWWitws0BeDWRUCWI 6anYC675khpANOa+fYm5GYHmJ6w/AwFwGhen9Kzea7D1bvEX10XewzGYe4FFVXPd+qhB mirQ== 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-type; bh=zgrVbxUaFT5lhEMo4A8hKtKSTyLmxorz5MQOgZ8R/QU=; b=IPu/hZFvZHezGT9yGuCZ+VaYinEsGTelGUGMUPbq8bmrEbux+27RO43cEJRila3NVr V7fL29QNd7Da8QB1RwJqaiSjdc7Szz5k6davM8wu8YZvpwi/FRtw78m5AEpSrnGSJ42L jgKvevKQJvnw4XN8SECfilolpXaAAfi82eafUbelGd6L3DzaC+7HxVGj/F2H+Bd2p9Jo h6HtnbMqF45NehrIw3KXSjXhVoZewYfg+6i2knW29xk7JoxwLfcBA1IhNVb4KkG59Bmg BWhTjjdx3aJfcuKrt6DlQ38Upx81u7OBrByIpnSvOxMDcEW8/ql9zVRrua/MP5O+Ta7Z 2wDw== X-Gm-Message-State: AG10YORkFODttBbsKOHdAiZlF9d/RazUWDsLpyRkywfvrJ7j6HSMu8b4Lh0aPcKSK/ttXvI5AzGIH1Q38R31EQ== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr21810054vkg.133.1454448956196; Tue, 02 Feb 2016 13:35:56 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 13:35:55 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 13:35:55 -0800 (PST) In-Reply-To: <20160202211331.GA95817@ernw.de> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> Date: Wed, 3 Feb 2016 08:35:55 +1100 Message-ID: From: Mark Smith To: Enno Rey Content-Type: multipart/alternative; boundary=001a1143d33860cdd6052ad049d1 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:35:59 -0000 --001a1143d33860cdd6052ad049d1 Content-Type: text/plain; charset=UTF-8 On 3 Feb 2016 8:13 AM, "Enno Rey" wrote: > > Hi, > > > On 02/02/2016 09:44 AM, Owen DeLong wrote: > > >>> If you're running a host without any sort of filter, that's > > >>> really not a problem we should be solving at the network level. > > >>> That's more of an educational problem. > > >> > > >> that's a very interesting statement, taking the end-to-end > > >> principle into account, which IPv6 strives to realize/bring back. > > > > > > Why? There???s nothing about filters that interferes with the > > > end-to-end principle. > > > > > > A Stateful inspection firewall that doesn???t mangle the packet header > > > is perfectly acceptable in an end-to-end world. Whether it???s a > > > network-level firewall, a host-level firewall, both, etc. > > a network-level "stateful inspection" firewall keeps track of, well, state. doing so "in the network" is a - from my understanding - fundamental violation of the e2e principle, not least as it impedes "survivability in the face of failure". > Right, and forwarding plane state also creates opportunities for attackers to exhaust that state. So if network located packet validation is considered necessary, then I think stateless packet filtering in the network and stateful host firewalling is the more robust model that also satisfies the e2e principle. Regards, Mark. > best > > Enno > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143d33860cdd6052ad049d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 Feb 2016 8:13 AM, "Enno Rey" <erey@ernw.de> wrote:
>
> Hi,
>
> > On 02/02/2016 09:44 AM, Owen DeLong wrote:
> > >>> If you're running a host without any sort of fil= ter, that's
> > >>> really not a problem we should be solving at the net= work level.
> > >>> That's more of an educational problem.
> > >>
> > >> that's a very interesting statement, taking the end-= to-end
> > >> principle into account, which IPv6 strives to realize/br= ing back.
> > >
> > > Why? There???s nothing about filters that interferes with th= e
> > > end-to-end principle.
> > >
> > > A Stateful inspection firewall that doesn???t mangle the pac= ket header
> > > is perfectly acceptable in an end-to-end world. Whether it??= ?s a
> > > network-level firewall, a host-level firewall, both, etc. >
> a network-level "stateful inspection" firewall keeps track o= f, well, state. doing so "in the network" is a - from my understa= nding - fundamental violation of the e2e principle, not least as it impedes= "survivability in the face of failure".
>

Right, and forwarding plane state also creates opportunities= for attackers to exhaust that state.

So if network located packet validation is considered necess= ary, then I think stateless packet filtering in the network and stateful ho= st firewalling is the more robust model that also satisfies the e2e princip= le.

Regards,
Mark.

> best
>
> Enno
>
>
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6= 221 419008 - Cell +49 173 6745902=
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> =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=3D= =3D=3D=3D=3D=3D=3D=3D
> Blog: www.insinuator.net || = Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> =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=3D= =3D=3D=3D=3D=3D=3D=3D
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143d33860cdd6052ad049d1-- From nobody Tue Feb 2 13:50:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03551A0035 for ; Tue, 2 Feb 2016 13:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GYxFEiZScad for ; Tue, 2 Feb 2016 13:50:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FEE1A0033 for ; Tue, 2 Feb 2016 13:50:00 -0800 (PST) Received: from [172.20.7.97] ([65.216.242.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u12LnHLT017950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2016 13:49:18 -0800 (PST) To: Mark Smith , Enno Rey References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> From: Joe Touch Message-ID: <56B12415.3010003@isi.edu> Date: Tue, 2 Feb 2016 13:48:05 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:50:02 -0000 On 2/2/2016 1:35 PM, Mark Smith wrote: >> > > Why? There's nothing about filters that interferes with the >> > > end-to-end principle. I'm not sure how far back that quote goes, but it's correct only if the filters inspect no further than the network (IP) header. The transport header is meaningful only at the endpoints. They can change those headers at will - i.e., change port numbers or transport protocol numbers, etc., subject to agreement of the endpoints. Anything except the endpoints that interprets those headers is a violation of E2E. It may be desired, useful, or even common, but it's not E2E-compliant. Joe From nobody Tue Feb 2 14:16:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694681A00EA for ; Tue, 2 Feb 2016 14:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKFN0YVwkD2R for ; Tue, 2 Feb 2016 14:16:41 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id DFFC51A00E9 for ; Tue, 2 Feb 2016 14:16:40 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u12MEQBb019881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 14:14:27 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <56B12415.3010003@isi.edu> Date: Tue, 2 Feb 2016 14:14:26 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 14:14:27 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:16:42 -0000 > On Feb 2, 2016, at 13:48 , Joe Touch wrote: > > > > On 2/2/2016 1:35 PM, Mark Smith wrote: >>>>> Why? There's nothing about filters that interferes with the >>>>> end-to-end principle. > > I'm not sure how far back that quote goes, but it's correct only if the > filters inspect no further than the network (IP) header. > > The transport header is meaningful only at the endpoints. They can > change those headers at will - i.e., change port numbers or transport > protocol numbers, etc., subject to agreement of the endpoints. > > Anything except the endpoints that interprets those headers is a > violation of E2E. It may be desired, useful, or even common, but it's > not E2E-compliant. We can agree to disagree. It is my NSHO that if you do not alter the packets you allow to pass, your inspection of the higher layer headers in making a security decision is not a violation of e2e. Owen From nobody Tue Feb 2 14:33:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF31A0128 for ; Tue, 2 Feb 2016 14:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW0j8VhBNo1G for ; Tue, 2 Feb 2016 14:33:16 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92F41A0127 for ; Tue, 2 Feb 2016 14:33:15 -0800 (PST) Received: from [172.20.7.97] ([65.216.242.2]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u12MWUFM019008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2016 14:32:41 -0800 (PST) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> From: Joe Touch Message-ID: <56B12E21.7090708@isi.edu> Date: Tue, 2 Feb 2016 14:30:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:33:17 -0000 On 2/2/2016 2:14 PM, Owen DeLong wrote: > >> On Feb 2, 2016, at 13:48 , Joe Touch wrote: >> >> >> >> On 2/2/2016 1:35 PM, Mark Smith wrote: >>>>>> Why? There's nothing about filters that interferes with the >>>>>> end-to-end principle. >> >> I'm not sure how far back that quote goes, but it's correct only if the >> filters inspect no further than the network (IP) header. >> >> The transport header is meaningful only at the endpoints. They can >> change those headers at will - i.e., change port numbers or transport >> protocol numbers, etc., subject to agreement of the endpoints. >> >> Anything except the endpoints that interprets those headers is a >> violation of E2E. It may be desired, useful, or even common, but it's >> not E2E-compliant. > > We can agree to disagree. > > It is my NSHO that if you do not alter the packets you allow to pass, > your inspection of the higher layer headers in making a security decision > is not a violation of e2e. If the net behaves differently in any way based on anything above L3, then that is the violation. That may involve blocking, etc. Further, IMO, any interpretation of info above L3 is a risk - the endpoints are allowed to negotiate those layers, headers, and parameters as they see fit. There is no strict rule that port 53 is DNS - when you block based on port at an intermediate device, that device is *assuming* understanding of that port. That can be (and often is) incorrect. Joe From nobody Tue Feb 2 18:31:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE921B31EA for ; Tue, 2 Feb 2016 18:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYumHyfp-1lm for ; Tue, 2 Feb 2016 18:31:36 -0800 (PST) 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 05D011B31EC for ; Tue, 2 Feb 2016 18:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1725; q=dns/txt; s=iport; t=1454466695; x=1455676295; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UarLieEmm2li/xglPkKg1W0mmDGnflGUia4R0yi/19w=; b=Uk731cv3rV3mGjr/cRYf6PiQkrWN31YCvMAYRyASCtlQ1YWDUeoWkKK0 U8OG55PpZcVaRzjO8DZ3oa0/JxfZyFJVldCMby6I9A4TVLhkO/tUTtlMi ptNuAYV4mbGMxURGUDZU9Ont3PM9UPYl58wONMMMqOVFNFKd78Y3160FZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOBgAOZbFW/4oNJK1egzp+QYhZs12GD?= =?us-ascii?q?QKBQDwQAQEBAQEBAYEKhEIBAQQ6PxALDgoVGVcGE4gbv0oBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEVhg+BbYJKhDBBgmyBDwWOGYhYjUuJIIVRjj83K4QFGy6JawEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.22,387,1449532800"; d="scan'208";a="67642487" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 02:31:35 +0000 Received: from [10.24.44.178] ([10.24.44.178]) (authenticated bits=0) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u132VX5E002685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2016 02:31:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <20160202211331.GA95817@ernw.de> Date: Tue, 2 Feb 2016 18:30:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> To: Enno Rey X-Mailer: Apple Mail (2.3112) X-Authenticated-User: dwing Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 02:31:37 -0000 On 02-Feb-2016 01:13 pm, Enno Rey wrote: >=20 > Hi, >=20 >> On 02/02/2016 09:44 AM, Owen DeLong wrote: >>>>> If you're running a host without any sort of filter, that's >>>>> really not a problem we should be solving at the network level. >>>>> That's more of an educational problem. >>>>=20 >>>> that's a very interesting statement, taking the end-to-end >>>> principle into account, which IPv6 strives to realize/bring back. >>>=20 >>> Why? There???s nothing about filters that interferes with the >>> end-to-end principle. >>>=20 >>> A Stateful inspection firewall that doesn???t mangle the packet = header >>> is perfectly acceptable in an end-to-end world. Whether it???s a >>> network-level firewall, a host-level firewall, both, etc. >=20 > a network-level "stateful inspection" firewall keeps track of, well, = state. doing so "in the network" is a - from my understanding - = fundamental violation of the e2e principle, not least as it impedes = "survivability in the face of failure". The network itself does not have infinite bandwidth (and never will), = and needs protection from denial of service attacks by sending = unsolicited traffic. Even if the host (IoT light bulb) drops the = packet, the network path may well be saturated with those discarded = packets. We have a few small attempts to push that filtering away from = the host into the network (one example is PCP's FILTER option in = RFC6887), but few people see the need. I expect as network connectivity = becomes more necessary for businesses and homes, and attacks continue to = proliferate, the need to filter in the network will remain and will = become more controllable by hosts. -d From nobody Tue Feb 2 21:17:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AC1A1AB6 for ; Tue, 2 Feb 2016 21:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVnbROCfK2bW for ; Tue, 2 Feb 2016 21:17:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 103CD1A1AB3 for ; Tue, 2 Feb 2016 21:17:41 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u135FSrY001371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Feb 2016 21:15:29 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_6CFF559A-4280-4864-A90C-32D4CEBE100A" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <56B12E21.7090708@isi.edu> Date: Tue, 2 Feb 2016 21:15:27 -0800 Message-Id: <2A7F1F30-2345-46D2-BBCE-1CBA44DAB8F9@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> <56B12E21.7090708@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 02 Feb 2016 21:15:30 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 05:17:44 -0000 --Apple-Mail=_6CFF559A-4280-4864-A90C-32D4CEBE100A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 2, 2016, at 14:30 , Joe Touch wrote: >=20 >=20 >=20 > On 2/2/2016 2:14 PM, Owen DeLong wrote: >>=20 >>> On Feb 2, 2016, at 13:48 , Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 2/2/2016 1:35 PM, Mark Smith wrote: >>>>>>> Why? There's nothing about filters that interferes with the >>>>>>> end-to-end principle. >>>=20 >>> I'm not sure how far back that quote goes, but it's correct only if = the >>> filters inspect no further than the network (IP) header. >>>=20 >>> The transport header is meaningful only at the endpoints. They can >>> change those headers at will - i.e., change port numbers or = transport >>> protocol numbers, etc., subject to agreement of the endpoints. >>>=20 >>> Anything except the endpoints that interprets those headers is a >>> violation of E2E. It may be desired, useful, or even common, but = it's >>> not E2E-compliant. >>=20 >> We can agree to disagree. >>=20 >> It is my NSHO that if you do not alter the packets you allow to pass, >> your inspection of the higher layer headers in making a security = decision >> is not a violation of e2e. >=20 > If the net behaves differently in any way based on anything above L3, > then that is the violation. That may involve blocking, etc. >=20 > Further, IMO, any interpretation of info above L3 is a risk - the > endpoints are allowed to negotiate those layers, headers, and = parameters > as they see fit. There is no strict rule that port 53 is DNS - when = you > block based on port at an intermediate device, that device is = *assuming* > understanding of that port. That can be (and often is) incorrect. >=20 > Joe When I decide at the ingress to a collection of machines that I = administer or have responsibility for securing that port 53 is not a port that I = want to allow traffic on, it doesn=92t matter whether the guy at the other = end is thinking it is DNS, Foozball tournament stats, or a message direct to = the pope, it=92s traffic I=92ve decided to administratively deny. Doing so at the network level at the ingress to my network is perfectly = valid and does not, IMNSHO constitute a layering violation or a violation of = e2e. Mutilating the packet and then passing along what remains would, IMNSHO violate e2e because what arrives differs from what was sent in a = meaningful way. Having what was sent never arrive at all due to my security policy = is not a violation. Now, if a transit AS starts making such filtration, I would agree with = you. But a network administrator filtering the ingress to networks = exclusively containing machines for which he/she has responsibility and/or authority is no such violation. In this case, the network is not assuming that it understands the = semantics negotiated by the end points, the network is assuming that the guy who configured the filter understands the policy he intends to implement. Owen --Apple-Mail=_6CFF559A-4280-4864-A90C-32D4CEBE100A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 2, 2016, at 14:30 , Joe Touch <touch@isi.edu> = wrote:



On 2/2/2016 2:14 PM, Owen DeLong = wrote:

On Feb 2, 2016, at 13:48 = , Joe Touch <touch@isi.edu> wrote:



On 2/2/2016 1:35 PM, Mark Smith wrote:
Why? There's nothing about filters that interferes with = the
end-to-end principle.

I'm not sure how far back that quote goes, but it's correct = only if the
filters inspect no further than the network = (IP) header.

The transport header is = meaningful only at the endpoints. They can
change those = headers at will - i.e., change port numbers or transport
protocol numbers, etc., subject to agreement of the = endpoints.

Anything except the endpoints = that interprets those headers is a
violation of E2E. It = may be desired, useful, or even common, but it's
not = E2E-compliant.

We can agree to = disagree.

It is my NSHO that if you do not = alter the packets you allow to pass,
your inspection of = the higher layer headers in making a security decision
is = not a violation of e2e.

If the net behaves = differently in any way based on anything above L3,
then that is the = violation. That may involve blocking, etc.

Further, IMO, any interpretation of info above = L3 is a risk - the
endpoints are allowed to negotiate those layers, = headers, and parameters
as they see fit. There is no strict rule that = port 53 is DNS - when you
block based on port at an intermediate device, = that device is *assuming*
understanding of that port. That can be (and = often is) incorrect.

Joe

When I decide at the ingress to a collection of machines that = I administer
or have responsibility for securing = that port 53 is not a port that I want
to allow = traffic on, it doesn=92t matter whether the guy at the other end = is
thinking it is DNS, Foozball tournament stats, = or a message direct to the pope,
it=92s traffic = I=92ve decided to administratively deny.

Doing so at the network level at the = ingress to my network is perfectly valid
and does = not, IMNSHO constitute a layering violation or a violation of = e2e.

Mutilating = the packet and then passing along what remains would, IMNSHO
violate e2e because what arrives differs from what was sent = in a meaningful
way. Having what was sent never = arrive at all due to my security policy is
not a = violation.

Now, = if a transit AS starts making such filtration, I would agree with = you.

But a = network administrator filtering the ingress to networks = exclusively
containing machines for which he/she = has responsibility and/or authority
is no such = violation.

In = this case, the network is not assuming that it understands the = semantics
negotiated by the end points, the network = is assuming that the guy who
configured the filter = understands the policy he intends to implement.

Owen

= --Apple-Mail=_6CFF559A-4280-4864-A90C-32D4CEBE100A-- From nobody Tue Feb 2 23:25:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D71A1BA3 for ; Tue, 2 Feb 2016 23:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooPIubObj8w4 for ; Tue, 2 Feb 2016 23:25:27 -0800 (PST) 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 B98371A92B7 for ; Tue, 2 Feb 2016 23:25:26 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e64so8200010vkg.0 for ; Tue, 02 Feb 2016 23:25:26 -0800 (PST) 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:content-type; bh=LaGQncx3179VuJC66KGc14oOcQGsCJQfT021cqJFMuA=; b=C6iZm6WZn6fv3ZHp5PRjDXL1+fxMMEcb0MRqJwcw1FCJVUxPvmUGH53brCv9PUBlMm g2IlxATiIBy0FvavuZGsOuaG+tjX3YDfHVtsDcC49rXGrJYfynfUXQc8H2hhfzuF92Bw Ou+vKXLVduXxgSvk2WsCOZ3ONdELRXqd5j0Es4lrJ+K9f95YP42OS+ljCpEiX+hppAu+ G/2bjyaeVsGnSbjh0OozTi0bOlnHPiHHlcu9hg3XVJL1qAtHhsPMERz1hjg8N6b+n2qn Mgpj4ANf0dPnlq8fu6UVPivTGx0oTmS6kQisZhMI0VFTvf1iIM4pnIVAJkNGEncTrDzS Mp3Q== 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-type; bh=LaGQncx3179VuJC66KGc14oOcQGsCJQfT021cqJFMuA=; b=WCu8c7cPmDAeRxhL1B7CKsH4OdPRUqZRvofBSZ0DirbCkZ1/U4lPyAJszBkay4tYIB oIJATnuisfAYLEwHJfjOaB+37A2iaoJ7C3fbl5mrElUNTszvIwy8xvHvAB28ebqk7bmA gRsIfSltIPAMlCT8oJl+HdsgZ20V+VwAXGlTt1eJSHOnrDZIZ1esUcaU1OrTUgqYsjh5 YBzRbjme33+aRSH2A2z7iU9iVWwGH4lmf/udvfsFBgCv3mDzrbH+xzjgIAJcN2fGPyz6 V2haliRNDs/14n5gg7VPYguyNFk4sCkoWUP+aaSpXjZHkLWp1Cys9tQ4GQGGIMYzqL4J JsJA== X-Gm-Message-State: AG10YOQtdYj4tpwBho2jqLbHfMcPO1KE6Zn7xzrKF1J9ns2RfcPMtX0EmQ8oMQSrQFQQU4tMgy9Yy2cHsHvq2w== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr23331874vkg.133.1454484325879; Tue, 02 Feb 2016 23:25:25 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 23:25:25 -0800 (PST) Received: by 10.103.92.67 with HTTP; Tue, 2 Feb 2016 23:25:25 -0800 (PST) In-Reply-To: <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> Date: Wed, 3 Feb 2016 18:25:25 +1100 Message-ID: From: Mark Smith To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a1143d338935807052ad885c5 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 07:25:29 -0000 --001a1143d338935807052ad885c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 Feb 2016 1:31 PM, "=F0=9F=94=93Dan Wing" wrote: > > > On 02-Feb-2016 01:13 pm, Enno Rey wrote: > > > > Hi, > > > >> On 02/02/2016 09:44 AM, Owen DeLong wrote: > >>>>> If you're running a host without any sort of filter, that's > >>>>> really not a problem we should be solving at the network level. > >>>>> That's more of an educational problem. > >>>> > >>>> that's a very interesting statement, taking the end-to-end > >>>> principle into account, which IPv6 strives to realize/bring back. > >>> > >>> Why? There???s nothing about filters that interferes with the > >>> end-to-end principle. > >>> > >>> A Stateful inspection firewall that doesn???t mangle the packet heade= r > >>> is perfectly acceptable in an end-to-end world. Whether it???s a > >>> network-level firewall, a host-level firewall, both, etc. > > > > a network-level "stateful inspection" firewall keeps track of, well, state. doing so "in the network" is a - from my understanding - fundamental violation of the e2e principle, not least as it impedes "survivability in the face of failure". > > The network itself does not have infinite bandwidth (and never will), and needs protection from denial of service attacks by sending unsolicited traffic. Even if the host (IoT light bulb) drops the packet, the network path may well be saturated with those discarded packets. We have a few small attempts to push that filtering away from the host into the network (one example is PCP's FILTER option in RFC6887), but few people see the need. I expect as network connectivity becomes more necessary for businesses and homes, and attacks continue to proliferate, the need to filter in the network will remain and will become more controllable by hosts. > So I don't think it is really necessary, and I think it is actually useful that the network doesn't try to understand specific host/end protocols to perform anti-DoS mitigation. I think DoS mitigation could be more effectively and more generically achieved by network devices just performing bit pattern matching on packets, which matches what is basically happening in the TCAMs. An external tool of some sort would convert protocol fields it understands into bit pattern specifications before they're pushed into the network device performing the inspection. That would be stateless, while providing a lot of upper layer inspection flexibility. Regards, Mark. > -d > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143d338935807052ad885c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 Feb 2016 1:31 PM, "=F0=9F=94=93Dan Wing" <dwing@cisco.com> wrote:
>
>
> On 02-Feb-2016 01:13 pm, Enno Rey <= erey@ernw.de> wrote:
> >
> > Hi,
> >
> >> On 02/02/2016 09:44 AM, Owen DeLong wrote:
> >>>>> If you're running a host without any sort of = filter, that's
> >>>>> really not a problem we should be solving at the = network level.
> >>>>> That's more of an educational problem.
> >>>>
> >>>> that's a very interesting statement, taking the e= nd-to-end
> >>>> principle into account, which IPv6 strives to realize= /bring back.
> >>>
> >>> Why? There???s nothing about filters that interferes with= the
> >>> end-to-end principle.
> >>>
> >>> A Stateful inspection firewall that doesn???t mangle the = packet header
> >>> is perfectly acceptable in an end-to-end world. Whether i= t???s a
> >>> network-level firewall, a host-level firewall, both, etc.=
> >
> > a network-level "stateful inspection" firewall keeps tr= ack of, well, state. doing so "in the network" is a - from my und= erstanding - fundamental violation of the e2e principle, not least as it im= pedes "survivability in the face of failure".
>
> The network itself does not have infinite bandwidth (and never will), = and needs protection from denial of service attacks by sending unsolicited = traffic.=C2=A0 Even if the host (IoT light bulb) drops the packet, the netw= ork path may well be saturated with those discarded packets.=C2=A0 We have = a few small attempts to push that filtering away from the host into the net= work (one example is PCP's FILTER option in RFC6887), but few people se= e the need.=C2=A0 I expect as network connectivity becomes more necessary f= or businesses and homes, and attacks continue to proliferate, the need to f= ilter in the network will remain and will become more controllable by hosts= .
>

So I don't think it is really necessary, and I think it = is actually useful that the network doesn't try to understand specific = host/end protocols to perform anti-DoS mitigation.

I think DoS mitigation could be more effectively and more ge= nerically achieved by network devices just performing bit pattern matching = on packets, which matches what is basically happening in the TCAMs. An exte= rnal tool of some sort would convert protocol fields it understands into bi= t pattern specifications before they're pushed into the network device = performing the inspection. That would be stateless, while providing a lot o= f upper layer inspection flexibility.

Regards,
Mark.



> -d
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143d338935807052ad885c5-- From nobody Wed Feb 3 06:07:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BBB1ACCDC for ; Wed, 3 Feb 2016 06:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOV_omyZr_If for ; Wed, 3 Feb 2016 06:07:50 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA781ACC81 for ; Wed, 3 Feb 2016 06:07:50 -0800 (PST) Received: from [172.20.7.97] ([65.216.242.2]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u13E5twI013558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Feb 2016 06:06:06 -0800 (PST) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> <56B12E21.7090708@isi.edu> <2A7F1F30-2345-46D2-BBCE-1CBA44DAB8F9@delong.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56B208E9.40303@isi.edu> Date: Wed, 3 Feb 2016 06:04:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <2A7F1F30-2345-46D2-BBCE-1CBA44DAB8F9@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 14:07:52 -0000 On 2/2/2016 9:15 PM, Owen DeLong wrote: ... > When I decide at the ingress to a collection of machines that I administer > or have responsibility for securing that port 53 is not a port that I want > to allow traffic on, it doesn’t matter whether the guy at the other end is > thinking it is DNS, Foozball tournament stats, or a message direct to > the pope, > it’s traffic I’ve decided to administratively deny. The "end" of E2E is often ambiguous. >From a protocol viewpoint, it is the host to whom the IP address is assigned, never anything else. Administratively, if you think it is your right to act on behalf of that endpoint *AND* that endpoint agrees to delegate that right, then you are really just semantically redefining "endpoint" to mean "the entire endsystem under your adminstrative control". However, that will work ONLY when the E2E protocol *ALSO* is coordinated. I.e., you can block port 53 all day long and I can continue to run DNS on another port, or run anything on port 53 inside a tunnel (e.g., encrypted or just with enough layers that you don't inspect). I.e., whether this is valid is NOT solely your decision, regardless of what you *think* your authority is. The endsystem with the given IP address still has to cooperate with you or your solution will not have the desired effect. That delegation can happen anywhere in the net, but it's not so much a violation of the E2E argument as a redefinition that the endpoint is spread out. It doesn't matter whether you are "mutilating" a packet or discarding it, delaying it, or treating it in any way different from packets you don't deep inspect. In any case, any differential treatment is a violation of E2E. I do appreciate that we violate E2E all the time for a variety of practical reasons, but the result always has the potential consequence of unintentionally interfering with valid E2E communication. ... > In this case, the network is not assuming that it understands the semantics > negotiated by the end points, the network is assuming that the guy who > configured the filter understands the policy he intends to implement. It is the person who configures the filter who ASSUMES they can know the consequence of a L4 or higher filter. It is an ASSUMPTION. No amount of "understanding" can overcome the fact that L4 and higher semantics are knowable ONLY at the endpoints. Joe From nobody Wed Feb 3 08:37:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D961B29E2 for ; Wed, 3 Feb 2016 08:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiRoXLBmbjOv for ; Wed, 3 Feb 2016 08:37:22 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 282931B29E1 for ; Wed, 3 Feb 2016 08:37:22 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id mw1so39354559igb.1 for ; Wed, 03 Feb 2016 08:37:22 -0800 (PST) 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-type; bh=5/vEQxL7uAUxNmI75/GqGPbiGL1Oh/BiInxJ7CMtN3M=; b=hded22SeSNap9so6xk8sJuby6pMM4HLxre3KbAKOi0OF9v4vyOtHh3psU+9fX9SbRz VtjT8DD864sL3ZR2qAsbQYfumlChDoZ+L8eT2teuqlW/4ynsPUFk1LztjMUYr9LHUjra AdtvTqREm4767JL5tL33vGPic7T+mlv12P/FdmR6ulAI95cKsXFfNkCP0X9XPVi0Juu3 E3sVPyNyzlbCltc8MxZY+4Xji92stDaqtRNc4UJEdhfwgLn2DXPSpjG1l3FZbZgD0VoV CfMlqYWuvzEj+wc3+l0XiixUWEaf85IAK/D+H0Vtt7B7/+ChPBrVMJo/GfNq9OYoUD2Y ZfaA== 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-type; bh=5/vEQxL7uAUxNmI75/GqGPbiGL1Oh/BiInxJ7CMtN3M=; b=RI6Vvi7HoAn1yKSZ/E/DwAgTu14XqRqIkZVSSOwVPYFPzbDNc8IinUeKguZidLFqMC PSxhpbtfTZtFQiecFhgFZGrHSTSKekl2feptDtrFAHLXyX3ZvtF0EhOouhdtmlZ/uFRY VMZ0TZM/IdrpipWwAmbDD2xeivHw3yLUKdwurj9wVOFGYo9HaZ6uj/4YSnTTTZW+2oR7 3wUgHsiLdLIXp6QVotRQh+ADfioYNPYybO7xMrfKAImn1IfHJlLENZDoezo+pEoJEzMb 9ZgzK2PMraLawDCZKgHWavoTlXZNz0/+IjRzjwtr67bvN3k9P3re6j77tjiPI1IQ1Gum UkBw== X-Gm-Message-State: AG10YOSgjVHd00/6+Ih8sZKbCjLXVyNLiIL5PjbaE3CcpR5KGPk+oBoPO8gzIHr6S5s3oc1D98GdhV89ikhwLw== MIME-Version: 1.0 X-Received: by 10.50.29.5 with SMTP id f5mr4637944igh.65.1454517441566; Wed, 03 Feb 2016 08:37:21 -0800 (PST) Received: by 10.107.160.203 with HTTP; Wed, 3 Feb 2016 08:37:21 -0800 (PST) In-Reply-To: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> Date: Wed, 3 Feb 2016 08:37:21 -0800 Message-ID: From: Tom Herbert To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:37:23 -0000 On Tue, Feb 2, 2016 at 2:14 PM, Owen DeLong wrote: > >> On Feb 2, 2016, at 13:48 , Joe Touch wrote: >> >> >> >> On 2/2/2016 1:35 PM, Mark Smith wrote: >>>>>> Why? There's nothing about filters that interferes with the >>>>>> end-to-end principle. >> >> I'm not sure how far back that quote goes, but it's correct only if the >> filters inspect no further than the network (IP) header. >> >> The transport header is meaningful only at the endpoints. They can >> change those headers at will - i.e., change port numbers or transport >> protocol numbers, etc., subject to agreement of the endpoints. >> >> Anything except the endpoints that interprets those headers is a >> violation of E2E. It may be desired, useful, or even common, but it's >> not E2E-compliant. > > We can agree to disagree. > > It is my NSHO that if you do not alter the packets you allow to pass, > your inspection of the higher layer headers in making a security decision > is not a violation of e2e. > What about the case where packets are dropped by an intermediate device because it doesn't understand some legitimate L4 protocol or isn't able to find the L4 header because it doesn't parse all the ext. hdrs. This sort of thing is a major culprit of protocol ossification on the Internet. Because of this it's infeasible for us (end users) to deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with TCP forever, it seem like the only recourse we currently have is encapsulating "alternative" L4 protocols in UDP, but that leads to it's own problems. Tom > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 3 09:19:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9E41B3525 for ; Wed, 3 Feb 2016 09:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhdJTXkkdx2H for ; Wed, 3 Feb 2016 09:19:02 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 2E3701B3523 for ; Wed, 3 Feb 2016 09:19:01 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l66so80751911wml.0 for ; Wed, 03 Feb 2016 09:19:01 -0800 (PST) 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:content-type; bh=tmnh8NGXVQJ3zEdBBnYXzfanq0eCbNY3lZUoRyt+ECI=; b=wBrFvqvVYUEvz2VPV4FOHzenBR/KRX7wYS5nnUxIsZwKNrqTnbVdPMbvnlIoi+I4mO pP0KkksSzPl+v3QpdKSOCCFQGh2dXp/oTnjdSCKU2Aei9TXy6vQAhLCESUf0cLl2MmCa ja8HgusAqL6Bu/0/fzQqBds5zXgDXFQ/FdYvUKHiUVxdUU/A3mwTL+sRETs6dLer4QWn eWaTR5wE+iSUvYiU29UVPsY/j+L4Jmga0vtKk++FJCLBe/BbYjgjtSsWD+airtI98FUo J95YIGBAGv7/sQr4BuA7XKBSvzSur74HgzSE87LgaUSUfrfDpaPrPP2juFS+Gdnma9Tm VbrA== 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-type; bh=tmnh8NGXVQJ3zEdBBnYXzfanq0eCbNY3lZUoRyt+ECI=; b=k6xa1KSWQkdm7LYH3itC9aaWxUNBTd5A0GObj81EWtaXO917B8rqxCfk6NF+bfRDeE Cgnq5RMFW7GZQ091GIrP+e1agQ4ZKZKMbkoh8YayPwz8PO8qY1EiThuA0PUur6ZXye9k QFFDjX7B2VV3ssCFA39cJE/+pzSoGV0bK/cM5GMPMlOU0LcdI+VUzTSgXn6p8m0D3oNT AG1bxmvGVW1JhTK/lpdAwogAz8w0rgl2T5qm56QH6K1F3/TelMdyA+ggcQNf5S9JifAJ OQ2fFIb0NDsfS/LBv9VIfCksb0jz8Xorm+ZFfIMS1bUWQQ8phbBdsUmAumK+2RRYlzfi P/nA== X-Gm-Message-State: AG10YOSckkFFEPqBwQBVqDaTlyoc0zYC9RivNfV1l2U2zyxsCgaKrTFcuLXxJrv1LWXxe3MeBFmthDz7hO8oHg== MIME-Version: 1.0 X-Received: by 10.28.189.11 with SMTP id n11mr26864905wmf.3.1454519940389; Wed, 03 Feb 2016 09:19:00 -0800 (PST) Received: by 10.194.68.66 with HTTP; Wed, 3 Feb 2016 09:18:59 -0800 (PST) In-Reply-To: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> Date: Wed, 3 Feb 2016 09:18:59 -0800 Message-ID: From: Ca By To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114b15dc5da441052ae0d021 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:19:04 -0000 --001a114b15dc5da441052ae0d021 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 3, 2016 at 8:37 AM, Tom Herbert wrote: > On Tue, Feb 2, 2016 at 2:14 PM, Owen DeLong wrote: > > > >> On Feb 2, 2016, at 13:48 , Joe Touch wrote: > >> > >> > >> > >> On 2/2/2016 1:35 PM, Mark Smith wrote: > >>>>>> Why? There's nothing about filters that interferes with the > >>>>>> end-to-end principle. > >> > >> I'm not sure how far back that quote goes, but it's correct only if the > >> filters inspect no further than the network (IP) header. > >> > >> The transport header is meaningful only at the endpoints. They can > >> change those headers at will - i.e., change port numbers or transport > >> protocol numbers, etc., subject to agreement of the endpoints. > >> > >> Anything except the endpoints that interprets those headers is a > >> violation of E2E. It may be desired, useful, or even common, but it's > >> not E2E-compliant. > > > > We can agree to disagree. > > > > It is my NSHO that if you do not alter the packets you allow to pass, > > your inspection of the higher layer headers in making a security decision > > is not a violation of e2e. > > > What about the case where packets are dropped by an intermediate > device because it doesn't understand some legitimate L4 protocol or > isn't able to find the L4 header because it doesn't parse all the ext. > hdrs. This sort of thing is a major culprit of protocol ossification > on the Internet. Because of this it's infeasible for us (end users) to > deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with > TCP forever, it seem like the only recourse we currently have is > encapsulating "alternative" L4 protocols in UDP, but that leads to > it's own problems. > > Tom > > Alas, UDP will / is be blocked as well. UDP profiles for rate limiting are sticky around the heuristic that UDP is less than 5% of traffic during normal operations, and excess traffic over that heuristic is 100% correlated with outrage causing UDP ddos (CHARGEN, DNS, NTP, UPNP, ....) https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > Owen > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114b15dc5da441052ae0d021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 3, 2016 at 8:37 AM, Tom Herbert <tom@herbertland.com= > wrote:
On Tue, Feb 2, 2016= at 2:14 PM, Owen DeLong <owen@delong= .com> wrote:
>
>> On Feb 2, 2016, at 13:48 , Joe Touch <touch@isi.edu> wrote:
>>
>>
>>
>> On 2/2/2016 1:35 PM, Mark Smith wrote:
>>>>>> Why? There's nothing about filters that interf= eres with the
>>>>>> end-to-end principle.
>>
>> I'm not sure how far back that quote goes, but it's correc= t only if the
>> filters inspect no further than the network (IP) header.
>>
>> The transport header is meaningful only at the endpoints. They can=
>> change those headers at will - i.e., change port numbers or transp= ort
>> protocol numbers, etc., subject to agreement of the endpoints.
>>
>> Anything except the endpoints that interprets those headers is a >> violation of E2E. It may be desired, useful, or even common, but i= t's
>> not E2E-compliant.
>
> We can agree to disagree.
>
> It is my NSHO that if you do not alter the packets you allow to pass,<= br> > your inspection of the higher layer headers in making a security decis= ion
> is not a violation of e2e.
>
What about the case where packets are dropped by an intermediate
device because it doesn't understand some legitimate L4 protocol or
isn't able to find the L4 header because it doesn't parse all the e= xt.
hdrs. This sort of thing is a major culprit of protocol ossification
on the Internet. Because of this it's infeasible for us (end users) to<= br> deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with
TCP forever, it seem like the only recourse we currently have is
encapsulating "alternative" L4 protocols in UDP, but that leads t= o
it's own problems.

Tom


Alas, UDP will / is be blocked as well. UDP profiles = for rate limiting are sticky around the heuristic that UDP is less than 5% = of traffic during normal operations, and excess traffic over that heuristic= is 100% correlated with outrage causing UDP ddos (CHARGEN, DNS, NTP, UPNP,= ....)



=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
> Owen
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a114b15dc5da441052ae0d021-- From nobody Wed Feb 3 09:25:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BAE1B355E for ; Wed, 3 Feb 2016 09:25:14 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZKn_rfKMuQI for ; Wed, 3 Feb 2016 09:25:12 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AE41B3559 for ; Wed, 3 Feb 2016 09:25:11 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u13HP59l075640 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2016 17:25:05 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56B237F0.8010300@foobar.org> Date: Wed, 03 Feb 2016 17:25:04 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:25:15 -0000 Tom Herbert wrote: > What about the case where packets are dropped by an intermediate > device because it doesn't understand some legitimate L4 protocol or > isn't able to find the L4 header because it doesn't parse all the ext. > hdrs. This sort of thing is a major culprit of protocol ossification > on the Internet. Because of this it's infeasible for us (end users) to > deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with > TCP forever, it seem like the only recourse we currently have is > encapsulating "alternative" L4 protocols in UDP, but that leads to > it's own problems. This is the main subject of draft-gont-v6ops-ipv6-ehs-packet-drops. Nick From nobody Wed Feb 3 11:47:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B41B2BF5 for ; Wed, 3 Feb 2016 11:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1I9Rok-7niP for ; Wed, 3 Feb 2016 11:47:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 823E11B2BF3 for ; Wed, 3 Feb 2016 11:47:21 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u13JjGQH026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 11:45:16 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_26200465-E952-4655-99CB-E3633FD4F439" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: Date: Wed, 3 Feb 2016 11:45:16 -0800 Message-Id: <99454ED0-00E6-46D8-81BB-F8478623DFEB@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> To: Mark Smith X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 03 Feb 2016 11:45:17 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:47:24 -0000 --Apple-Mail=_26200465-E952-4655-99CB-E3633FD4F439 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I think DoS mitigation could be more effectively and more generically = achieved by network devices just performing bit pattern matching on = packets, which matches what is basically happening in the TCAMs. An = external tool of some sort would convert protocol fields it understands = into bit pattern specifications before they're pushed into the network = device performing the inspection. That would be stateless, while = providing a lot of upper layer inspection flexibility. >=20 Most of the real dDOS tools worked around that form of mitigation many = years ago. Even if they hadn=E2=80=99t, it is trivial to do so and = widespread deployment of your recommendation would be a lot of work to = achieve while taking about 10 minutes of coding to defeat. Owen --Apple-Mail=_26200465-E952-4655-99CB-E3633FD4F439 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I think DoS mitigation could be more effectively = and more generically achieved by network devices just performing bit = pattern matching on packets, which matches what is basically happening = in the TCAMs. An external tool of some sort would convert protocol = fields it understands into bit pattern specifications before they're = pushed into the network device performing the inspection. That would be = stateless, while providing a lot of upper layer inspection = flexibility.

Most of the real dDOS tools worked = around that form of mitigation many years ago. Even if they hadn=E2=80=99t= , it is trivial to do so and widespread deployment of your = recommendation would be a lot of work to achieve while taking about 10 = minutes of coding to defeat.


Owen

= --Apple-Mail=_26200465-E952-4655-99CB-E3633FD4F439-- From nobody Wed Feb 3 11:51:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BBB1B2BF7 for ; Wed, 3 Feb 2016 11:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymoSYzzdHZnB for ; Wed, 3 Feb 2016 11:51:35 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBB1B2BF6 for ; Wed, 3 Feb 2016 11:51:34 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u13JoVgd026734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 11:50:31 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: Date: Wed, 3 Feb 2016 11:50:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> To: Ca By X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 03 Feb 2016 11:50:32 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:51:36 -0000 > Alas, UDP will / is be blocked as well. UDP profiles for rate limiting = are sticky around the heuristic that UDP is less than 5% of traffic = during normal operations, and excess traffic over that heuristic is 100% = correlated with outrage causing UDP ddos (CHARGEN, DNS, NTP, UPNP, =E2=80=A6= .) I=E2=80=99m going to go out on a limb and say that there are a number of = networks where that simply isn=E2=80=99t the case=E2=80=A6 (Think VOIP = service providers, for example). Owen From nobody Wed Feb 3 13:07:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40D1B2CF8 for ; Wed, 3 Feb 2016 13:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRw9CJXsjDYe for ; Wed, 3 Feb 2016 13:07:19 -0800 (PST) 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 A8D221B2CF6 for ; Wed, 3 Feb 2016 13:07:19 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e64so24149416vkg.0 for ; Wed, 03 Feb 2016 13:07:19 -0800 (PST) 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:content-type; bh=vSP8RC66sT82e990gbrovwubFLXo+dSw4Wghh3spvPw=; b=vByUUJySSRl6XsmVJdzMY+gW9BbPW5C/OvbH1ZaHxQHZWB0jlnCb64ZwcBJn9tbkHX rF1h3u+e7R6XK6JX2qHcvzxVTb5ZwF6HRfJ950PbBEeuHdq3MBWXIa806SGsNscydEIo QnVFdzxdvg2IEkld2j0Tu2wPVYGZlO80i/VaL4B0xLJxQRpEUcrCmcn0SqSY4rHbPcEK 3SAwZj0Dqq7IxUFy5H0DzGIPPThuymP2s4Nijv6+z0wTxZ+KOS/i2N56OmnrSaTGYtb9 8DWnbtidwLTqOEnwlklJ0SpCxZKo3hmGVDk20TCFUB0ie0+5+SYPxA5j4FowlbSHbuZY GeVQ== 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-type; bh=vSP8RC66sT82e990gbrovwubFLXo+dSw4Wghh3spvPw=; b=fnwoPQBFE7+uGZ03Jjc4f1zgmpXuLiCBzCUMVSo1ZNyE/TAb5cl9YZQB+F1L+DLQUK v9f/kyo3jNj5/0LCly7W34yIoRHSQQsFcYdvcuPM8JYRYgWarFwZGsPXUMc0ybOeJNE3 TKv8LJgXAjQQOrBzNSqZ/2OkpHVWTUytwITxZbPIF6Qs32THvwPFO8JE6TBQIfMNDUQp MzRCubJc/2r0WaPDJPkjiWTUw4IiC5Cf7qFsO25roz/foDGl+vC2fNVjwYbfIzAzH5s9 8SV0HS0lLPZk5htyeS1AUrlkiVg6m2WGSEHX7YawQLE+526+YXB9jWvmBNSwDIQ0y60V swFQ== X-Gm-Message-State: AG10YOTKLjinb4qY3LcdfFypaIBgRtq2LYFhk2ZsxK+4kHM/hIOZ0iwRQRgC9lFeOMDV3gjJ4+4Y7lXyxmKLWA== MIME-Version: 1.0 X-Received: by 10.31.133.201 with SMTP id h192mr2895515vkd.102.1454533638892; Wed, 03 Feb 2016 13:07:18 -0800 (PST) Received: by 10.103.92.67 with HTTP; Wed, 3 Feb 2016 13:07:18 -0800 (PST) Received: by 10.103.92.67 with HTTP; Wed, 3 Feb 2016 13:07:18 -0800 (PST) In-Reply-To: <99454ED0-00E6-46D8-81BB-F8478623DFEB@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> <99454ED0-00E6-46D8-81BB-F8478623DFEB@delong.com> Date: Thu, 4 Feb 2016 08:07:18 +1100 Message-ID: From: Mark Smith To: Owen DeLong Content-Type: multipart/alternative; boundary=001a114119a2dc3085052ae4005f Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:07:21 -0000 --001a114119a2dc3085052ae4005f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 Feb 2016 6:46 AM, "Owen DeLong" wrote: >> >> I think DoS mitigation could be more effectively and more generically achieved by network devices just performing bit pattern matching on packets, which matches what is basically happening in the TCAMs. An external tool of some sort would convert protocol fields it understands into bit pattern specifications before they're pushed into the network device performing the inspection. That would be stateless, while providing a lot of upper layer inspection flexibility. > > Most of the real dDOS tools worked around that form of mitigation many years ago. Even if they hadn=E2=80=99t, it is trivial to do so and widespre= ad deployment of your recommendation would be a lot of work to achieve while taking about 10 minutes of coding to defeat. > > Example please. Demonstrate how an inflexible packet matching device that hard interprets packet field layouts and values is going to be more effective than a device that can match any specified bit pattern in any location in the packet, including bit patterns that can span multiple traditional packet fields. > Owen > --001a114119a2dc3085052ae4005f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 Feb 2016 6:46 AM, "Owen DeLong" <owen@delong.com> wrote:
>>
>> I think DoS mitigation could be more effectively and more generica= lly achieved by network devices just performing bit pattern matching on pac= kets, which matches what is basically happening in the TCAMs. An external t= ool of some sort would convert protocol fields it understands into bit patt= ern specifications before they're pushed into the network device perfor= ming the inspection. That would be stateless, while providing a lot of uppe= r layer inspection flexibility.
>
> Most of the real dDOS tools worked around that form of mitigation many= years ago. Even if they hadn=E2=80=99t, it is trivial to do so and widespr= ead deployment of your recommendation would be a lot of work to achieve whi= le taking about 10 minutes of coding to defeat.
>
>

Example please.

Demonstrate how an inflexible packet matching device that ha= rd interprets packet field layouts and values is going to be more effective= than a device that can match any specified bit pattern in any location in = the packet, including bit patterns that can span multiple traditional packe= t fields.

> Owen
>

--001a114119a2dc3085052ae4005f-- From nobody Wed Feb 3 13:45:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBACC1B2DB9 for ; Wed, 3 Feb 2016 13:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQa-qME9zQMs for ; Wed, 3 Feb 2016 13:45:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C26E91B2DB3 for ; Wed, 3 Feb 2016 13:45:19 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u13LhDMR005601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 13:43:14 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_E01B0948-B774-452C-9B28-53C3808C8487" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: Date: Wed, 3 Feb 2016 13:43:13 -0800 Message-Id: <40506FE2-79C1-454F-B8E7-6270F0C2F053@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <57F5F519-32E8-4FAB-822F-F656E40AF0E6@cisco.com> <99454ED0-00E6-46D8-81BB-F8478623DFEB@delong.com> To: Mark Smith X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 03 Feb 2016 13:43:14 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:45:24 -0000 --Apple-Mail=_E01B0948-B774-452C-9B28-53C3808C8487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2016, at 13:07 , Mark Smith wrote: >=20 >=20 > On 4 Feb 2016 6:46 AM, "Owen DeLong" > wrote: > >> > >> I think DoS mitigation could be more effectively and more = generically achieved by network devices just performing bit pattern = matching on packets, which matches what is basically happening in the = TCAMs. An external tool of some sort would convert protocol fields it = understands into bit pattern specifications before they're pushed into = the network device performing the inspection. That would be stateless, = while providing a lot of upper layer inspection flexibility. > > > > Most of the real dDOS tools worked around that form of mitigation = many years ago. Even if they hadn=E2=80=99t, it is trivial to do so and = widespread deployment of your recommendation would be a lot of work to = achieve while taking about 10 minutes of coding to defeat. > > > > >=20 > Example please. >=20 > Demonstrate how an inflexible packet matching device that hard = interprets packet field layouts and values is going to be more effective = than a device that can match any specified bit pattern in any location = in the packet, including bit patterns that can span multiple traditional = packet fields. >=20 Most packet matching devices used for dDOS mitigation in the modern = world are not inflexible. Hence your claim depends on an invalid = assertion. Owen --Apple-Mail=_E01B0948-B774-452C-9B28-53C3808C8487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 3, 2016, at 13:07 , Mark Smith <markzzzsmith@gmail.com> wrote:


On 4 Feb 2016 6:46 AM, "Owen DeLong" <owen@delong.com> = wrote:
>>
>> I think DoS mitigation could be more effectively and more = generically achieved by network devices just performing bit pattern = matching on packets, which matches what is basically happening in the = TCAMs. An external tool of some sort would convert protocol fields it = understands into bit pattern specifications before they're pushed into = the network device performing the inspection. That would be stateless, = while providing a lot of upper layer inspection flexibility.
>
> Most of the real dDOS tools worked around that form of mitigation = many years ago. Even if they hadn=E2=80=99t, it is trivial to do so and = widespread deployment of your recommendation would be a lot of work to = achieve while taking about 10 minutes of coding to defeat.
>
>

Example please.

Demonstrate how an inflexible packet matching device that = hard interprets packet field layouts and values is going to be more = effective than a device that can match any specified bit pattern in any = location in the packet, including bit patterns that can span multiple = traditional packet fields.

Most packet = matching devices used for dDOS mitigation in the modern world are not = inflexible. Hence your claim depends on an invalid assertion.

Owen

= --Apple-Mail=_E01B0948-B774-452C-9B28-53C3808C8487-- From nobody Wed Feb 3 15:25:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07A51B3688 for ; Wed, 3 Feb 2016 15:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4blJImTJTiIf for ; Wed, 3 Feb 2016 15:24:58 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B602D1B3687 for ; Wed, 3 Feb 2016 15:24:58 -0800 (PST) Received: from [172.20.5.68] (96-91-217-194-static.hfc.comcastbusiness.net [96.91.217.194] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u13NOWC0013377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Feb 2016 15:24:44 -0800 (PST) To: Tom Herbert , Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> From: Joe Touch Message-ID: <56B28C2E.3030302@isi.edu> Date: Wed, 3 Feb 2016 15:24:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 23:24:59 -0000 On 2/3/2016 8:37 AM, Tom Herbert wrote: > What about the case where packets are dropped by an intermediate > device because it doesn't understand some legitimate L4 protocol or > isn't able to find the L4 header because it doesn't parse all the ext. > hdrs. Or IPsec. Joe From nobody Wed Feb 3 20:27:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185241A0093 for ; Wed, 3 Feb 2016 20:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJC-SLAiD4zz for ; Wed, 3 Feb 2016 20:27:50 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 19FE11A0092 for ; Wed, 3 Feb 2016 20:27:49 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u144QjRm011194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 20:26:45 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_B739150E-DECA-48CB-806A-468D31654E78" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: Date: Wed, 3 Feb 2016 20:26:39 -0800 Message-Id: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> To: Tom Herbert X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 03 Feb 2016 20:26:46 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 04:27:52 -0000 --Apple-Mail=_B739150E-DECA-48CB-806A-468D31654E78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>=20 >> We can agree to disagree. >>=20 >> It is my NSHO that if you do not alter the packets you allow to pass, >> your inspection of the higher layer headers in making a security = decision >> is not a violation of e2e. >>=20 > What about the case where packets are dropped by an intermediate > device because it doesn't understand some legitimate L4 protocol or > isn't able to find the L4 header because it doesn't parse all the ext. > hdrs. This sort of thing is a major culprit of protocol ossification > on the Internet. Because of this it's infeasible for us (end users) to > deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with > TCP forever, it seem like the only recourse we currently have is > encapsulating "alternative" L4 protocols in UDP, but that leads to > it's own problems. First, being unable to find the L4 header because you can=E2=80=99t = parse the ext. headers shouldn=E2=80=99t happen. Extension headers are = all designed with standard parameters at the beginning allowing them to = be skipped if they are not understood. If the intermediate system is under a different authority than the end = host, I agree this is inappropriate and have said so. Note, different = authority here gets murky. For example, the security department of XYZ, = Inc. is not for this purpose IMHO a different authority from the rest of = XYZ, Inc. OTOH, if $ISP is blocking packets for their customers that their = customers would prefer to see, then $ISP is both a different authority = _AND_ quite thoroughly in the wrong. Most of the protocol ossification I have observed relates to what will = pass NAT vs. what won=E2=80=99t. A little bit results from corporate policies that seem to think forcing = everyone to use HTTPs and DNS to encapsulate everything else somehow = improves their security posture. NAT is largely an IPv4 problem. The other is largely an educational = problem. Owen --Apple-Mail=_B739150E-DECA-48CB-806A-468D31654E78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

We can agree to disagree.

It is = my NSHO that if you do not alter the packets you allow to pass,
your inspection of the higher layer headers in making a = security decision
is not a violation of e2e.

What about the case where = packets are dropped by an intermediate
device because it doesn't understand some = legitimate L4 protocol or
isn't able to find the L4 header because it = doesn't parse all the ext.
hdrs. This sort of thing is a major culprit of = protocol ossification
on the Internet. Because of this it's infeasible = for us (end users) to
deploy SCTP, IP option, ext. hdrs. etc. Other = than being stuck with
TCP forever, it seem like the only recourse we = currently have is
encapsulating "alternative" L4 protocols in UDP, = but that leads to
it's own problems.

First, = being unable to find the L4 header because you can=E2=80=99t parse the = ext. headers shouldn=E2=80=99t happen. Extension headers are all = designed with standard parameters at the beginning allowing them to be = skipped if they are not understood.

If the intermediate system is under a = different authority than the end host, I agree this is inappropriate and = have said so. Note, different authority here gets murky. For example, = the security department of XYZ, Inc. is not for this purpose IMHO a = different authority from the rest of XYZ, Inc.

OTOH, if $ISP is blocking packets for = their customers that their customers would prefer to see, then $ISP is = both a different authority _AND_ quite thoroughly in the = wrong.

Most of = the protocol ossification I have observed relates to what will pass NAT = vs. what won=E2=80=99t.

A little bit results from corporate policies that seem to = think forcing everyone to use HTTPs and DNS to encapsulate everything = else somehow improves their security posture.

NAT is largely an IPv4 problem. The = other is largely an educational problem.

Owen

= --Apple-Mail=_B739150E-DECA-48CB-806A-468D31654E78-- From nobody Thu Feb 4 03:17:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385AE1ACEB2 for ; Thu, 4 Feb 2016 03:17:42 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QjzNj-9xlv4 for ; Thu, 4 Feb 2016 03:17:40 -0800 (PST) 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 150061ACEAF for ; Thu, 4 Feb 2016 03:17:39 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 5FCAE206ABD; Thu, 4 Feb 2016 12:17:35 +0100 (CET) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <10DF2D0B-4E24-432C-9770-FE395066D12C@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B32D96.9090502@si6networks.com> Date: Thu, 4 Feb 2016 07:53:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <10DF2D0B-4E24-432C-9770-FE395066D12C@delong.com> Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 11:17:42 -0000 On 02/02/2016 02:44 PM, Owen DeLong wrote: > >> On Feb 2, 2016, at 06:33 , Fernando Gont wrote: >> >> On 02/02/2016 10:20 AM, Owen DeLong wrote: >>> >>>> On Feb 1, 2016, at 23:56, Fernando Gont wrote: >>>> >>>>> On 02/01/2016 07:25 PM, Owen DeLong wrote: >>>>> [...] >>>>> >>>>> The thing that strikes me most about this is that a host which has an >>>>> adequate stateful inspection firewall in front of it realy has no more issue >>>>> from itĄŻs IPv6 address being harvested than it does from its IPv4 >>>>> address being harvested, so IĄŻm not seeing how this is news or how it really >>>>> represents any sort of inherent vulnerability. >>>>> >>>>> Perhaps someone can enlighten me as to how this is some new security >>>>> issue we should be concerned about, but for now, it appears to me as if >>>>> it is much ado about nothing. >>>> >>>> Maybe in that in IPv4 you typically have a NAT in front of your node, >>>> where in IPv6 you don't necessarily have a fw? >>>> >>> >>> If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem. >> >> There's a reason for deploying network-based firewalls: >> > > A network-based firewall is one form of filter. IĄŻm not sure why you think my statement was antithetical to that. I took your statement as implying that a host should run its own filters. Looks like it was a misunderstanding on my side -- my apologies. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 4 03:17:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613AE1ACEB8 for ; Thu, 4 Feb 2016 03:17:50 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I73uk324XT3E for ; Thu, 4 Feb 2016 03:17:45 -0800 (PST) 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 9F8E21ACEB7 for ; Thu, 4 Feb 2016 03:17:45 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 42D2B206ABF; Thu, 4 Feb 2016 12:17:41 +0100 (CET) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BEBA.1050203@si6networks.com> <9E55768C-BCDC-475E-BB53-3435FB9359C4@delong.com> From: Fernando Gont Message-ID: <56B32E44.1050906@si6networks.com> Date: Thu, 4 Feb 2016 07:56:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9E55768C-BCDC-475E-BB53-3435FB9359C4@delong.com> Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 11:17:50 -0000 On 02/02/2016 02:46 PM, Owen DeLong wrote: > >> On Feb 2, 2016, at 06:35 , Fernando Gont >> wrote: >> >> On 02/02/2016 10:20 AM, Owen DeLong wrote: >>> >>> >>>> On Feb 1, 2016, at 23:56, Fernando Gont >>>> wrote: >>>> >>>>> On 02/01/2016 07:25 PM, Owen DeLong wrote: [...] >>>>> >>>>> The thing that strikes me most about this is that a host >>>>> which has an adequate stateful inspection firewall in front >>>>> of it realy has no more issue from itĄŻs IPv6 address being >>>>> harvested than it does from its IPv4 address being harvested, >>>>> so IĄŻm not seeing how this is news or how it really >>>>> represents any sort of inherent vulnerability. >>>>> >>>>> Perhaps someone can enlighten me as to how this is some new >>>>> security issue we should be concerned about, but for now, it >>>>> appears to me as if it is much ado about nothing. >>>> >>>> Maybe in that in IPv4 you typically have a NAT in front of your >>>> node, where in IPv6 you don't necessarily have a fw? >>>> >>> >>> If you're running a host without any sort of filter, that's >>> really not a problem we should be solving at the network level. >>> That's more of an educational problem. >> >> Besides, in th IoT world, the "host" may be a network-connected >> lamp with some >> crappy-and-impopssible-to-upgrade-or-even-adminisiter firmwareĄŚ > > If your lamp doesnĄŻt have a firewall with a packet filter or stateful > inspection in front of it, then you deserve your house blinking > radically at all hours of the day or nightĄŚ > > However, I said Ą°without any sort of filterĄą. Not Ą°without a > host-based filterĄą, so IĄŻm still unclear on how this is a relevant > response to what I said. Then we're on the same page. Thanks for the clarification! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 4 03:18:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CA41ACEB2 for ; Thu, 4 Feb 2016 03:17:56 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djWAOubp7rPz for ; Thu, 4 Feb 2016 03:17:51 -0800 (PST) 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 053C41ACEB7 for ; Thu, 4 Feb 2016 03:17:51 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 CE993206A44; Thu, 4 Feb 2016 12:17:47 +0100 (CET) To: Enno Rey , v6ops@ietf.org References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B33300.6060704@si6networks.com> Date: Thu, 4 Feb 2016 08:16:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202211331.GA95817@ernw.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 11:17:56 -0000 On 02/02/2016 06:13 PM, Enno Rey wrote: > Hi, > >> On 02/02/2016 09:44 AM, Owen DeLong wrote: >>>>> If you're running a host without any sort of filter, that's >>>>> really not a problem we should be solving at the network >>>>> level. That's more of an educational problem. >>>> >>>> that's a very interesting statement, taking the end-to-end >>>> principle into account, which IPv6 strives to realize/bring >>>> back. >>> >>> Why? There???s nothing about filters that interferes with the >>> end-to-end principle. >>> >>> A Stateful inspection firewall that doesn???t mangle the packet >>> header is perfectly acceptable in an end-to-end world. Whether >>> it???s a network-level firewall, a host-level firewall, both, >>> etc. > > a network-level "stateful inspection" firewall keeps track of, well, > state. doing so "in the network" is a - from my understanding - > fundamental violation of the e2e principle, not least as it impedes > "survivability in the face of failure". FWIW, this is what we say in about this: ---- cut here ---- 3.2. The End-to-End Principle One common complaint about firewalls in general is that they violate the End-to-End Principle [Saltzer]. The End-to-End Principle is often incorrectly stated as requiring that "application specific functions ought to reside in the end nodes of a network rather than in intermediary nodes, provided they can be implemented 'completely and correctly' in the end nodes" or that "there should be no state in the network." What it actually says is heavily nuanced, and is a line of reasoning applicable when considering any two communication layers. [Saltzer] "presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." In other words, the End-to-End Argument is not a prohibition against e.g. lower layer retries of transmissions, which can be important in certain LAN technologies, nor of the maintenance of state, nor of consistent policies imposed for security reasons. It is, however, a plea for simplicity. Any behavior of a lower communication layer, whether found in the same system as the higher layer (and especially application) functionality or in a different one, that from the perspective of a higher layer introduces inconsistency, complexity, or coupling extracts a cost. That cost may be in user satisfaction, difficulty of management or fault diagnosis, difficulty of future innovation, reduced performance, or other forms. Such costs need to be clearly and honestly weighed against the benefits expected, and used only if the benefit outweighs the cost. From that perspective, introduction of a policy that prevents communication under an understood set of circumstances, whether it is to prevent access to pornographic sites or prevents traffic that can be characterized as an attack, does not fail the End-to-End Argument; there are any number of possible sites on the network that are inaccessible at any given time, and the presence of such a policy is easily explained and understood. What does fail the End-to-End Argument is behavior that is intermittent, difficult to explain, or unpredictable. If I can sometimes reach a site and not at other times, or reach it using this host or application but not another, I wonder why that is true, and may not even know where to look for the issue. ---- cut here ---- Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 4 03:34:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A301ACF19 for ; Thu, 4 Feb 2016 03:34:16 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X7ZXeAYBv_e for ; Thu, 4 Feb 2016 03:34:14 -0800 (PST) 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 AE3C61ACF17 for ; Thu, 4 Feb 2016 03:34:14 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 DFD34206ABF; Thu, 4 Feb 2016 12:34:08 +0100 (CET) To: Owen DeLong , Tom Herbert References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B33602.2040303@si6networks.com> Date: Thu, 4 Feb 2016 08:29:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 11:34:16 -0000 On 02/04/2016 01:26 AM, Owen DeLong wrote: >>> >>> We can agree to disagree. >>> >>> It is my NSHO that if you do not alter the packets you allow to pass, >>> your inspection of the higher layer headers in making a security decision >>> is not a violation of e2e. >>> >> What about the case where packets are dropped by an intermediate >> device because it doesn't understand some legitimate L4 protocol or >> isn't able to find the L4 header because it doesn't parse all the ext. >> hdrs. This sort of thing is a major culprit of protocol ossification >> on the Internet. Because of this it's infeasible for us (end users) to >> deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with >> TCP forever, it seem like the only recourse we currently have is >> encapsulating "alternative" L4 protocols in UDP, but that leads to >> it's own problems. > > First, being unable to find the L4 header because you can’t parse the > ext. headers shouldn’t happen. Extension headers are all designed with > standard parameters at the beginning allowing them to be skipped if they > are not understood. Not really. Please see: [....] > OTOH, if $ISP is blocking packets for their customers that their > customers would prefer to see, then $ISP is both a different authority > _AND_ quite thoroughly in the wrong. > > Most of the protocol ossification I have observed relates to what will > pass NAT vs. what won’t. +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 Thu Feb 4 04:44:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823F11B2E52 for ; Thu, 4 Feb 2016 04:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTvO3VP6HS3j for ; Thu, 4 Feb 2016 04:44:02 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED741B2E50 for ; Thu, 4 Feb 2016 04:44:02 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u14ChdEm003090; Thu, 4 Feb 2016 12:43:39 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u14ChdEm003090 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1454589825; bh=rWdaDLI1VZdSr5TpBAmDimsuNBc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=4yheUujREztPaUv3Zg4xTi/dNHyGgK37OChayYFanzSSgFfA4vloZSuj065DxjUPu 7jmj6KX2oWfnscwk4G2KS1VtxppviTKikfTxQe+YjNFj9W8oHlF8aBthhi1E6anURI T2K/ES1fU0XFMkGT2q6mW1MDgfM1giDAMwv6844M= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s13Chd1791807560yk ret-id none; Thu, 04 Feb 2016 12:43:45 +0000 Received: from [192.168.0.10] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u14ChKNc001501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2016 12:43:21 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Tim Chown In-Reply-To: <1FE3E9E6-57B8-40E8-AE4D-5CA181F07F88@cisco.com> Date: Thu, 4 Feb 2016 12:43:20 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <56B0BE2B.5050408@si6networks.com> <7A88E510-8A39-4765-A762-E855B9ACBDFF@ecs.soton.ac.uk> <1FE3E9E6-57B8-40E8-AE4D-5CA181F07F88@cisco.com> <29A110F0-7F24-4F2C-B992-B42D4E385108@ecs.soton.ac.uk> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s13Chd179180756000; tid=s13Chd1791807560yk; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u14ChdEm003090 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 12:44:03 -0000 > On 2 Feb 2016, at 18:45, Fred Baker (fred) wrote: >=20 >=20 >> On Feb 2, 2016, at 10:31 AM, Tim Chown wrote: >>=20 >>> There is an unaddressed tension here. >>> I think one view is that IPv6 should be deployed without firewalls = so all >>> hosts are reachable from arbitrary other hosts on the Internet. >>> I think the other view is that all/most/many hosts should be = protected by >>> a stateful firewall. >>>=20 >>> I don=C2=B9t know that we can resolve this tension in v6ops, but I = want to make >>> it explicit. >>=20 >> Well, we=E2=80=99ve seen a few firewall models put forward in v6ops. = RFC 6092 seems >> to have been generally well received. It may well be the only one = that made it >> to RFC status? e.g. draft-ietf-v6ops-balanced-ipv6-security-01 = stopped at that >> version. >=20 > That is explicitly why Fernando and I are trying to have a firewall = discussion in opsawg (draft-gont-opsawg-firewalls-analysis). RFC 6092 is = certainly a common firewall model (modeling a NAT's behavior), but I = would say that the consensus supporting it was "rough". The other = firewall models proposed (draft-ietf-v6ops-balanced-ipv6-security, = draft-vyncke-advanced-ipv6-security) basically pushed towards = firewall-as-a-service, and as such gutted the filter function. >=20 > I'll refer us to that discussion if we want to go general on firewall = functionality. >=20 > My question here was essentially about finding a simple rule = *on*the*host* that might obviate a lot of attacks and probing. The = conclusion that I draw is that I can do anything I want as long as I = don't change anything, and yes, my suggestion is a change. I actually do = think there may be value in it, however. I agree. And to me that seems fine - how the host handles the = address(es) it uses to initiate or receive traffic is a matter for it, = just as host-based filtering / access control is. Tim From nobody Thu Feb 4 12:08:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DBC1ACE59 for ; Thu, 4 Feb 2016 12:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7NkQthFSGQW for ; Thu, 4 Feb 2016 12:08:38 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 272BA1ACE36 for ; Thu, 4 Feb 2016 12:08:37 -0800 (PST) Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u14K7Zax024761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2016 12:07:35 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_4996A342-9409-4258-936A-B5F295002970" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <56B33602.2040303@si6networks.com> Date: Thu, 4 Feb 2016 12:07:34 -0800 Message-Id: <13F5CF07-9ED5-480C-AEA8-4535102CCB46@delong.com> References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> <56B33602.2040303@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 04 Feb 2016 12:07:35 -0800 (PST) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:08:40 -0000 --Apple-Mail=_4996A342-9409-4258-936A-B5F295002970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Wouldn=92t it be simpler just to require all IPv6 extension headers to = conform to the NH/HdrExtLen first fields? I don=92t see the point of encapsulating all future extension headers in = yet another header. To the best of my knowledge, all existing extension headers already = conform to this syntax. TBH, I thought they were already required to do = so. Owen > On Feb 4, 2016, at 03:29 , Fernando Gont = wrote: >=20 > On 02/04/2016 01:26 AM, Owen DeLong wrote: >>>>=20 >>>> We can agree to disagree. >>>>=20 >>>> It is my NSHO that if you do not alter the packets you allow to = pass, >>>> your inspection of the higher layer headers in making a security = decision >>>> is not a violation of e2e. >>>>=20 >>> What about the case where packets are dropped by an intermediate >>> device because it doesn't understand some legitimate L4 protocol or >>> isn't able to find the L4 header because it doesn't parse all the = ext. >>> hdrs. This sort of thing is a major culprit of protocol ossification >>> on the Internet. Because of this it's infeasible for us (end users) = to >>> deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with >>> TCP forever, it seem like the only recourse we currently have is >>> encapsulating "alternative" L4 protocols in UDP, but that leads to >>> it's own problems. >>=20 >> First, being unable to find the L4 header because you can=92t parse = the >> ext. headers shouldn=92t happen. Extension headers are all designed = with >> standard parameters at the beginning allowing them to be skipped if = they >> are not understood. >=20 > Not really. Please see: > > >=20 >=20 > [....] >> OTOH, if $ISP is blocking packets for their customers that their >> customers would prefer to see, then $ISP is both a different = authority >> _AND_ quite thoroughly in the wrong. >>=20 >> Most of the protocol ossification I have observed relates to what = will >> pass NAT vs. what won=92t. >=20 > +1 >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --Apple-Mail=_4996A342-9409-4258-936A-B5F295002970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Wouldn=92t it be simpler just to require all IPv6 extension = headers to conform to the NH/HdrExtLen first fields?

I don=92t see the point of = encapsulating all future extension headers in yet another = header.

To the = best of my knowledge, all existing extension headers already conform to = this syntax. TBH, I thought they were already required to do = so.

Owen

On Feb 4, 2016, at 03:29 , = Fernando Gont <fgont@si6networks.com> wrote:

On 02/04/2016 01:26 AM, Owen DeLong = wrote:

We can agree to disagree.

It is = my NSHO that if you do not alter the packets you allow to pass,
your inspection of the higher layer headers in making a = security decision
is not a violation of e2e.

What about the case where packets = are dropped by an intermediate
device because it doesn't = understand some legitimate L4 protocol or
isn't able to = find the L4 header because it doesn't parse all the ext.
hdrs. This sort of thing is a major culprit of protocol = ossification
on the Internet. Because of this it's = infeasible for us (end users) to
deploy SCTP, IP option, = ext. hdrs. etc. Other than being stuck with
TCP forever, = it seem like the only recourse we currently have is
encapsulating "alternative" L4 protocols in UDP, but that = leads to
it's own problems.

First, being unable to find the L4 header because you can=92t = parse the
ext. headers shouldn=92t happen. Extension = headers are all designed with
standard parameters at the = beginning allowing them to be skipped if they
are not = understood.

Not really. Please see:
<https://www.ietf.org/id/draft-gont-6man-rfc6564bis-01.txt>


[....]
OTOH,= if $ISP is blocking packets for their customers that their
customers would prefer to see, then $ISP is both a different = authority
_AND_ quite thoroughly in the wrong.

Most of the protocol ossification I have = observed relates to what will
pass NAT vs. what won=92t.

+1

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

= --Apple-Mail=_4996A342-9409-4258-936A-B5F295002970-- From nobody Thu Feb 4 12:34:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522291AD218 for ; Thu, 4 Feb 2016 12:34:32 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEc1yXIkqKMB for ; Thu, 4 Feb 2016 12:34:30 -0800 (PST) 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 BD4411AD2DF for ; Thu, 4 Feb 2016 12:34:11 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 BDC39206ABF; Thu, 4 Feb 2016 21:34:08 +0100 (CET) To: Owen DeLong References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <56AFD626.1000802@bogus.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de> <56B12415.3010003@isi.edu> <56B33602.2040303@si6networks.com> <13F5CF07-9ED5-480C-AEA8-4535102CCB46@delong.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B3B5AE.8060104@si6networks.com> Date: Thu, 4 Feb 2016 17:33:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <13F5CF07-9ED5-480C-AEA8-4535102CCB46@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] Hmm. Interesting article... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:34:32 -0000 On 02/04/2016 05:07 PM, Owen DeLong wrote: > Wouldn’t it be simpler just to require all IPv6 extension headers to > conform to the NH/HdrExtLen first fields? You can''t, because the upper-layer protocols and EHs share the same namespace. Example: Say you receive unknown NH=88... Is it a new transport protocol, or a new EH? -- Answer: You just can't tell. > I don’t see the point of encapsulating all future extension headers in > yet another header. > > To the best of my knowledge, all existing extension headers already > conform to this syntax. TBH, I thought they were already required to do so. The problem is not existing EHs -- those you can identify, and hence know how to parse. The problem is any new EHs or upper-ayer-protocols defined in the future. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 4 18:03:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF681B2C8C for ; Thu, 4 Feb 2016 18:03:56 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldYFL8QJwgwJ for ; Thu, 4 Feb 2016 18:03:54 -0800 (PST) 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 62D781B2C8A for ; Thu, 4 Feb 2016 18:03:54 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 BE161206A64; Fri, 5 Feb 2016 03:03:51 +0100 (CET) From: Fernando Gont To: IPv6 Operations References: <56B401AE.2030105@si6networks.com> Message-ID: <56B40284.5070604@si6networks.com> Date: Thu, 4 Feb 2016 23:01:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B401AE.2030105@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Fwd: Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 02:03:56 -0000 Folks, FYI. We expect discussion to happen on the opsawg@ietf.org mailing-list. -------- Forwarded Message -------- Subject: Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-02.txt Date: Thu, 4 Feb 2016 22:58:06 -0300 From: Fernando Gont To: opsawg@ietf.org Folks, We have posted a revision of our firewalls document. The revised I-D is available at: Among the changes are: * We have rewritten the intro. * The document clearly states what the goals of this document are. * The document has now a more clear definition of what we mean by "firewall", and is agnostic regarding the specific layer at which the firewall operates (in most of the discussion about firewalls). * Some sections have been augmented. * Minor editorial changes. Your feedback will be appreciated (on the opsawg@ietf.org mailing-list). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsawg-firewalls-analysis-02.txt Date: Thu, 04 Feb 2016 16:58:07 -0800 From: internet-drafts@ietf.org To: Fred Baker , Fernando Gont A new version of I-D, draft-gont-opsawg-firewalls-analysis-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsawg-firewalls-analysis Revision: 02 Title: On Firewalls in Network Security Document date: 2016-02-04 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/ Htmlized: https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-opsawg-firewalls-analysis-02 Abstract: This document analyzes the role of firewalls in network security, and recognizes their role in the internet architecture. It suggests a line of reasoning about their usage, and analyzes common kinds of firewalls and the claims made for them. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Feb 4 20:41:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33971B34FB for ; Thu, 4 Feb 2016 20:41:05 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 955wAOZo990f for ; Thu, 4 Feb 2016 20:41:00 -0800 (PST) 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 1B5EC1B34FA for ; Thu, 4 Feb 2016 20:41:00 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 470ED206ABD; Fri, 5 Feb 2016 05:40:54 +0100 (CET) References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> To: IPv6 Operations From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> Message-ID: <56B40916.1060504@si6networks.com> Date: Thu, 4 Feb 2016 23:29:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" Subject: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 04:41:05 -0000 Folks, We have published a revision of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: . This revision is mostly meant to: * Address the detailed comments received from Andrew Yourtchenko * Address the detailed revision received from Sander Steffann. * Address Brian Carpenter's comments regarding the Flow Label * Clearly state the goals of this document, as requested during my presentation at the Yokohama IETF. Your feedback will be appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt Date: Thu, 04 Feb 2016 13:46:39 -0800 From: internet-drafts@ietf.org To: Nick Hilliard , Shucheng LIU (Will) , Gert Doering , Will Liu (Shucheng) , Fernando Gont , Warren Kumari A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 02 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2016-02-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-02 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Feb 5 05:07:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2DB1B384E for ; Fri, 5 Feb 2016 05:07:21 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v_bYjA1p_t1 for ; Fri, 5 Feb 2016 05:07:19 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CA71B384C for ; Fri, 5 Feb 2016 05:07:19 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15D7FK0061543 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 13:07:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B49E82.6030900@foobar.org> Date: Fri, 05 Feb 2016 13:07:14 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Fernando Gont References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> In-Reply-To: <56B40916.1060504@si6networks.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 13:07:21 -0000 Fernando Gont wrote: > * Address Brian Carpenter's comments regarding the Flow Label the flow label is more nuanced than it looks. If you're load balancing traffic via LAG or ECMP, you need a consistent source of flow based entropy which can be determined from an individual packet so that you can build up a hash key which will allow the router to send packets belonging to same flow down the same bearer link in a bundle. Routers need to do this because if you end up with out-of-sequence packet delivery, performance will drop considerably. The problem with the ipv6 flow label spec is that it does not affect how either the source or the destination handles an individual flow. This means that an ipv6 source host can set a flow label to be any value without affecting how the destination host will handle the value. The problem is that the flow label is expected to influence how intermediate routers process the packet, in particular which bearer links they might choose in a bundle. In other words, because the end hosts can control the flow label arbitrarily, control of LAG/ECMP hashing is substantially put in the hands of the end hosts, rather than the network operator. This is the case because the end hosts can tune the LAG/ECMP hash value without affecting any other characteristics of a particular data flow. This strikes me as being a poor idea. The relevance of this to draft-gont-v6ops-ipv6-ehs-packet-drops is that it means that it's a particularly bad idea to depend on the flow label as the sole source of entropy for LAG / ECMP hashing. This in turn means that it would be advisable to depend on other consistent entropy sources (e.g. the normal 5-tuples). These can only easily be determined if the ipv6 header doesn't contain EHs. Nick From nobody Fri Feb 5 06:57:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060BC1B39F9 for ; Fri, 5 Feb 2016 06:57:21 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrIrl8OdvP6A for ; Fri, 5 Feb 2016 06:57:19 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD031B39CE for ; Fri, 5 Feb 2016 06:57:19 -0800 (PST) Received: from [192.52.179.108] (dc108.internet2.edu [192.52.179.108]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u15EuWgB013077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 06:56:34 -0800 (PST) To: Nick Hilliard , Fernando Gont References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> From: Joe Touch Message-ID: <56B4B81E.6080904@isi.edu> Date: Fri, 5 Feb 2016 06:56:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B49E82.6030900@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u15EuWgB013077 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:57:21 -0000 On 2/5/2016 5:07 AM, Nick Hilliard wrote: > Fernando Gont wrote: >> * Address Brian Carpenter's comments regarding the Flow Label > > the flow label is more nuanced than it looks. > > If you're load balancing traffic via LAG or ECMP, you need a consistent > source of flow based entropy which can be determined from an individual > packet so that you can build up a hash key which will allow the router > to send packets belonging to same flow down the same bearer link in a > bundle. Routers need to do this because if you end up with > out-of-sequence packet delivery, performance will drop considerably. > > The problem with the ipv6 flow label spec is that it does not affect how > either the source or the destination handles an individual flow. This > means that an ipv6 source host can set a flow label to be any value > without affecting how the destination host will handle the value. The > problem is that the flow label is expected to influence how intermediate > routers process the packet, in particular which bearer links they might > choose in a bundle. > > In other words, because the end hosts can control the flow label > arbitrarily, control of LAG/ECMP hashing is substantially put in the > hands of the end hosts, rather than the network operator. This is the > case because the end hosts can tune the LAG/ECMP hash value without > affecting any other characteristics of a particular data flow. This > strikes me as being a poor idea. > > The relevance of this to draft-gont-v6ops-ipv6-ehs-packet-drops is that > it means that it's a particularly bad idea to depend on the flow label > as the sole source of entropy for LAG / ECMP hashing. This in turn > means that it would be advisable to depend on other consistent entropy > sources (e.g. the normal 5-tuples). These can only easily be determined > if the ipv6 header doesn't contain EHs. Why do you think that any other endpoint assigned values in these 5-tuples would not have the same problems as the flow label? I.e., either they have no entropy (fixed per host) or are assigned within the host in a way that might not optimize entropy at all. So there's no reason to worry about EHs for this issue. Either you trust the endsystem entropy or you don't. Joe From nobody Fri Feb 5 07:34:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608E81B3A9B for ; Fri, 5 Feb 2016 07:34:55 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHP5v-BAdeec for ; Fri, 5 Feb 2016 07:34:53 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22D31B3929 for ; Fri, 5 Feb 2016 07:34:52 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15FYm4c065355 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 15:34:50 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4C117.1030101@foobar.org> Date: Fri, 05 Feb 2016 15:34:47 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> In-Reply-To: <56B4B81E.6080904@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:34:55 -0000 Joe Touch wrote: > So there's no reason to worry about EHs for this issue. Either you trust > the endsystem entropy or you don't. You're misunderstanding what I'm saying, which is that having a flow label field doesn't obviate the requirement for core boxes to pull entropy from the normal src/dst ip/port n-tuples. If there are EHs in a packet, fallback to using only the flow label is probably then not a good idea. Nick From nobody Fri Feb 5 07:35:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D141B3AA3 for ; Fri, 5 Feb 2016 07:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjkNa-gZ3cFE for ; Fri, 5 Feb 2016 07:35:49 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 DE0691B3A89 for ; Fri, 5 Feb 2016 07:35:48 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id d63so132233625ioj.2 for ; Fri, 05 Feb 2016 07:35:48 -0800 (PST) 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-type; bh=aMlqNBurnFMcC/KthQkO/0zr29cczj+JXqIfhxRp90A=; b=T6lWp11QT1VqCi1BLRzCY2XezlfQ4aLHoJZUfRbUXLgl6cNPgLTUiGhAvr5KolDxx9 SQsGFSlzgRognYe1aHCnuLUx8hFi+pcebnZ5ceEmTlstsXU43LlxaIqDPs4bYPLBW9w7 wQ7qKVQDpcnWK4DW8IVhfl3j1moOZ3l8N3+I4gshBnJxR4BXJAFuqn4jdYt/aEUl8NYA nyvcMY38Ut4UU78CsZojDbV6z91DHHZxSMW2IIJKSSLSs9drQfNebmGig4p8j3ot6o+9 bCK/SpLBopOGW+38lD86Q/gVTyCyxsA+1uJ3y4F2hGRrAUcyXlB2h6AXRI6+tTAToLkU Qprw== 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-type; bh=aMlqNBurnFMcC/KthQkO/0zr29cczj+JXqIfhxRp90A=; b=N6SUXE3zG3gFqVwotORLMcPvK5Eg66lfyP7PPhCA9NdOLpvPdqNjVxen/LDA/cl1p0 qm0vbuBIyO9JuYiMndJMG/hUfgiDcnN2D0jbgBXti/KQTeT53Km0owfIXWQjPWRyXYsk JEgCdhVro0PzSoWuNtMH5ddpuXAcZPnPF+ISuhQ/QitwG+2jTnhuIoNRtCcoP8JZ3JS9 Wx8hDKZfHS+Y3gsnprdz1drMStWOcj4VJJ+GYSndaWZ0yX5Ew52eXk+TSkwhE6wkF+ZA eaD/TbV2UopvHxRSwPe6UTjLoNJCASBxoZNrKHR0LSe9z5lBj7oUCylm5ZqA+ibnL6pP B9Lg== X-Gm-Message-State: AG10YOSLm3+TdP5e/DH1MAPgGKJHrbBdrMGR8ziiCH83AqUXGJlWMm41otNrdyhrPYUYWgPH04Xmlimg5veehQ== MIME-Version: 1.0 X-Received: by 10.107.138.203 with SMTP id c72mr13105364ioj.107.1454686548132; Fri, 05 Feb 2016 07:35:48 -0800 (PST) Received: by 10.107.160.203 with HTTP; Fri, 5 Feb 2016 07:35:48 -0800 (PST) In-Reply-To: <56B4B81E.6080904@isi.edu> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> Date: Fri, 5 Feb 2016 07:35:48 -0800 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:35:50 -0000 On Fri, Feb 5, 2016 at 6:56 AM, Joe Touch wrote: > > > On 2/5/2016 5:07 AM, Nick Hilliard wrote: >> Fernando Gont wrote: >>> * Address Brian Carpenter's comments regarding the Flow Label >> >> the flow label is more nuanced than it looks. >> >> If you're load balancing traffic via LAG or ECMP, you need a consistent >> source of flow based entropy which can be determined from an individual >> packet so that you can build up a hash key which will allow the router >> to send packets belonging to same flow down the same bearer link in a >> bundle. Routers need to do this because if you end up with >> out-of-sequence packet delivery, performance will drop considerably. >> >> The problem with the ipv6 flow label spec is that it does not affect how >> either the source or the destination handles an individual flow. This >> means that an ipv6 source host can set a flow label to be any value >> without affecting how the destination host will handle the value. The >> problem is that the flow label is expected to influence how intermediate >> routers process the packet, in particular which bearer links they might >> choose in a bundle. >> >> In other words, because the end hosts can control the flow label >> arbitrarily, control of LAG/ECMP hashing is substantially put in the >> hands of the end hosts, rather than the network operator. This is the >> case because the end hosts can tune the LAG/ECMP hash value without >> affecting any other characteristics of a particular data flow. This >> strikes me as being a poor idea. >> >> The relevance of this to draft-gont-v6ops-ipv6-ehs-packet-drops is that >> it means that it's a particularly bad idea to depend on the flow label >> as the sole source of entropy for LAG / ECMP hashing. This in turn >> means that it would be advisable to depend on other consistent entropy >> sources (e.g. the normal 5-tuples). These can only easily be determined >> if the ipv6 header doesn't contain EHs. > > Why do you think that any other endpoint assigned values in these > 5-tuples would not have the same problems as the flow label? I.e., > either they have no entropy (fixed per host) or are assigned within the > host in a way that might not optimize entropy at all. > > So there's no reason to worry about EHs for this issue. Either you trust > the endsystem entropy or you don't. > +1 The flow label used for ECMP is critical for us moving forward. Use of the 5-tuple restricts us to a using a small handful of protocols that the intermediate network HW arbitrarily decides is worth supporting, which seems to just be UDP/IP and TCP/IP with no IP options or ext. hdrs. Using flow label for ECMP is a big step in the battle against protocol ossification. With IPv6 flow label devices don't need to parse beyond the IP header just to switch packets. This means we can deploy any protocol or protocol feature we want and still get the value of flow based ECMP if the end host sets the flow label accordingly (which is already the default in OSes). It has the additional advantage that we can change the flow label for a flow that is having problems to try to get a better route through the network. Tom > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 5 07:40:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5173A1B3AB7 for ; Fri, 5 Feb 2016 07:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP4q_n1yGN8X for ; Fri, 5 Feb 2016 07:40:44 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41401B3AB8 for ; Fri, 5 Feb 2016 07:40:43 -0800 (PST) Received: from [192.52.179.108] (dc108.internet2.edu [192.52.179.108]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u15Fdjaf017763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 07:39:55 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> From: Joe Touch Message-ID: <56B4C23E.50302@isi.edu> Date: Fri, 5 Feb 2016 07:39:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4C117.1030101@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:40:45 -0000 On 2/5/2016 7:34 AM, Nick Hilliard wrote: > Joe Touch wrote: >> So there's no reason to worry about EHs for this issue. Either you trust >> the endsystem entropy or you don't. > > You're misunderstanding what I'm saying, which is that having a flow > label field doesn't obviate the requirement for core boxes to pull > entropy from the normal src/dst ip/port n-tuples. If there are EHs in a > packet, fallback to using only the flow label is probably then not a > good idea. If you're saying "the 5 tuple adds more entropy than is available in the flow label", maybe or maybe not. It depends on how the flow label is assigned. IMO, it's not worth the risk and effort of digging out the 5-tuple for this potential increase. (risk = brittleness, e.g., won't work when payloads are eventually all encrypted). Joe From nobody Fri Feb 5 07:47:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22B41B3AC6 for ; Fri, 5 Feb 2016 07:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crNY2u6WH0I4 for ; Fri, 5 Feb 2016 07:47:25 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 EF71E1B3ACE for ; Fri, 5 Feb 2016 07:47:24 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C457D62C8F for ; Fri, 5 Feb 2016 16:47:22 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8506D62C82 for ; Fri, 5 Feb 2016 16:47:22 +0100 (CET) Received: (qmail 74682 invoked by uid 1007); 5 Feb 2016 16:47:22 +0100 Date: Fri, 5 Feb 2016 16:47:22 +0100 From: Gert Doering To: Joe Touch Message-ID: <20160205154722.GQ58491@Space.Net> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B4B81E.6080904@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:47:27 -0000 Hi, On Fri, Feb 05, 2016 at 06:56:30AM -0800, Joe Touch wrote: > So there's no reason to worry about EHs for this issue. Either you trust > the endsystem entropy or you don't. There's more than one end system out there. Nothing can stop them from all using the same flow label value, like "0", but at least one part of the 5-tuple *will* differ for different senders. Just sayin' Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Feb 5 07:52:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65891B3AD5 for ; Fri, 5 Feb 2016 07:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP1_uuB_46KI for ; Fri, 5 Feb 2016 07:52:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FEE1B3AEB for ; Fri, 5 Feb 2016 07:52:30 -0800 (PST) Received: from [192.52.179.108] (dc108.internet2.edu [192.52.179.108]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u15Fq9rd026560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 07:52:11 -0800 (PST) To: Gert Doering References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> From: Joe Touch Message-ID: <56B4C527.1040600@isi.edu> Date: Fri, 5 Feb 2016 07:52:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160205154722.GQ58491@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:52:33 -0000 On 2/5/2016 7:47 AM, Gert Doering wrote: > Hi, > > On Fri, Feb 05, 2016 at 06:56:30AM -0800, Joe Touch wrote: >> So there's no reason to worry about EHs for this issue. Either you trust >> the endsystem entropy or you don't. > > There's more than one end system out there. > > Nothing can stop them from all using the same flow label value, like "0", > but at least one part of the 5-tuple *will* differ for different senders. The only thing you know will differ is the IP address pair (as a tuple). The rest might or might not. That argues for flowlabel + IPaddrs and just that. Digging deeper to get to transport protocol and corresponding port numbers seems like a lot of work for unpredictable benefit. Joe From nobody Fri Feb 5 08:22:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0815E1B3B0D for ; Fri, 5 Feb 2016 08:22:18 -0800 (PST) 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 Received: 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-LcQkC_n8Sf for ; Fri, 5 Feb 2016 08:22:16 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579E21B3B0C for ; Fri, 5 Feb 2016 08:22:15 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15GMCg0067602 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 16:22:12 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4CC33.9020702@foobar.org> Date: Fri, 05 Feb 2016 16:22:11 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> In-Reply-To: <56B4C23E.50302@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:22:18 -0000 Joe Touch wrote: > IMO, it's not worth the risk and effort of digging out the 5-tuple for > this potential increase. (risk = brittleness, e.g., won't work when > payloads are eventually all encrypted). As Gert suggested, flow labels are often set to zero by default. It's not helpful when your entropy source is constant across flows. Nick From nobody Fri Feb 5 08:29:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3395B1B3B40 for ; Fri, 5 Feb 2016 08:29:23 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seLiNDZ9yNbx for ; Fri, 5 Feb 2016 08:29:21 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8415C1B3B2C for ; Fri, 5 Feb 2016 08:29:21 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15GTJbw067795 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 16:29:19 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4CDDD.9080006@foobar.org> Date: Fri, 05 Feb 2016 16:29:17 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> In-Reply-To: <56B4C527.1040600@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:29:23 -0000 Joe Touch wrote: > The only thing you know will differ is the IP address pair (as a tuple). > The rest might or might not. > > That argues for flowlabel + IPaddrs and just that. > > Digging deeper to get to transport protocol and corresponding port > numbers seems like a lot of work for unpredictable benefit. Having had to deal extensively with lag/ecmp problems on large public production networks, I'm going to politely disagree with you. Nick From nobody Fri Feb 5 08:34:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863D61B31EE for ; Fri, 5 Feb 2016 08:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH-0YhNM_Lva for ; Fri, 5 Feb 2016 08:34:09 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 883351B317F for ; Fri, 5 Feb 2016 08:34:09 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id 5so17602009igt.0 for ; Fri, 05 Feb 2016 08:34:09 -0800 (PST) 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-type; bh=tMBbCqLLkf8iZzn0I657fsQMkyQ6q+gQVcPWqq5b4ro=; b=tv8z7W4JLTUTs2iVCO/0gW0bVuIAdPnQtCUfMfT0fuSBadU/BAltEdkJrfn6Wn26GK YnPXsuXVZVCXm7tzE01hcHwSZEOQ7xgJmGUuwVXcA1GYEpFVUn90zd7mXTvHWFj6dHOC QxSLFoH7/qWHSc/jYtfFxcsUKXWXZ+Zsywcl5kJkDRpCDQWmS+FjPr9+di8kdr9n1/pU GeY1CcgcyM1mGez5o3fQSpPrOXfSNbMJ2Rp+U/lE83rX0jhnSDgKRa0/4XpdwA4tvYVe 9BrR88GaZPeM5Z0O0hDxzf/1GJ/BSRlI5fMF9Rgu7Qg1pQdt0IJkWAI2WQysIgcAOV5v e/iQ== 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-type; bh=tMBbCqLLkf8iZzn0I657fsQMkyQ6q+gQVcPWqq5b4ro=; b=Is5mH+5MdtglR9RvP+h64ul1psSjlZdMjPvANcTFfADBpuaKzmiaTeGZmZCd/j4jhs x9LtQs7OwL1MaqGtk7nyuDgvemZ8TtypBQQWq406JNZeZeQ/MOcQmgkV3YC9sGRXqSRi OrmJFbcNwk8oGmySUB7J7iBPQ73JDvg4HZI0jlA022P/pjgsrjmLxluU4y7ZbP5zqbbw sNj4ogiHzG8TPzP05WaGKsUNAL2uR3sihKU+41m3HAKpiChfERQ2SoE1W4ywXPsAcQIy f/bZ+h0wndPgoGbHOqj/1nbfy43AyeRRVY/GxMP5cpkW7SN0ZWatpaM0xusZU6pouvUK kMJQ== X-Gm-Message-State: AG10YOShk9W2sB/UAUsrPemcVefesdJZ1KjdvO33ZdG8kwk5QHNAOLbX2GV9GBei0jc5Hg5bVvcy7SlfDV9RAA== MIME-Version: 1.0 X-Received: by 10.50.117.33 with SMTP id kb1mr16736498igb.89.1454690048833; Fri, 05 Feb 2016 08:34:08 -0800 (PST) Received: by 10.107.160.203 with HTTP; Fri, 5 Feb 2016 08:34:08 -0800 (PST) In-Reply-To: <56B4CC33.9020702@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> Date: Fri, 5 Feb 2016 08:34:08 -0800 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:34:10 -0000 On Fri, Feb 5, 2016 at 8:22 AM, Nick Hilliard wrote: > Joe Touch wrote: >> IMO, it's not worth the risk and effort of digging out the 5-tuple for >> this potential increase. (risk = brittleness, e.g., won't work when >> payloads are eventually all encrypted). > > As Gert suggested, flow labels are often set to zero by default. It's > not helpful when your entropy source is constant across flows. > The 3-tuple is still usable. This situation is not different than device trying to switch a packet with a transport protocol it can't parse where the fallback is just to use 3-tuple. Besides that, default for IOS and now Linux will be to set the flow label to non-zero based on a hash of the transport flow (I haven't looked into other OSes). Tom > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 5 08:47:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D31B3B63 for ; Fri, 5 Feb 2016 08:47:06 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myt7BP6Obbk8 for ; Fri, 5 Feb 2016 08:47:05 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7F31B3B62 for ; Fri, 5 Feb 2016 08:47:04 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15GkvNr068280 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 16:46:57 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4D200.1040105@foobar.org> Date: Fri, 05 Feb 2016 16:46:56 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:47:07 -0000 Tom Herbert wrote: > The 3-tuple is still usable. unless the flow label is set, the 3-tuple will just be a src/dst ip tuple, and load balancing on src/dst ip is, in my experience, useless. There is no guarantee that a flow label will be set. Nick From nobody Fri Feb 5 08:50:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6751B3B63 for ; Fri, 5 Feb 2016 08:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOdcQy8ZodJe for ; Fri, 5 Feb 2016 08:50:54 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735051B3B60 for ; Fri, 5 Feb 2016 08:50:54 -0800 (PST) Received: from [192.168.1.158] (washington-campus-1.internet2.edu [192.52.179.14]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u15GntLd012600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 08:50:07 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> From: Joe Touch Message-ID: <56B4D2B2.4020206@isi.edu> Date: Fri, 5 Feb 2016 08:49:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4CDDD.9080006@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:50:55 -0000 On 2/5/2016 8:29 AM, Nick Hilliard wrote: > Having had to deal extensively with lag/ecmp problems on large public > production networks, I'm going to politely disagree with you. I don't think it's useful to make recommendations even if they're based on existing practice when we see it sunsetting fairly soon - either because of network-layer encryption, tunnels, etc. Joe From nobody Fri Feb 5 08:55:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661B1B3B86 for ; Fri, 5 Feb 2016 08:55:14 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRJpNGkuuY0U for ; Fri, 5 Feb 2016 08:55:08 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B201B3B82 for ; Fri, 5 Feb 2016 08:55:08 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15Gt5ND068518 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 16:55:06 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4D3E8.7050706@foobar.org> Date: Fri, 05 Feb 2016 16:55:04 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> In-Reply-To: <56B4D2B2.4020206@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:55:14 -0000 Joe Touch wrote: > I don't think it's useful to make recommendations even if they're based > on existing practice when we see it sunsetting fairly soon - either > because of network-layer encryption, tunnels, etc. It's not clear what practices/protocols you're referring to when you say sunsetting? Nick From nobody Fri Feb 5 09:01:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6E1B3BA3 for ; Fri, 5 Feb 2016 09:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUp4dGzpq8B5 for ; Fri, 5 Feb 2016 09:01:31 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6A11B3B9F for ; Fri, 5 Feb 2016 09:01:31 -0800 (PST) Received: from [192.168.1.158] (washington-campus-1.internet2.edu [192.52.179.14]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u15H0kpe009114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 09:00:48 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> From: Joe Touch Message-ID: <56B4D539.4010007@isi.edu> Date: Fri, 5 Feb 2016 09:00:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4D3E8.7050706@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:01:33 -0000 On 2/5/2016 8:55 AM, Nick Hilliard wrote: > Joe Touch wrote: >> I don't think it's useful to make recommendations even if they're based >> on existing practice when we see it sunsetting fairly soon - either >> because of network-layer encryption, tunnels, etc. > > It's not clear what practices/protocols you're referring to when you say > sunsetting? DPI to extract transport context for entropy inside the network. Joe From nobody Fri Feb 5 10:08:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463481A6FA8 for ; Fri, 5 Feb 2016 10:08:11 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4ErIYA5gpQZ for ; Fri, 5 Feb 2016 10:08:10 -0800 (PST) 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 0FFFA1A1A8B for ; Fri, 5 Feb 2016 10:08:10 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 24748206AF1; Fri, 5 Feb 2016 19:08:05 +0100 (CET) To: Joe Touch , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> From: Fernando Gont Message-ID: <56B4E4FD.7010608@si6networks.com> Date: Fri, 5 Feb 2016 15:07:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4D539.4010007@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:08:11 -0000 On 02/05/2016 02:00 PM, Joe Touch wrote: > > > On 2/5/2016 8:55 AM, Nick Hilliard wrote: >> Joe Touch wrote: >>> I don't think it's useful to make recommendations even if they're based >>> on existing practice when we see it sunsetting fairly soon - either >>> because of network-layer encryption, tunnels, etc. >> >> It's not clear what practices/protocols you're referring to when you say >> sunsetting? > > DPI to extract transport context for entropy inside the network. I've seen increased deployment of *TLS*... but TLS still allows you to extract the transport-related information.... Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 5 11:02:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216391A8796 for ; Fri, 5 Feb 2016 11:02:07 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3KVOO_CrZ2Z for ; Fri, 5 Feb 2016 11:02:04 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635541A8830 for ; Fri, 5 Feb 2016 11:02:03 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15J20Pl071783 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 19:02:00 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B4F1A6.7080402@foobar.org> Date: Fri, 05 Feb 2016 19:01:58 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> In-Reply-To: <56B4D539.4010007@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 19:02:07 -0000 Joe Touch wrote: > On 2/5/2016 8:55 AM, Nick Hilliard wrote: >> Joe Touch wrote: >>> I don't think it's useful to make recommendations even if they're based >>> on existing practice when we see it sunsetting fairly soon - either >>> because of network-layer encryption, tunnels, etc. >> It's not clear what practices/protocols you're referring to when you say >> sunsetting? > > DPI to extract transport context for entropy inside the network. If you're referring to IPsec when you say "network layer encryption", I haven't noticed any proportional increase as a long term trend. It's still rarely more than line noise in almost all situations. As Fernando mentioned, TLS usage has increased substantially as a percentage of overall tcp flows, but that doesn't impact load balancing because it allows extraction of L4 n-tuples in the same way as if the traffic were unencrypted. Tunnels other than ipsec tunnel mode exist, but are in the minority in terms of overall traffic flows on the internet. I don't see any prospect of sunsetting inspection of layer 4 info on the basis of your suggestions, even in the long term as a potential possibility. Nick From nobody Fri Feb 5 11:03:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738921A8830 for ; Fri, 5 Feb 2016 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj8rzCEUGP2y for ; Fri, 5 Feb 2016 11:03:50 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 15CDB1A87D5 for ; Fri, 5 Feb 2016 11:03:49 -0800 (PST) Received: (qmail 3309 invoked from network); 5 Feb 2016 19:03:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Feb 2016 19:03:48 -0000 Date: Fri, 05 Feb 2016 20:03:48 +0100 (CET) Message-Id: <20160205.200348.74751017.sthaug@nethelp.no> To: fgont@si6networks.com From: sthaug@nethelp.no In-Reply-To: <56B4E4FD.7010608@si6networks.com> References: <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4E4FD.7010608@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 19:03:52 -0000 > >>> I don't think it's useful to make recommendations even if they're based > >>> on existing practice when we see it sunsetting fairly soon - either > >>> because of network-layer encryption, tunnels, etc. > >> > >> It's not clear what practices/protocols you're referring to when you say > >> sunsetting? > > > > DPI to extract transport context for entropy inside the network. > > I've seen increased deployment of *TLS*... but TLS still allows you to > extract the transport-related information.... I think "fairly soon" needs to be defined. I believe extracting entropy from address and port numbers will continue to be used at least as long as we have a significant amount of IPv4 traffic. Steinar Haug, AS 2116 From nobody Fri Feb 5 11:41:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645861A8F40 for ; Fri, 5 Feb 2016 11:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV7JY6cXiRUz for ; Fri, 5 Feb 2016 11:41:47 -0800 (PST) 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 EEA501A8EA9 for ; Fri, 5 Feb 2016 11:41:46 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id uo6so39533008pac.1 for ; Fri, 05 Feb 2016 11:41:46 -0800 (PST) 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-type :content-transfer-encoding; bh=WUUwKw9yDuBUkqE+GR7Mq7O2DXRsZuaD/90cPDVnB4Y=; b=iAsZ8bAgq1QyFPC9lVMJh/+lq+n1jQ0GhaRuh0b7KgKWTt+lGErfqkRM/ogcQ6LBQs Ngrh/Se4F0k2R1WzlnuZpIdfXDwu8wqOcUPwaDvHCOfxcehLiF0R2FaPyiLx+XVVLlVL zBIrVfMFRHLMpLpzcAJdY8hI96ZQkEy3sm2eKhZ3dxgSvYwpzUPuO3HaRflsTPrc71Nq q0E3+077oZ57EJBS9VMcxW0QUF4zFGZHAwgkhozdPmr/m/wOmxD6BijcD5754MXlbCQe 0RDr8M58szTqRWNpktZMo8VV06B6YdYQVLm2buJwFjSAiWFneSPEEnqlzymBIEgGEUF2 zYyA== 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-type :content-transfer-encoding; bh=WUUwKw9yDuBUkqE+GR7Mq7O2DXRsZuaD/90cPDVnB4Y=; b=DuVcOeofPeqX8YqzBArcARPdhhZD0LsPEnk0AJ9lFdTeZH0ZXwNNpoIHhjeIYCJmVx 7P3y+ePqCln6khv35OiV0fdliWOFWDKG5OkC1QZr/axMu+wyZLlL7+6yyxaGT2Xjiv2x giEJdMr68mceNyfoSKEAoT20B+fIN8fa7mVIckRAKJyXGfApgjgBLF3dY2CyQeOeaAaf 4oAxtp7HRdyuNVsbJJv99FpTcv+lUiQnR2lg/HwvhmwGnUhJbqCsbnx2C7yHWzoumtjI CnsCoIkKRK+1my9M9goq/MzjSL5UAd0OnctOaslG3ndbMr0hmqzvp5oBktnPUJ9Xlu+J 4Heg== X-Gm-Message-State: AG10YOSo5336/xF0IbKgr8/iMwXkgqf+0/v4AMWhni7glMxQjv3mDntk29AZEOHtWnBSHQ== X-Received: by 10.66.139.134 with SMTP id qy6mr22316069pab.45.1454701306644; Fri, 05 Feb 2016 11:41:46 -0800 (PST) Received: from ?IPv6:2406:e007:4357:1:28cc:dc4c:9703:6781? ([2406:e007:4357:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n4sm26354462pfi.3.2016.02.05.11.41.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 11:41:44 -0800 (PST) To: Nick Hilliard , Tom Herbert References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B4FB01.8040401@gmail.com> Date: Sat, 6 Feb 2016 08:41:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4D200.1040105@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 19:41:48 -0000 On 06/02/2016 05:46, Nick Hilliard wrote: > Tom Herbert wrote: >> The 3-tuple is still usable. > > unless the flow label is set, the 3-tuple will just be a src/dst ip > tuple, and load balancing on src/dst ip is, in my experience, useless. Really, with IPv6 addresses? There tends to be a fair amount of entropy in the bottom 64 bits of the client address. With the 5-tuple, all you really gain is the entropy in the ephemeral port number. Adding a well-known port to the hash doesn't help much. > There is no guarantee that a flow label will be set. That's true, although we have changed the standard to make it more likely that future stacks will do so. But the thing is, what else are you going to do to help load balancing in the case that the transport header is inaccessible? What do you lose in that case by adding the flow label to the hash? If it's zero, the hash doesn't get worse. If it's been set according to RFC6437, the hash gets better. (I'm assuming that we aren't talking about the RFC6438 scenario.) Brian From nobody Fri Feb 5 12:01:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4835C1ACDF3 for ; Fri, 5 Feb 2016 12:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAApC6_aI1fn for ; Fri, 5 Feb 2016 12:01:24 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 136731ACE03 for ; Fri, 5 Feb 2016 12:01:12 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id 9so140797416iom.1 for ; Fri, 05 Feb 2016 12:01:12 -0800 (PST) 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-type; bh=jpdgFDpPUXEE2qT9OmB1ycAM/kk0mYpicSCFagSAMkE=; b=X2WfUOivGehY6a+WDuu5QO27Dh8uVMNa+jMPtPG2WWgQTK241vGLoTY0cAejPQClVK 9E6awbsDj6Q/EoCIHrtDCNHOpFszaGg6HdTgHa9B/kqnwOs+dTEBUqhQDnB3npLFp+t2 /bu3y2HDfOeOJ9aZINz2GVeDKfVq+f1G2KymGwxWjDZTSdSB9aiFHqHBO84SBmtiUhZW g4zsicpgBg1z1WP1iqqfHwUcTFTPv5pgyn0ooo84g0pcPq/Qgs1ByPjNb8IOrGiNSKqx KJn8prypgxdMZIVF8/H5cIHkALeuS8bCaKqIpyFjhIYx/fv0yiT/CVphQdM9Ow/4rHgb tGqg== 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-type; bh=jpdgFDpPUXEE2qT9OmB1ycAM/kk0mYpicSCFagSAMkE=; b=YfHnpj2pvIekVGpmKWDU/Gj5RVmS4wlThdf//mHKW4VzH7A+5M2pk2FxjZlxxJBDx/ 1Qezw7SbERBKy4XfvesLaOirACPhc6ElPeuKndWEPASPDSzQkaewBVd8ZbfnWK153Y+s v/lpnrkeMNR7KC0dPwRdAC1mi2WQqoE3Knii3QTcmn6Sx2CF5um2zpJQlG3NfTgJc3UM ZBPLcFM8f/2+SkMNxzFTvRkTObttHDFWjnW1hguTss1ZAC8W8vvkRv6JI7MLo0qxevKu UdCw0udF4zSNJmmQtVfvHkZ6375vGkMxp6w4+clV5fWR6FpT45pbn3vqwJOhdlvgAdRS lSfw== X-Gm-Message-State: AG10YOTZ9F+6/VjNr2bHDmEjc46Xolpv6Ahx9lEX2W5V2PUmQ3rPNUei81AU1KBvrewHd6NnxIB7sRKAMaR2yw== MIME-Version: 1.0 X-Received: by 10.107.138.203 with SMTP id c72mr14418621ioj.107.1454702471401; Fri, 05 Feb 2016 12:01:11 -0800 (PST) Received: by 10.107.160.203 with HTTP; Fri, 5 Feb 2016 12:01:11 -0800 (PST) In-Reply-To: <56B4FB01.8040401@gmail.com> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> Date: Fri, 5 Feb 2016 12:01:11 -0800 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:01:25 -0000 On Fri, Feb 5, 2016 at 11:41 AM, Brian E Carpenter wrote: > On 06/02/2016 05:46, Nick Hilliard wrote: >> Tom Herbert wrote: >>> The 3-tuple is still usable. >> >> unless the flow label is set, the 3-tuple will just be a src/dst ip >> tuple, and load balancing on src/dst ip is, in my experience, useless. > > Really, with IPv6 addresses? There tends to be a fair amount of entropy > in the bottom 64 bits of the client address. > > With the 5-tuple, all you really gain is the entropy in the ephemeral port > number. Adding a well-known port to the hash doesn't help much. > >> There is no guarantee that a flow label will be set. > > That's true, although we have changed the standard to make it more likely > that future stacks will do so. > > But the thing is, what else are you going to do to help load balancing in > the case that the transport header is inaccessible? What do you lose in that > case by adding the flow label to the hash? If it's zero, the hash doesn't get > worse. If it's been set according to RFC6437, the hash gets better. > > (I'm assuming that we aren't talking about the RFC6438 scenario.) > RFC6438 is very relevant to this discussion! There is no standard way to deduce a 5-tuple hash for an encapsulated flow in encapsulation protocols (GRE, MPLS, IPIP, IPsec, etc.) and in this case the addresses don't contain any entropy about the flows going over the tunnel. We really only have two options to get flow based ECMP with encapsulation: 1) foo-over-UDP encapsulation or 2) Flow labels. UDP encapsulation "works" but adds yet another layer, complexity, and byte overhead and doesn't help to solve the EH problem anyway. Flow labels are really the best solution once you're on IPv6. Tom > Brian > From nobody Fri Feb 5 12:40:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF21ACEE0 for ; Fri, 5 Feb 2016 12:40:29 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS8p0_m4BOSE for ; Fri, 5 Feb 2016 12:40:27 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966A81ACEDE for ; Fri, 5 Feb 2016 12:40:26 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15KeDaI074168 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 20:40:14 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B508AC.60601@foobar.org> Date: Fri, 05 Feb 2016 20:40:12 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian E Carpenter References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> In-Reply-To: <56B4FB01.8040401@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:40:29 -0000 Brian E Carpenter wrote: > Really, with IPv6 addresses? There tends to be a fair amount of entropy > in the bottom 64 bits of the client address. that's not the point. If you depend solely on src/dst ip, all traffic flows between those two endpoints will be hashed over the same bundle member. This does two things: 1. it restricts the maximum bandwidth between those two hosts to the amount of free bandwidth on the bundle member in question and 2. it trashes the link for other people, potentially causing performance problems. If you add in a flow label as an entropy source, it may change the hash on a per stream basis, but only if the end-point operating system has set the flow label to be nonzero. This is not guaranteed to happen because the flow label plays no part in the transmission mechanism between the two end points, only on the intermediate path elements of the transmission. I.e. from the point of view of an end point, it's unnecessary. > That's true, although we have changed the standard to make it more likely > that future stacks will do so. it's well established that changing the standard doesn't necessarily change the implementations. It would be good to have recent data on this - the most recent formal paper I've seen on this dates from 2005 which is way too old (http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf) Nick From nobody Fri Feb 5 12:40:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3691ACEE6 for ; Fri, 5 Feb 2016 12:40:39 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gH6YXBZ1cGk for ; Fri, 5 Feb 2016 12:40:38 -0800 (PST) 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 A7D781ACEEA for ; Fri, 5 Feb 2016 12:40:38 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 68EB3206A2B; Fri, 5 Feb 2016 21:40:29 +0100 (CET) To: sthaug@nethelp.no References: <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4E4FD.7010608@si6networks.com> <20160205.200348.74751017.sthaug@nethelp.no> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B50759.1080109@si6networks.com> Date: Fri, 5 Feb 2016 17:34:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160205.200348.74751017.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:40:40 -0000 On 02/05/2016 04:03 PM, sthaug@nethelp.no wrote: >>>>> I don't think it's useful to make recommendations even if they're based >>>>> on existing practice when we see it sunsetting fairly soon - either >>>>> because of network-layer encryption, tunnels, etc. >>>> >>>> It's not clear what practices/protocols you're referring to when you say >>>> sunsetting? >>> >>> DPI to extract transport context for entropy inside the network. >> >> I've seen increased deployment of *TLS*... but TLS still allows you to >> extract the transport-related information.... > > I think "fairly soon" needs to be defined. I believe extracting > entropy from address and port numbers will continue to be used at > least as long as we have a significant amount of IPv4 traffic. just curious: why do you think IPv6 would make a different in this respect? -- because extracting such information can be difficult and hence everyone would shift to employing the flow-label, or something else? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 5 14:25:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843431B2E3C for ; Fri, 5 Feb 2016 14:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASVW4HWojCq6 for ; Fri, 5 Feb 2016 14:25:05 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 E06371B2E39 for ; Fri, 5 Feb 2016 14:25:04 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id cy9so40834796pac.0 for ; Fri, 05 Feb 2016 14:25:04 -0800 (PST) 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-type :content-transfer-encoding; bh=NVwPWeIuwJCHaeBxiXbd9mQxBfqFn1iGSUlMtKAxeOs=; b=vgsJelWp+fmOzFDw73QRRyk+QBnbZSglqUOqhx9zYZJs1/KTodQx+dVLeiTGempL8q ARO+yZqHi1/3gTbHMPbZQ0EDjfdbg6vBU8yChgrMaJLvp3XCl4xs3dNY2MkYUpgdzzUl PVtMkJfwdIsCkY1mC11a9MtPmnxr2Fm6+mpDR/gWzf/H3vcz6DlP4K6HUDHauUBcyBq/ qJx4Nlco30YzHcmEMPoKeYU/nT468Eh27ZcUdqkyfZpHBRRtUwaI+eoqap1K6pdeV3J8 AtNoWRvgyGArt/VHqRZr3c7eHrGMY1UdM/rr9XcAQmFomzcPBn/kiPr7nn3LpQj6NjXu XkVQ== 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-type :content-transfer-encoding; bh=NVwPWeIuwJCHaeBxiXbd9mQxBfqFn1iGSUlMtKAxeOs=; b=il2ClNW9OGLBzqlgVlsfoV9T/yzFZFT64KHLCSffKow91IPfeXFs8GcWa9eT1wWvMs i5JivpZtNRricaoL1VNREQIz6WaLDBhwcKb+RSdUhk1pJ3mtCNBA9aqfwBEhA2C2Bd09 db+q2kqsxFWKKpt1E4mOuqqAbtfCPd+MbWz/+pc7WyrzB8Lx/M9G7rVR7VHAm1XvaemG s54cfge318xWf9XRpZxXwEaWzRZSzL96dJZs0B1VopRwQiW4OAfNcCqAcjR9k6HT5SRl +/Su+3u9D1U4iCE/yPToEeaCRLusizz5NAHN8im4Kr+eNR74oJucQGb8nMCLhgOLOPnS /HDg== X-Gm-Message-State: AG10YOQeksVSetFRvOEYMDLeh8dGJHkfKKMdZJTsHxVP1U4W/TjhCXDQlx7CanKiWdSySg== X-Received: by 10.66.63.8 with SMTP id c8mr6986216pas.147.1454711104547; Fri, 05 Feb 2016 14:25:04 -0800 (PST) Received: from ?IPv6:2406:e007:4357:1:28cc:dc4c:9703:6781? ([2406:e007:4357:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ze5sm26731743pac.32.2016.02.05.14.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 14:25:03 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> <56B508AC.60601@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B52147.7070502@gmail.com> Date: Sat, 6 Feb 2016 11:25:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B508AC.60601@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 22:25:06 -0000 On 06/02/2016 09:40, Nick Hilliard wrote: > Brian E Carpenter wrote: >> Really, with IPv6 addresses? There tends to be a fair amount of entropy >> in the bottom 64 bits of the client address. > > that's not the point. If you depend solely on src/dst ip, all traffic > flows between those two endpoints will be hashed over the same bundle > member. Which doesn't matter in the least if you have thousands of flows from hundreds of sources on the link. I agree that it matters if you have multiple flows from one particular bandwidth hog; things like GridFTP for example, which is designed to take an unfair share by grabbing multiple ports for one application flow. > This does two things: 1. it restricts the maximum bandwidth > between those two hosts to the amount of free bandwidth on the bundle > member in question and 2. it trashes the link for other people, > potentially causing performance problems. > > If you add in a flow label as an entropy source, it may change the hash > on a per stream basis, but only if the end-point operating system has > set the flow label to be nonzero. This is not guaranteed to happen > because the flow label plays no part in the transmission mechanism > between the two end points, only on the intermediate path elements of > the transmission. I.e. from the point of view of an end point, it's > unnecessary. > >> That's true, although we have changed the standard to make it more likely >> that future stacks will do so. > > it's well established that changing the standard doesn't necessarily > change the implementations. It would be good to have recent data on > this - the most recent formal paper I've seen on this dates from 2005 > which is way too old (http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf) Yes. It's 4 years since RFC6437 so it might almost be worth looking to see if things have changed. But this is a long game. Brian From nobody Fri Feb 5 14:41:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685981B2E50 for ; Fri, 5 Feb 2016 14:41:32 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp0JqICV7wxZ for ; Fri, 5 Feb 2016 14:41:30 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805A91B2E4A for ; Fri, 5 Feb 2016 14:41:30 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u15MfHnW077221 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2016 22:41:18 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B5250C.5010402@foobar.org> Date: Fri, 05 Feb 2016 22:41:16 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian E Carpenter References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> <56B508AC.60601@foobar.org> <56B52147.7070502@gmail.com> In-Reply-To: <56B52147.7070502@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 22:41:32 -0000 Brian E Carpenter wrote: > Which doesn't matter in the least if you have thousands of flows > from hundreds of sources on the link. in practice, it matters a great deal. 10G and 40G server connectivity is now commonplace. If your egress or core bundle members are of the same order of magnitude as your edge, this will create visible elephant flows in usage graphs. Nick From nobody Fri Feb 5 15:47:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF01B2FDC for ; Fri, 5 Feb 2016 15:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-qT-2Y3T-a5 for ; Fri, 5 Feb 2016 15:47:12 -0800 (PST) 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 0A5081B2FD8 for ; Fri, 5 Feb 2016 15:47:12 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id o185so76503307pfb.1 for ; Fri, 05 Feb 2016 15:47:12 -0800 (PST) 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-type :content-transfer-encoding; bh=TxUaiM4rHIfWvEHWvsjmqpbIAVnqRTWn9SAedoTG6os=; b=QJwRgTe00woHYFSGXZW2sKwU4q1QrcLwBOx4cf2P0LQW6qJ7i4zST2ij0Gk8co8xNM JV46dwrDOQxu4ozNzobeS0W75OCk9KFcC2lPNK/hinWzmI/SPYQD4I7gaasjmnE0hOW5 ZIMEucj0V+3QJxMzgSHFjTuRB4WWQeS46CKHwHXFlidf1DmcLpXYhCaoefJhz7HT2aj2 osBQLNnbbQgjiq1U7bAvDtdMPDNruSq6NAZSW9K+PyOzsHsSR//XEkDF3xba5crB00MD fU5yEFY13svmdtJJKBSfUd1ucC9V/ZsNNDtL2CpoDb26UD7gOMRjbG8eBbZuawoDJzeG MBAw== 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-type :content-transfer-encoding; bh=TxUaiM4rHIfWvEHWvsjmqpbIAVnqRTWn9SAedoTG6os=; b=b579My4mh5lM9b0/+hGfMhMHHxIaSh5Hr+XeqEysD+YZbPo3KR74tdBlVuiZFpnpS9 Tubc9XnZmHl1aCWaDcuJXfzZIa+r9wj3l6OYK0OURLnrz84vv4npnirEaHoEkOaAVG2w fIxRxxwpv/TfC8A1jWlJsnJERW1wdWhS1C/Pvhs3RVrtZb7hySlVa9LjVDtVxgaKlJyM LYUqTQNfYCXK6v8vOD2gEG0XGOZ+SJpvoBiocLPlTqSY9sfNGUF9IZ5K5U/4kBL2JgwP 2RcXZfC4HQC8TLPXzDgSMyFlNOpBx32o+07exUmcrcqxKHcWa5kyAbFBL0+skQ8cuFji vCBw== X-Gm-Message-State: AG10YOQFFE6NmMRqNy2wUu+AZMNBqcce/dTIhFFVZ6lP0oGY1SqkwUIi88HTYkAIhGzmKg== X-Received: by 10.98.18.215 with SMTP id 84mr23951246pfs.131.1454716031732; Fri, 05 Feb 2016 15:47:11 -0800 (PST) Received: from ?IPv6:2406:e007:4357:1:28cc:dc4c:9703:6781? ([2406:e007:4357:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v66sm21919116pfi.56.2016.02.05.15.47.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 15:47:10 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> <56B508AC.60601@foobar.org> <56B52147.7070502@gmail.com> <56B5250C.5010402@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B53486.60201@gmail.com> Date: Sat, 6 Feb 2016 12:47:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B5250C.5010402@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 23:47:13 -0000 On 06/02/2016 11:41, Nick Hilliard wrote: > Brian E Carpenter wrote: >> Which doesn't matter in the least if you have thousands of flows >> from hundreds of sources on the link. > > in practice, it matters a great deal. 10G and 40G server connectivity > is now commonplace. If your egress or core bundle members are of the > same order of magnitude as your edge, this will create visible elephant > flows in usage graphs. I completely understand that for IPv4 traffic, but this is about IPv6, where there are potentially 64 bits of entropy in the low-order bits of the address. The high-order address bits don't add much entropy. I'm not just saying that; it can be seen in the table headed Trace 4 in https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf, where the rows for Algorithms 2 and 6 are with and without the top 64 bits of the addresses. Brian From nobody Fri Feb 5 16:03:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0D1B3050 for ; Fri, 5 Feb 2016 16:03:05 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULW-x_zKY-6Q for ; Fri, 5 Feb 2016 16:03:04 -0800 (PST) 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 1CB951B304F for ; Fri, 5 Feb 2016 16:03:04 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:3166:f14:7911:ed6c]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1602phl058519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Feb 2016 00:02:52 GMT (envelope-from joelja@bogus.com) To: Brian E Carpenter , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> <56B508AC.60601@foobar.org> <56B52147.7070502@gmail.com> <56B5250C.5010402@foobar.org> <56B53486.60201@gmail.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56B5382A.9050206@bogus.com> Date: Fri, 5 Feb 2016 16:02:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <56B53486.60201@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qtg4hNmNlMV06oOrSsabbV4q5Gv7q1f6t" Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 00:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qtg4hNmNlMV06oOrSsabbV4q5Gv7q1f6t Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/5/16 3:47 PM, Brian E Carpenter wrote: > On 06/02/2016 11:41, Nick Hilliard wrote: >> Brian E Carpenter wrote: >>> Which doesn't matter in the least if you have thousands of flows >>> from hundreds of sources on the link. >> >> in practice, it matters a great deal. 10G and 40G server connectivity= >> is now commonplace. If your egress or core bundle members are of the >> same order of magnitude as your edge, this will create visible elephan= t >> flows in usage graphs. >=20 > I completely understand that for IPv4 traffic, but this is about IPv6, > where there are potentially 64 bits of entropy in the low-order bits > of the address. The high-order address bits don't add much entropy. today in my world we have polarization of flows between hosts talking to each other using 4 x 10Gbe nics on either end so oddly I don't see address entropy as enough ever... maybe source dest and flow label are enough if the latter is actually an entropy source. but the source/dest are not. > I'm not just saying that; it can be seen in the table headed Trace 4 > in https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf, where the rows= > for Algorithms 2 and 6 are with and without the top 64 bits of the > addresses. >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Qtg4hNmNlMV06oOrSsabbV4q5Gv7q1f6t 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 iEYEARECAAYFAla1OCoACgkQ8AA1q7Z/VrJ8NQCePCMkMl3VP+LjSMZr2Cv7Yak/ KLgAn3Hl9tfgg1WTrPGFvRr/CHI05IhE =yQpv -----END PGP SIGNATURE----- --Qtg4hNmNlMV06oOrSsabbV4q5Gv7q1f6t-- From nobody Fri Feb 5 16:19:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C841B30D5 for ; Fri, 5 Feb 2016 16:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3h-Rw2fDECI for ; Fri, 5 Feb 2016 16:19:24 -0800 (PST) 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 2E1DE1B30D4 for ; Fri, 5 Feb 2016 16:19:24 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id 9so146483564iom.1 for ; Fri, 05 Feb 2016 16:19:24 -0800 (PST) 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-type; bh=Cbhr5FoDOxdB45aUyoODIWA3UvSEAYCVBpbgCnaWXQQ=; b=Wfe1xa4HS1KeOvKq8iuEUpWFP2cFbMUG0th/bNPmTYMtD14m6sEJYR057TI7qae4FR hCsdUzsqQtWIr9DzaqDJv+EPLS9xyfSssYq0U/n0iTDfvomRGctf69oe/HfeRTEeezTL OjOqnGSeqP9vh/pN34QysAucz+YGisXHVs3jOqD0iHZUEOLueXSswLRgEyLsM38GE0I7 Inzm8LEpiyO7bV+P3XlIsrt5BMYoAduiOQl7xBuS6H3H/8019qvv8Bf4JziHlfRVr/+v Bcg4ckxLgrw4qD/rgNdricrpRciMc5va6wtsj9nkC3NO7NZtOpb/hX8lu4n09nfhWhdm klzQ== 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-type; bh=Cbhr5FoDOxdB45aUyoODIWA3UvSEAYCVBpbgCnaWXQQ=; b=ExDbFDKZkR+jxOkGr9/UyR53xs8kcviLK0dgSft0UYYAxWery5wvwJK709B1YGK0dr IHdfTqTrWeJHJvGFQJ4T3a/0SH7byWKw0FrtI1j9Fg9rQL8/aVqE4i5tsx45Pusc0gw7 SJlkfZU9v6RW1zXBA+WvM5IS4vCrza+mBlY4T077+Q5YUjYFdZtLocD7MJEjSNQGrZ3E tTqi3Wa8rROwCEI+T1Haa5UnazGFpRjwG3Z7oP/Em3RNyR0VSW6rD61LPMTDwWRvXjH0 OWK2/+CMQQcq1BlJT1exqiLY7XLqpZQs6O+DG3TebeL2nYM4ueC0CwTJyGHkvGow+j4N MIDQ== X-Gm-Message-State: AG10YOR6LxCN/NEhGheREyI8HdlFFWlORuPzzZVPDO+s7jKZ0ecNAZxmI9KgHP/07QZI9QkjlJ7ujYeXqKxMtg== MIME-Version: 1.0 X-Received: by 10.107.138.203 with SMTP id c72mr15439926ioj.107.1454717963625; Fri, 05 Feb 2016 16:19:23 -0800 (PST) Received: by 10.107.160.203 with HTTP; Fri, 5 Feb 2016 16:19:23 -0800 (PST) In-Reply-To: <56B4F1A6.7080402@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> Date: Fri, 5 Feb 2016 16:19:23 -0800 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 00:19:25 -0000 On Fri, Feb 5, 2016 at 11:01 AM, Nick Hilliard wrote: > Joe Touch wrote: >> On 2/5/2016 8:55 AM, Nick Hilliard wrote: >>> Joe Touch wrote: >>>> I don't think it's useful to make recommendations even if they're based >>>> on existing practice when we see it sunsetting fairly soon - either >>>> because of network-layer encryption, tunnels, etc. >>> It's not clear what practices/protocols you're referring to when you say >>> sunsetting? >> >> DPI to extract transport context for entropy inside the network. > > If you're referring to IPsec when you say "network layer encryption", I > haven't noticed any proportional increase as a long term trend. It's > still rarely more than line noise in almost all situations. > > As Fernando mentioned, TLS usage has increased substantially as a > percentage of overall tcp flows, but that doesn't impact load balancing > because it allows extraction of L4 n-tuples in the same way as if the > traffic were unencrypted. > > Tunnels other than ipsec tunnel mode exist, but are in the minority in > terms of overall traffic flows on the internet. > Then it's deadlock: we can't widely deploy protocols that are not well supported on the Internet, and protocols won't get proper support unless they are widely deployed. This is protocol ossification! Within the enterprise network this story is very different. Tunnels are quite common and we will be using EH as well as alternative transport protocols and flow labels really are the only feasible solution to get the necessary input entropy for ECMP for encapsulated flows. IMO support for using flow label for ECMP should now be considered a requirement for anyone selling networking gear to the enterprise. > I don't see any prospect of sunsetting inspection of layer 4 info on the > basis of your suggestions, even in the long term as a potential possibility. > It's not so much a question of sunsetting DPI, but enabling the use of flow labels in ECMP to cover use cases where DPI fails to find a 5-tuple (e.g. ext. hdrs., alternative transport protocols, encapsulation protocols). Tom > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 5 16:25:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30B1B30FC for ; Fri, 5 Feb 2016 16:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orMK4qu0rIzX for ; Fri, 5 Feb 2016 16:25:10 -0800 (PST) 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 AC0361B30FB for ; Fri, 5 Feb 2016 16:25:10 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id ho8so42009955pac.2 for ; Fri, 05 Feb 2016 16:25:10 -0800 (PST) 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-type :content-transfer-encoding; bh=/JAySsicaHehmBhGqfBKSC3lCCOj2fHGjcgIbdsLf+8=; b=qgQyJ2cforZznJ5GsQYxXaA2t+Mlu3vdEno+JS65XCLqD8T5vRTUJCOW+JehjJHGx4 vZoeByQI3S1ZR5cjZx3Ir4kOwZKIJxqF7sedj70H0Ff+kKLSM1sWI2IXDr88d3IpJSh5 lz1AFWpa2bNZRKCTqbrAEY97zyWloD+mBoLZXplS8+nUcpKaVXusNM+tU6BoGaGxAVKR 5ssNc/iilqgVRsqJBlz7ZSe0voKAFn4bEG1HV795LYFLIH5EaNYAg+EkIQB5Vc85jZgQ wsxW2sVUFDby9zEdjtsGYLmPRTwRcItGLPhc8Fj313xRil6UrqnZw+bG3xJUXLLgGyVU UJSg== 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-type :content-transfer-encoding; bh=/JAySsicaHehmBhGqfBKSC3lCCOj2fHGjcgIbdsLf+8=; b=U/vUpYnKjErJbaESaFzHhI0T9KHhxasa7AEJoXF9B+lyia0BJ1wjwvy+WlZ3ZhUhLR 1NlelL+osD1gk3Ynda7GBP8wLKIMTfTb2tXzyJ8OjvKOje8LKpeQVaWca3y2cLfjsScG fUHus697tiSjh/JpGmPHUzNs9Xyrxakp4EM2yphDGvRNFqnB9pNpQAoxuVQKtBfBjRgr 9H37Vxpze5j9O/68647c1jolFMiuJwdhds5Vob92/NdcGv+bzY/qVHN5RDNLCcJO/y2k SkcUglmar3qTWpJnRSl7XYx2U6ILjt/TKc0milpX97sja64tHgbSWjd7QBGFRoUz2Hll sbUw== X-Gm-Message-State: AG10YOSv6K9QU3l9Hv5rucXSjPg/ZP+6IiRkIGO6QBTRD6+pAnSDVNZwLTw4N62mAva4ZA== X-Received: by 10.66.235.162 with SMTP id un2mr23922717pac.17.1454718310341; Fri, 05 Feb 2016 16:25:10 -0800 (PST) Received: from ?IPv6:2406:e007:4357:1:28cc:dc4c:9703:6781? ([2406:e007:4357:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a21sm26989932pfj.40.2016.02.05.16.25.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 16:25:08 -0800 (PST) To: joel jaeggli , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <56B4C117.1030101@foobar.org> <56B4C23E.50302@isi.edu> <56B4CC33.9020702@foobar.org> <56B4D200.1040105@foobar.org> <56B4FB01.8040401@gmail.com> <56B508AC.60601@foobar.org> <56B52147.7070502@gmail.com> <56B5250C.5010402@foobar.org> <56B53486.60201@gmail.com> <56B5382A.9050206@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B53D6D.3060704@gmail.com> Date: Sat, 6 Feb 2016 13:25:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B5382A.9050206@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 00:25:12 -0000 On 06/02/2016 13:02, joel jaeggli wrote: > On 2/5/16 3:47 PM, Brian E Carpenter wrote: >> On 06/02/2016 11:41, Nick Hilliard wrote: >>> Brian E Carpenter wrote: >>>> Which doesn't matter in the least if you have thousands of flows >>>> from hundreds of sources on the link. >>> >>> in practice, it matters a great deal. 10G and 40G server connectivity >>> is now commonplace. If your egress or core bundle members are of the >>> same order of magnitude as your edge, this will create visible elephant >>> flows in usage graphs. >> >> I completely understand that for IPv4 traffic, but this is about IPv6, >> where there are potentially 64 bits of entropy in the low-order bits >> of the address. The high-order address bits don't add much entropy. > > today in my world we have polarization of flows between hosts talking to > each other using 4 x 10Gbe nics on either end so oddly I don't see > address entropy as enough ever... maybe source dest and flow label are > enough if the latter is actually an entropy source. but the source/dest > are not. If you are up against GridFTP or the like, yes, that will happen and entropy from port numbers is your only hope. OTOH it should be in the host's own interest to set a useful flow label on each subflow. Brian > >> I'm not just saying that; it can be seen in the table headed Trace 4 >> in https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf, where the rows >> for Algorithms 2 and 6 are with and without the top 64 bits of the >> addresses. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From nobody Sat Feb 6 01:13:02 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA761AD47E; Sat, 6 Feb 2016 01:12:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160206091257.25205.98908.idtracker@ietfa.amsl.com> Date: Sat, 06 Feb 2016 01:12:57 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 09:12:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration Authors : Bing Liu Sheng Jiang Xiangyang Gong Wendong Wang Enno Rey Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt Pages : 23 Date : 2016-02-06 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration such as DNS-related configuration. These are the M, O, and A flags, which by definition are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that the divergent behaviors might cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 6 12:57:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E6D1B338F for ; Sat, 6 Feb 2016 12:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTiQDuUsYO5l for ; Sat, 6 Feb 2016 12:57:46 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 1984C1B338E for ; Sat, 6 Feb 2016 12:57:46 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id c3so29214456vkb.3 for ; Sat, 06 Feb 2016 12:57:46 -0800 (PST) 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-type:content-transfer-encoding; bh=cQqY9+Wkv75RETofaTNsjfdjJqXleYMIL6YSD5ppWws=; b=xPP387TziiCTXlDGod707fFmcKDarPPYNMBLs5OALhrzZlpVPncRXy61h9eAdC2aOD tfOA/9FZB1X02Pq/Tu+RpNfEH0tGgEmAe7LnuufpqNP2sy7OmtSpnXiECJ78JJyxHtwv ixA43NyQafG4bCKeB/oijhUjEqDGhKABH4HQRQPXPB7yaKQd0OC3kkm68TreoOtncc8T 0Mu8FBh7mrR5015ZcUP53/t3qyNI02YNpUTb26Hl+4ANboaFHShaJhDzgE75xR8kHdnB oWmEOc0lAWA+46FsnaU3cO83Lk+NguFqRLMvdmUxPwjopoHIBFhptILFHKN84Y4BqWHm kqrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=cQqY9+Wkv75RETofaTNsjfdjJqXleYMIL6YSD5ppWws=; b=CPfWKM2/0dp5gZQaZnz2lmFtJ4RToDeitcoNt3vd0FVcKLpwUaPVXEUw+cmfpnQmbh T6UameeU0mgo6GJofC/G4g0WepNo6XEa8j/4Fo3vXriFkDcpSXmHlHifipYiDm1SuG1V P+ebyOn2+3xPKMtbHiJ64zqR929aGek63lucibTzapz87zC78FZoBcGYpCy24K8IU+VH 56Cu53QEbl/FsGGusycuIDH9x8/jtSL9ujuQOX+xn3yj1XZcHio8y8YHm42U2AXOHptD IDY/iJ4ce4lCD4My2ahAzLgUKWlQM5uncIBaQ5vgWp1/oh1L4wiQGTnNm9XbYETD/tmb GuiQ== X-Gm-Message-State: AG10YOSDkuWQLD3YBtWD26K2Ok3OibEdUQfKnDdnBWoEtqto8yVWuIQ5Y5wBJPLVNPiaR2v6XPCN6eQQbNa4vg== X-Received: by 10.31.128.82 with SMTP id b79mr14240602vkd.47.1454792265225; Sat, 06 Feb 2016 12:57:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Sat, 6 Feb 2016 12:57:15 -0800 (PST) In-Reply-To: <56B4F1A6.7080402@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> From: Mark Smith Date: Sun, 7 Feb 2016 07:57:15 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 20:57:48 -0000 On 6 February 2016 at 06:01, Nick Hilliard wrote: > Joe Touch wrote: >> On 2/5/2016 8:55 AM, Nick Hilliard wrote: >>> Joe Touch wrote: >>>> I don't think it's useful to make recommendations even if they're base= d >>>> on existing practice when we see it sunsetting fairly soon - either >>>> because of network-layer encryption, tunnels, etc. >>> It's not clear what practices/protocols you're referring to when you sa= y >>> sunsetting? >> >> DPI to extract transport context for entropy inside the network. > > If you're referring to IPsec when you say "network layer encryption", I > haven't noticed any proportional increase as a long term trend. It's > still rarely more than line noise in almost all situations. > > As Fernando mentioned, TLS usage has increased substantially as a > percentage of overall tcp flows, but that doesn't impact load balancing > because it allows extraction of L4 n-tuples in the same way as if the > traffic were unencrypted. > > Tunnels other than ipsec tunnel mode exist, but are in the minority in > terms of overall traffic flows on the internet. > > I don't see any prospect of sunsetting inspection of layer 4 info on the > basis of your suggestions, even in the long term as a potential possibili= ty. > The fundamental problem is that you're trying to solving a layer 2 problem using layer 3 or layer 4 information. If layer 3 or layer 4 information changes or isn't there, your layer 2 solution isn't anywhere as near as effective or effective at all. LAG is not a complete solution to more layer 2 link capacity because of this limitation. By using layer 3 and layer 4 information to try to solve your layer 2 problem, you're in effect merging the layers, which would mean that layer 3 or layer 4 changes become limited to occurring when layer 2 changes. Yet the purpose of layers is to decouple them, so that one layer can be changed or completely swapped without the others having to be changed or completely swapped at the same time. If LAG works for you as a layer 2 lack of capacity solution, then that's fine, keep using it. However, I don't think changes in other layers should be prevented just to make LAG work, when it itself doesn't really fully solve the problem it is intending to - lack of layer 2 bandwidth. "LAG is good, but it=E2=80=99s not as good as a fatter pipe" http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Feb 6 13:42:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034CF1B33FF for ; Sat, 6 Feb 2016 13:42:41 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VX_ozh3p_sG for ; Sat, 6 Feb 2016 13:42:39 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71EB1B33FB for ; Sat, 6 Feb 2016 13:42:38 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u16LgSbC017419 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2016 21:42:29 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B668C3.8090009@foobar.org> Date: Sat, 06 Feb 2016 21:42:27 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 21:42:41 -0000 Mark Smith wrote: > If LAG works for you as a layer 2 lack of capacity solution, then > that's fine, keep using it. However, I don't think changes in other > layers should be prevented just to make LAG work, when it itself > doesn't really fully solve the problem it is intending to - lack of > layer 2 bandwidth. we're talking about both LAG and ECMP - the underlying load-sharing methodologies are the same for each on most platforms. In other words, we're talking about lack of link bandwidth, not lack of specifically layer 2 bandwidth. > "LAG is good, but it’s not as good as a fatter pipe" > http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf No doubt well intentioned, that is not a very helpful suggestion. Nick From nobody Sat Feb 6 14:17:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE81B3466 for ; Sat, 6 Feb 2016 14:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnsDpd70opXT for ; Sat, 6 Feb 2016 14:17:12 -0800 (PST) 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 E01EC1B3465 for ; Sat, 6 Feb 2016 14:17:11 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e185so76124106vkb.1 for ; Sat, 06 Feb 2016 14:17:11 -0800 (PST) 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-type:content-transfer-encoding; bh=xtsjm67M/Dw9tm1mhqMDkhXI8Fd/jbKMZCd5fBvEVJg=; b=gjYLHrKJ9xPwSOiOdYh/psEfLES0JhsA6ixs8x+WFbc4/CoKYbcdTr6ixXMn06YCN6 yIKHjG4RzR9xoflq8bL8udTeD8oi1G4RL5pdTsACW5lyI+diQc7Sbbfk9fm+c+2hShDM EyfqkOZoKvqJXhe/JI0y29l1BJ/JPn/IlRP3UjlDMgkNQ1MT7VCmM6EJT4+NHORIr93P 3kB6XgvBlmZ/idKLFym/sEPzMRbd/1b5DSmt6YM/lTHX0WpniNzWnbsXQ/A07ZdrjW16 wHxxecBiXx7oaKM2O60AjK/DKjvWhslWLwjHtqhJuhl36QoLs5n0xvq5gs6FCq9NapgE O0Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xtsjm67M/Dw9tm1mhqMDkhXI8Fd/jbKMZCd5fBvEVJg=; b=Zs2cAfwtpD1Owp5nq+/xMVcFRptXWHpuG+SpId5UwCietcS3TqDDaT3Q25OgfvQ06U pyk0yoUGAG6CojQDyh9x7yiHYluSQ+BMWd+1mVWBkh5P5cl96Om4+x5XvYq1n6XCwc2K FKk9c3SSbwzblPtE39afyut/kt9DQgiR/Q/P9ufVEONVOKb/KQ4pRnPQrilsHEt70xei 6mM5EBLHWjnbm+OyXPCBY8zOs30vWJusXCPZd2dzfr4mZWwNdy5kz/3gbR7pVjC9tedB oWIz5ZclDVNYwF5cb5liXdFcDoBPiPLjM8DQ2EKGPsWavybQpw8l68VAa8kkSy7tLYtW AKWA== X-Gm-Message-State: AG10YOTLaWFxZTZNQnUkJyOLhoUkHpgMPkUHS7oNdNLZRorlqMhnWcmPtEQnTfGj94DaR4dBTdXE9EFGxHyV/g== X-Received: by 10.31.169.67 with SMTP id s64mr14701856vke.72.1454797031024; Sat, 06 Feb 2016 14:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Sat, 6 Feb 2016 14:16:41 -0800 (PST) In-Reply-To: <56B668C3.8090009@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> From: Mark Smith Date: Sun, 7 Feb 2016 09:16:41 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 22:17:13 -0000 On 7 February 2016 at 08:42, Nick Hilliard wrote: > Mark Smith wrote: >> If LAG works for you as a layer 2 lack of capacity solution, then >> that's fine, keep using it. However, I don't think changes in other >> layers should be prevented just to make LAG work, when it itself >> doesn't really fully solve the problem it is intending to - lack of >> layer 2 bandwidth. > > we're talking about both LAG and ECMP - the underlying load-sharing > methodologies are the same for each on most platforms. In other words, > we're talking about lack of link bandwidth, not lack of specifically > layer 2 bandwidth. > I'm not sure I really see the distinction, isn't link bandwidth layer 2 bandwidth? I think in either case of ECMP or LAG, the main issues crop up and the constraints on other layers occur when other layers' information is used as an input. If only the information within the layer that ECMP or LAG is operating in is used, then the layer boundaries are preserved. >> "LAG is good, but it=E2=80=99s not as good as a fatter pipe" >> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf > > No doubt well intentioned, that is not a very helpful suggestion. > It's an observation that even the people who specified it aren't recommending it when you have the option of a fatter pipe. (My recent experience with LAG issues in the last couple of years at a carrier basically showed that 4 x 1Gbps links in a LAG ended up being false economy compared to going straight to 1 x 10Gbps for edge aggregation of layer 2 services - broadcasts, multicasts and any non-IPv4/TCP/UDP protocols weren't balanced well or at all over the 4 x 1Gbps links. The chips in the devices were pretty smart - if the layer 4 info wasn't available, they'd still LB on layer 3 etc., but that still didn't balance the traffic enough that 4 x 1Gbps was really as good as it should have been. I've subsequently thought that LAG would be better implemented how Multilink PPP works - split the frames up, spread the parts across all of the links, then put the parts back together at the other end. That makes it not depend on any upper layer protocol values/fields or any other attributes of the frames. I'm guessing that hasn't been done because it isn't practical to do at high speed.) Regards, Mark. > Nick > From nobody Sat Feb 6 14:41:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003A41B349C for ; Sat, 6 Feb 2016 14:41:01 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMGKjoNY-W7X for ; Sat, 6 Feb 2016 14:40:58 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196CF1B349E for ; Sat, 6 Feb 2016 14:40:57 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u16MeoIU018949 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2016 22:40:50 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B67671.3010409@foobar.org> Date: Sat, 06 Feb 2016 22:40:49 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 22:41:01 -0000 Mark Smith wrote: > I think in either case of ECMP or LAG, the main issues crop up and the > constraints on other layers occur when other layers' information is > used as an input. If only the information within the layer that ECMP > or LAG is operating in is used, then the layer boundaries are > preserved. preserving layer boundaries is laudable, but operators have networks to run. > It's an observation that even the people who specified it aren't > recommending it when you have the option of a fatter pipe. which is fine, except that the option of a fatter pipe is often not viable. > (My recent experience with LAG issues in the last couple of years at a > carrier basically showed that 4 x 1Gbps links in a LAG ended up being > false economy compared to going straight to 1 x 10Gbps for edge > aggregation of layer 2 services - broadcasts, multicasts and any > non-IPv4/TCP/UDP protocols weren't balanced well or at all over the 4 > x 1Gbps links. the cost cut-over point for 1G to 10G is usually around 3x1G. However the breakeven point for 10G to 100G is - depending on the type of kit chosen - currently around 8x. If you need more than 100G - and many networks do - you need LAGs or ECMP because there is nothing faster at the moment. > as good as it should have been. I've subsequently thought that LAG > would be better implemented how Multilink PPP works - split the frames > up, spread the parts across all of the links, then put the parts back > together at the other end. That makes it not depend on any upper layer > protocol values/fields or any other attributes of the frames. one of the design goals of LAG and ECMP is that they can be run over links of unequal load and/or latency. This means that packet reassembly would require the receiving network device to maintain a large amount of state. This is an expensive proposition which does not scale well. Nick From nobody Sat Feb 6 16:21:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47E31A8836 for ; Sat, 6 Feb 2016 16:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4XjOELFOSwq for ; Sat, 6 Feb 2016 16:21:07 -0800 (PST) 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 254A11A8842 for ; Sat, 6 Feb 2016 16:21:06 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id k196so10216614vka.0 for ; Sat, 06 Feb 2016 16:21:06 -0800 (PST) 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-type:content-transfer-encoding; bh=6dIOsGFzMPjMJokB2FSUu1kAYNIhSyCiN/gZMeVjO0M=; b=Ylp7ZCcpmD9eyy1BkRSmZrVZ3G5XhVtEDidcHfwqSdMwoFuWSTzAHLlEBtvnCKJKAR 37g5oZsKeRsscwnN631WmRaiQLZ4h/rd/9y7IrBozs8KdGfcd9TkGSGDtxwIl/W/4TgL BQKMyf6pXtOFp4GG1ov0gypUEWtYFF0k+hqZdmtb/9rein2zg9+y5t2z+yafoSqrkkq+ eQHBNeuNtKuzhL/++gcxcdibG+5KkoazbkRguwEapeUYdXmxySbAWB/wp8B9IKzcwzO7 6jRPIxL3CmvGKb0MlqNvu+La7bMzTyUzyu3H3Ddj5YQQDOVzrTFX/KJwceQJ84jvDjiJ WQfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=6dIOsGFzMPjMJokB2FSUu1kAYNIhSyCiN/gZMeVjO0M=; b=ASrrHddCNIj6TmUztW4915xlVF/oINQNHks/OLpfCLyohiz+0WAj4EZb0yFDnye8+x 3+h+ziaBeH/UpKd71p2LZ5jrfm9t7hBPbyrgieQuNdq0h4en6BocR1w8nAyqyGmywE9P EasaP+bSq9S2G/Al4moyzXfI85UOGbK4YiVYZvjsTG/uM54jzakQsvPkWClFAcvVAu0o eQOhuZcNaZA7s6DfRZvkZHBX7A1KoScu3tcPiScVXKXYrhbRUkGYkBbj7Pmof71jrEfl Tqvc9+JulMn+ddYwXX4GJzA4dZxxJSbNa5j5NCpZMEZAlRpUnrcyFjKSE56CMXSk22XT SU/Q== X-Gm-Message-State: AG10YOSZIYVzHdZcYofAtvxQyw3wKZOT7Z1PA8t+1PPnwgoJWgDEGhgwgLIIAvoXE7HQsv5yFZehcFAo63C3BA== X-Received: by 10.31.128.82 with SMTP id b79mr14663887vkd.47.1454804465941; Sat, 06 Feb 2016 16:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Sat, 6 Feb 2016 16:20:36 -0800 (PST) In-Reply-To: <56B67671.3010409@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> From: Mark Smith Date: Sun, 7 Feb 2016 11:20:36 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 00:21:08 -0000 On 7 Feb 2016 09:40, "Nick Hilliard" wrote: > > Mark Smith wrote: > > I think in either case of ECMP or LAG, the main issues crop up and the > > constraints on other layers occur when other layers' information is > > used as an input. If only the information within the layer that ECMP > > or LAG is operating in is used, then the layer boundaries are > > preserved. > > preserving layer boundaries is laudable, but operators have networks to r= un. > Which really just sounds like you're saying that operators should never think and never have to think about long term possible costs and consequences of their technical choices. I've worked on and had to untangle a number of networks that have been built with that sort of mindset. I don't want to see that short of short sightedness encoded into the Internet protocols. > > It's an observation that even the people who specified it aren't > > recommending it when you have the option of a fatter pipe. > > which is fine, except that the option of a fatter pipe is often not viabl= e. > Well then, you have to put up with your LAG and ECMP limitations. That is the cost of not being able to use a fatter pipe. The compromise of LAG instead of a fatter pipe is not free, and should not be made cheaper at the cost of upper layer flexibility in the Internet and in particular on other operators' networks. > > (My recent experience with LAG issues in the last couple of years at a > > carrier basically showed that 4 x 1Gbps links in a LAG ended up being > > false economy compared to going straight to 1 x 10Gbps for edge > > aggregation of layer 2 services - broadcasts, multicasts and any > > non-IPv4/TCP/UDP protocols weren't balanced well or at all over the 4 > > x 1Gbps links. > > the cost cut-over point for 1G to 10G is usually around 3x1G. However > the breakeven point for 10G to 100G is - depending on the type of kit > chosen - currently around 8x. If you need more than 100G - and many > networks do - you need LAGs or ECMP because there is nothing faster at > the moment. > I think there is. If you scale out the number of links, the number of devices they attach to, and the paths into and out of those devices, you'll get the bandwidth you need, less single points of failure and lower consequences when there is a failure of a device or link. > > as good as it should have been. I've subsequently thought that LAG > > would be better implemented how Multilink PPP works - split the frames > > up, spread the parts across all of the links, then put the parts back > > together at the other end. That makes it not depend on any upper layer > > protocol values/fields or any other attributes of the frames. > > one of the design goals of LAG and ECMP is that they can be run over > links of unequal load and/or latency. It is not a specific design goal of LAG, although it isn't precluded. Even the actual load distribution method is unspecified. >From 802.1AX, "Aggregation of links of different data rates is not prohibited nor required by this standard. Determining how to distribute traffic across links of different data rates is beyond the scope of this standard. NOTE 2=E2=80=94Previous versions of this standard restricted the data rate = of the aggregated links. However, the specified mechanisms did not depend on whether the links operated at the same rate or not." > This means that packet reassembly > would require the receiving network device to maintain a large amount of > state. This is an expensive proposition which does not scale well. > "Expensive" is a relative term. If much more effective and non-protocol field value/existence dependent balancing over 4 x 1 Gbps links was less cost than a 10Gbps link to carry the same traffic, it wouldn't be expensive, it would be cheap. Regards, Mark. > Nick > From nobody Sun Feb 7 05:12:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAC81B3A42 for ; Sun, 7 Feb 2016 05:12:25 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra7sJPUCP1vG for ; Sun, 7 Feb 2016 05:12:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1741A1B3A3D for ; Sun, 7 Feb 2016 05:12:22 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u17DCD1k046156 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 13:12:13 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B742AC.7010307@foobar.org> Date: Sun, 07 Feb 2016 13:12:12 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 13:12:25 -0000 Mark Smith wrote: > Which really just sounds like you're saying that operators should > never think and never have to think about long term possible costs and > consequences of their technical choices. No, I'm saying that LAGs and ECMP are here to stay, and no amount of wishful thinking is going to stop them from being a reality that needs to be dealt with. If you don't need functional load-balancing on your network, then good for you, but most network operators do. Nick From nobody Sun Feb 7 05:30:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26911B3A66 for ; Sun, 7 Feb 2016 05:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Abn0mJ-vtMg for ; Sun, 7 Feb 2016 05:30:42 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 078E61B3A65 for ; Sun, 7 Feb 2016 05:30:41 -0800 (PST) Received: (qmail 17656 invoked from network); 7 Feb 2016 13:30:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Feb 2016 13:30:39 -0000 Date: Sun, 07 Feb 2016 14:30:39 +0100 (CET) Message-Id: <20160207.143039.74735886.sthaug@nethelp.no> To: nick@foobar.org From: sthaug@nethelp.no In-Reply-To: <56B742AC.7010307@foobar.org> References: <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 13:30:45 -0000 > > Which really just sounds like you're saying that operators should > > never think and never have to think about long term possible costs and > > consequences of their technical choices. > > No, I'm saying that LAGs and ECMP are here to stay, and no amount of > wishful thinking is going to stop them from being a reality that needs > to be dealt with. If you don't need functional load-balancing on your > network, then good for you, but most network operators do. As an example of this - we were told by Juniper that when they were introducing 100G, several years ago, they had very specific requests from some of their biggest customers that the 100G interfaces needed to support link aggregation right from the start - because those customers *already then* had a need for link capacities greater than 100G. (And yes, I absolutely agree that LAGs and ECMP are here to stay. And I don't believe peeking at the L3 and L4 info to ensure link distribution is going to disappear any time soon.) Steinar Haug, AS2116 From nobody Sun Feb 7 05:38:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E471B3A7A for ; Sun, 7 Feb 2016 05:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBO8f548tVDa for ; Sun, 7 Feb 2016 05:38:37 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 567D01B3A77 for ; Sun, 7 Feb 2016 05:38:36 -0800 (PST) Received: (qmail 17709 invoked from network); 7 Feb 2016 13:38:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Feb 2016 13:38:35 -0000 Date: Sun, 07 Feb 2016 14:38:35 +0100 (CET) Message-Id: <20160207.143835.41645325.sthaug@nethelp.no> To: fgont@si6networks.com From: sthaug@nethelp.no In-Reply-To: <56B50759.1080109@si6networks.com> References: <56B4E4FD.7010608@si6networks.com> <20160205.200348.74751017.sthaug@nethelp.no> <56B50759.1080109@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 13:38:38 -0000 > >>>>> I don't think it's useful to make recommendations even if they're based > >>>>> on existing practice when we see it sunsetting fairly soon - either > >>>>> because of network-layer encryption, tunnels, etc. > >>>> > >>>> It's not clear what practices/protocols you're referring to when you say > >>>> sunsetting? > >>> > >>> DPI to extract transport context for entropy inside the network. > >> > >> I've seen increased deployment of *TLS*... but TLS still allows you to > >> extract the transport-related information.... > > > > I think "fairly soon" needs to be defined. I believe extracting > > entropy from address and port numbers will continue to be used at > > least as long as we have a significant amount of IPv4 traffic. > > just curious: why do you think IPv6 would make a different in this > respect? -- because extracting such information can be difficult and > hence everyone would shift to employing the flow-label, or something else? I actually *don't* think IPv6 will make a significant difference (at least not until use of the flow label for entropy is *much* more widespread). However, IPv4 doesn't have the luxury of the flow label, and thus link aggregation entropy basically *must* be gained from L3 and L4 info. Steinar Haug, AS2116 From nobody Sun Feb 7 06:02:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358921B3B0E for ; Sun, 7 Feb 2016 06:02:17 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT2bb9PgbzYu for ; Sun, 7 Feb 2016 06:02:15 -0800 (PST) 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 0F4CD1B3B0D for ; Sun, 7 Feb 2016 06:02:15 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aSPug-0000C8C; Sun, 7 Feb 2016 15:02:06 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> In-reply-to: Your message of "Sun, 07 Feb 2016 14:30:39 +0100 (CET) ." <20160207.143039.74735886.sthaug@nethelp.no> Date: Sun, 07 Feb 2016 15:02:05 +0100 Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:02:17 -0000 In your letter dated Sun, 07 Feb 2016 14:30:39 +0100 (CET) you wrote: >(And yes, I absolutely agree that LAGs and ECMP are here to stay. And I >don't believe peeking at the L3 and L4 info to ensure link distribution >is going to disappear any time soon.) I could be wrong here, but as far as I know the reason for peeking at L3/L4 is to avoid reordered packets. So an alternative way to go forward is to fix the higher level protocols to deal with out of order packets and then switch to statistical multiplexing. From nobody Sun Feb 7 06:21:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8FB1B3B3F for ; Sun, 7 Feb 2016 06:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uy0yXR6Vp4v for ; Sun, 7 Feb 2016 06:21:53 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id EAF9E1B3B3E for ; Sun, 7 Feb 2016 06:21:52 -0800 (PST) Received: (qmail 17973 invoked from network); 7 Feb 2016 14:21:51 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Feb 2016 14:21:51 -0000 Date: Sun, 07 Feb 2016 15:21:51 +0100 (CET) Message-Id: <20160207.152151.71101099.sthaug@nethelp.no> To: pch-v6ops-4@u-1.phicoh.com From: sthaug@nethelp.no In-Reply-To: References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:21:55 -0000 > >(And yes, I absolutely agree that LAGs and ECMP are here to stay. And I > >don't believe peeking at the L3 and L4 info to ensure link distribution > >is going to disappear any time soon.) > > I could be wrong here, but as far as I know the reason for peeking at L3/L4 > is to avoid reordered packets. You identify one "flow" by peeking at L3/L4 info, and the you ensure that all packets for that flow are transmitted over the same link, to avoid reordering. But you *also* gain a better distribution of flows across links. > So an alternative way to go forward is to fix the higher level protocols > to deal with out of order packets and then switch to statistical multiplexing. Possibly. Not holding my breath waiting for this to happen, though. Steinar Haug, AS2116 From nobody Sun Feb 7 06:28:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82C1B3B42 for ; Sun, 7 Feb 2016 06:28:55 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz1PLhQ8byG6 for ; Sun, 7 Feb 2016 06:28:54 -0800 (PST) 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 EA9031B3B41 for ; Sun, 7 Feb 2016 06:28:53 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aSQKV-0000DIC; Sun, 7 Feb 2016 15:28:47 +0100 Message-Id: To: v6ops@ietf.org To: sthaug@nethelp.no From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.152151.71101099.sthaug@nethelp.no> In-reply-to: Your message of "Sun, 07 Feb 2016 15:21:51 +0100 (CET) ." <20160207.152151.71101099.sthaug@nethelp.no> Date: Sun, 07 Feb 2016 15:28:47 +0100 Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:28:55 -0000 >> So an alternative way to go forward is to fix the higher level protocols >> to deal with out of order packets and then switch to statistical multiplexin >g. > >Possibly. Not holding my breath waiting for this to happen, though. One option is to do statistical multiplexing for packets protected by an EH. A small extension header inside EH can easily deal with reordered packets. Or people using IPSEC tunnels can try to get TCP implementations fixed. From nobody Sun Feb 7 06:53:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411C71B3B86 for ; Sun, 7 Feb 2016 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUj-6HRXNwb4 for ; Sun, 7 Feb 2016 06:53:10 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4201B3B84 for ; Sun, 7 Feb 2016 06:53:09 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 83BF043EA92; Sun, 7 Feb 2016 15:53:06 +0100 (CET) Date: Sun, 07 Feb 2016 15:53:06 +0100 (CET) Message-Id: <20160207.155306.18852624714145445.he@uninett.no> To: pch-v6ops-4@u-1.phicoh.com From: Havard Eidnes In-Reply-To: References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 14:53:12 -0000 > I could be wrong here, but as far as I know the reason for > peeking at L3/L4 is to avoid reordered packets. I think it's also been pointed out that an important factor is to get a better distribution for the load balancing. > So an alternative way to go forward is to fix the higher level > protocols to deal with out of order packets and then switch to > statistical multiplexing. Higher-level protocols "deals" with out-of-order packets just fine from a correctness perspective. It's just that the higher- level protocols are highly optimized for the usual case, i.e. in- order packet delivery. Optimizing higher-level protocols (TCP) for out-of-order delivery doesn't magicially happen just because someone wishes for it... And ... I'd claim that if it was easy, it would already have been done. Regards, - H=E5vard From nobody Sun Feb 7 11:09:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A451A1A75 for ; Sun, 7 Feb 2016 11:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVDpbEHBmmoF for ; Sun, 7 Feb 2016 11:09:28 -0800 (PST) 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 6B33B1A1A72 for ; Sun, 7 Feb 2016 11:09:28 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id e127so2537355pfe.3 for ; Sun, 07 Feb 2016 11:09:28 -0800 (PST) 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-type :content-transfer-encoding; bh=TKTsu7NKIkVshd8/pkazVmdoLiRaxUj9h530eFTZeT8=; b=a62rxQ8u64n089eMRpuZwrtW7o2LuTRkLXpYqF85xS98/PaicnRvzAZI+XNZkHpUbM +uyb73CEDRNS9vG3ACJlsYv7yDRkO35w64j1CFHt9HwsEzCKs5vZH4G+qNzNiLvTuzJa +11oX6ySzfxtl9OhUHGdoarZa2dhq6ZL/Zkq9HgKewObCMS9VYWsvceVMu80zop5HmBj r6kES6kgg222F0R0/pHLsw9nb4i8c53uZ9ZAV7qJ/ig4u7FfJwXhJaAdIqZ9aUJ1Eo7I b1+XADMYdUUfwKAdfxzMYah04uKIMvHzps9x3Mssl7D8tNiKNMIafJmSbzVwT46A3S+y y4DA== 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-type :content-transfer-encoding; bh=TKTsu7NKIkVshd8/pkazVmdoLiRaxUj9h530eFTZeT8=; b=a8NwJhkxGw+mxmK3peUxNSkGUp/R5jG8hEUi08z8WSZy972YsF94PGVuJufCM+r1NO wwzpnkLJmPa2d2mD0IulERA3Re6ECLxVOnwk6nkzC58UCo7X4xwLZWIwJW8Kg3a0nHxL eH2WemmfgZ46rU9sRxUUBLYOOpWvi6ZIN9kjBSKx+Cv8I4UNfmXyzd2y5jzk8Z3w3EvR 5OWnNEIHq0m+eZgaBpOFBKR+F+U0jm3JZc1xtT/1+ybGmRynIOC1PfJJnVdKcYWjLsl9 cx5+HV5gr01oI8PLdEv3DoZlIzIoC88obU2bNKW2A52kRlMfD4g67A/EEliooGjBA54Q LcIw== X-Gm-Message-State: AG10YOQEGJKT/myph0PnvThyGlUhD4zJa+t/UeuSxLqVLn9JYDzD1xHNDtxYUBdgmiAQxA== X-Received: by 10.98.86.145 with SMTP id h17mr37037943pfj.9.1454872168035; Sun, 07 Feb 2016 11:09:28 -0800 (PST) Received: from ?IPv6:2406:e007:5a31:1:28cc:dc4c:9703:6781? ([2406:e007:5a31:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d22sm18821867pfj.32.2016.02.07.11.09.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Feb 2016 11:09:26 -0800 (PST) To: Havard Eidnes , pch-v6ops-4@u-1.phicoh.com References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.155306.18852624714145445.he@uninett.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B79663.2050208@gmail.com> Date: Mon, 8 Feb 2016 08:09:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160207.155306.18852624714145445.he@uninett.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 19:09:29 -0000 On 08/02/2016 03:53, Havard Eidnes wrote: >> I could be wrong here, but as far as I know the reason for >> peeking at L3/L4 is to avoid reordered packets. > > I think it's also been pointed out that an important factor is to > get a better distribution for the load balancing. > >> So an alternative way to go forward is to fix the higher level >> protocols to deal with out of order packets and then switch to >> statistical multiplexing. > > Higher-level protocols "deals" with out-of-order packets just > fine from a correctness perspective. It's just that the higher- > level protocols are highly optimized for the usual case, i.e. in- > order packet delivery. > > Optimizing higher-level protocols (TCP) for out-of-order delivery > doesn't magicially happen just because someone wishes for it... > And ... I'd claim that if it was easy, it would already have been > done. This is something that network coding mitigates to some degree*, but the fact that you have to use something as complex as network coding shows that it is indeed a hard problem. So yes, put it in the "science fiction" bucket for now. Getting all sources to set the flow label is physically possible, and seems to me to be the best hope of making the use of extension headers compatible with ECMP/LAG. But the operations community would need to push the operating systems community hard to make it happen. Brian * http://www.hindawi.com/journals/ijdsn/2015/379108/ From nobody Sun Feb 7 11:25:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20C41A1AA9 for ; Sun, 7 Feb 2016 11:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQR81y6mLVVX for ; Sun, 7 Feb 2016 11:25:48 -0800 (PST) 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 671841A1AB2 for ; Sun, 7 Feb 2016 11:25:48 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id c3so37527015vkb.3 for ; Sun, 07 Feb 2016 11:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RZMdP5zbUoG9WC/h6fxucCkfbhMgnuKhFdFFu67DSw4=; b=Cgxu0U/6XjQiVvtUR4/cv5y3xn/cGRAmTGJllYF3VwuqY9b+e9oeL1pd6ovOS3wt5T nuZT/vLPVThKLbX1CFyaUwiwvuecZUZmpT+c9t4EaZDuxvC9XdiqFm8mZ+osBcDcBUJO DLzd4ovPY2j7BdF22XND9s8sgkK8VDnrEkWwi0avBSM+p43FJUsrY5THnXuj71DQ6MSY bMjzGXOI3qHOES4a+sR8DtyNraSqfOpwlkap7fW7GnmodaxcboxfPPfEY2ATflTn3n5E S0A0xJe6XeM0KxBH6rw+HYPDfZOz9KcUEs1JM254kRNQalgbAHF7uNhcMPj0fluZcRBb XlJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=RZMdP5zbUoG9WC/h6fxucCkfbhMgnuKhFdFFu67DSw4=; b=Zmt1XCI7q5P/E+sKPXbdF0D5ta74SfXqqlF9B5xVBNLt4hiSiba8GEWr/yahHWRI5O 1T+ROGJxl3Ad3SwIOFvJ4fcYxEOKC8KQiYMf5XPnhkWBd4mB3fT9m3op7pnurhmNJ3zF 8s0uuC0WEObyTsDYcFzGLHSoUGITWf16s08qLd1oOGHu/SSiXAqsX8Ed1xP0ViQ/CM9s n9Ar7HTOeAYELcOToGlfXNQ1EeMrHqFldaeZ6D4bd2f9idYYFmkgK4lVJegOeVQKiNXK Tu2ChI3LaftH++RKWfjYXPniMhV4DYANWoTVNbri0Yv+TFyjvnLVsz46M1wCSJcMnKwM /g1A== X-Gm-Message-State: AG10YOSFhKjD3GsRC3XwFt23IzgLHjKhLRV23wisq01gw3NlzVfybgyVSHotWeVpOYIr+m9fT7OwYWsidnMBaw== X-Received: by 10.31.162.20 with SMTP id l20mr15805560vke.137.1454873147566; Sun, 07 Feb 2016 11:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Sun, 7 Feb 2016 11:25:18 -0800 (PST) From: Mark Smith Date: Mon, 8 Feb 2016 06:25:18 +1100 Message-ID: To: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 19:25:49 -0000 HI, I'm revisiting a few of my drafts that I've been intending to update, and here is the first. My basic realisation was that Solicited-Node joins also could serve as a low resolution address (or address space range) registration method, which could then be used by a router to determine whether it needs to send a ND NS or not. If the Solicited-Node group is present, send the ND NS, if the group isn't, then don't. This update adds a few sections and modes based on Lorenzo's feedback: - Strict and Relaxed discard modes. Universal discarding is Strict mode, Relaxed mode only discards if there is an indication a DoS is occurring, to allow for lower MLD reliability or implementations that don't support MLD - Some discussion on MLD reliability and how it would effect this method. Comments and suggestions appreciated. Regards, Mark. ---------- Forwarded message ---------- From: Date: 8 February 2016 at 06:14 Subject: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt To: "markzzzsmith+ietf-dt@gmail.com" A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt has been successfully submitted by Mark Smith and posted to the IETF repository. Name: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Revision: 01 Title: Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership Document date: 2016-02-07 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt Status: https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/ Htmlized: https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01 Abstract: For each of their IPv6 unicast or anycast addresses, nodes join a Solicited-Node multicast group, formed using the lower 24 bits of the address. This Solicited-Node group membership could be used by routers to further mitigate a Neighbor Discovery cache Denial of Service attack. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Feb 7 11:41:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525241A1B56 for ; Sun, 7 Feb 2016 11:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8Fv6smAl6DY for ; Sun, 7 Feb 2016 11:41:48 -0800 (PST) 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 DEE3E1A1B3F for ; Sun, 7 Feb 2016 11:41:47 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id c3so37644155vkb.3 for ; Sun, 07 Feb 2016 11:41:47 -0800 (PST) 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-type; bh=dD0UmNt8uuJNi237xGqVKpBPo+ilzibpwb3vxsudOQs=; b=zaitgYtXPn7sge4cUodZreWqwWjwlUgvGRABxfpNuyNm3Z6FkaEcWn/StSjNJda04D OiaaGrqcRH5IR1oGkY2aCfLxHzvJIfaTbnctg9i/q9FJbqPfilbC/KjIpWZFBRhmQ17A zHiWAfoxvJTI7ymqFZNaUh6IQFdBsI7PgK+ZT6d4FSHqciY3+LYu+3rAqxFq6Au4Shon BvAtrPRtFk69WV7uChltuXtN5lJmK4XmALwBG8g2ATJ61q2MNvAsjWWnayXy/KSVSVCw EDcmaCoY9pCm6G4jdLx8+kK/Gu6oN71kta9+vAvlGtsGVstRYUm06JMdmfjxlNRCVBOR Beuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dD0UmNt8uuJNi237xGqVKpBPo+ilzibpwb3vxsudOQs=; b=CT5qOBVQO9qPMV8EfI45IOaVcTEiHbKKzXVH3M7upKBbU8HmxBxuksD87rKQzoPvWf 4mUHJDeGWyBAoBSf317om72+DEUUcDrq8v4ArPutF9KXC7hktkPXewe9Iz+o6hoylYPw QNePu0Je/S/Z/TIuA0sV36ratCMlHk8smsz/2lF5HS8nnZjqeOYiPdS+PEyQ8/Fh5RTz chF0YvlrE3UWP5Uhe+Dfia7HqmOR9aNdtjTrDDCZ33IigOZM37OVf4d9I3MSyDc+s6bd e1+IKTHh1C/Ls/i99lBCwK2GzqIc5K/t4+BItHACb7tgQm5typTVjSxF6vDPvX2ImFIH XZ1w== X-Gm-Message-State: AG10YOSBOCT8IuUZGr4OqbLauSMEz/ONwqeo9ngN17c2Qz8Wm2CNl+ktkIfflIE6WyLU2nKRgGYDoBnCiUaogg== X-Received: by 10.31.128.82 with SMTP id b79mr17258014vkd.47.1454874107011; Sun, 07 Feb 2016 11:41:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Sun, 7 Feb 2016 11:41:17 -0800 (PST) In-Reply-To: <56B742AC.7010307@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> From: Mark Smith Date: Mon, 8 Feb 2016 06:41:17 +1100 Message-ID: To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 19:41:49 -0000 On 8 February 2016 at 00:12, Nick Hilliard wrote: > Mark Smith wrote: >> Which really just sounds like you're saying that operators should >> never think and never have to think about long term possible costs and >> consequences of their technical choices. > > No, I'm saying that LAGs and ECMP are here to stay, and no amount of > wishful thinking is going to stop them from being a reality that needs > to be dealt with. So no amount of wishful thinking will stop EHs or some other depth of encapsulation that invalidates layer 2 inspection of layer 3 and layer 4 fields and values for ECMP and LAG either. There is a specific field in the IPv6 fixed header to be used for this and similar purposes - the flow label field. You're allowed to override it's value if a host sets it to zero (and if you override it in *your* network when it isn't zero, nobody outside your network is going to know either). Use the tool provided for the purpose, and insist that your LAG/ECMP vendor considers the flow label field in their load distribution function, as per the RFC. (and in a network virtualisation context, layer 2 information could be made visible to layer 3 ECMP without violating layers - see section 5 https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07) > If you don't need functional load-balancing on your > network, then good for you, but most network operators do. > > Nick From nobody Sun Feb 7 13:37:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5271A88D5 for ; Sun, 7 Feb 2016 13:37:41 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3-6sEAD8OuR for ; Sun, 7 Feb 2016 13:37:40 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8CE1A88D4 for ; Sun, 7 Feb 2016 13:37:39 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u17LbUQE058875 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 21:37:31 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B7B919.8090001@foobar.org> Date: Sun, 07 Feb 2016 21:37:29 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 21:37:41 -0000 Mark Smith wrote: > You're allowed to override it's value if a host sets it to zero (and > if you override it in *your* network when it isn't zero, nobody > outside your network is going to know either). How are you going to do that in a useful way without inspecting L4 values? > Use the tool provided for the purpose, and insist that your LAG/ECMP > vendor considers the flow label field in their load distribution > function, as per the RFC. this is precisely the problem: it's not my vendor, it's someone else's vendor. I'm transporting their packets over my link bundles. If these packets don't have a flow label set then it comes back to a choice between poor quality load balancing (which affects me as a transport provider) or else trying to inspect L4 info to either do ad-hoc load balancing or to use that info to create a new flow label. Nick From nobody Sun Feb 7 18:38:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F5B1A8A3F for ; Sun, 7 Feb 2016 18:38:09 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prVkevZYOYdp for ; Sun, 7 Feb 2016 18:38:08 -0800 (PST) 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 4FB921A8A29 for ; Sun, 7 Feb 2016 18:38:08 -0800 (PST) Received: from mb-2.local (h7.180.128.40.static.ip.windstream.net [40.128.180.7] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u182bs2p071005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 02:37:56 GMT (envelope-from joelja@bogus.com) To: Mark Smith , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> From: joel jaeggli Message-ID: <56B7FF83.9090704@bogus.com> Date: Sun, 7 Feb 2016 18:37:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gfoIfIoBWpuDe76XrD2iCxIBfdoB8tOVn" Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 02:38:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gfoIfIoBWpuDe76XrD2iCxIBfdoB8tOVn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/6/16 4:20 PM, Mark Smith wrote: > On 7 Feb 2016 09:40, "Nick Hilliard" wrote: >> >> Mark Smith wrote: >>> I think in either case of ECMP or LAG, the main issues crop up and th= e >>> constraints on other layers occur when other layers' information is >>> used as an input. If only the information within the layer that ECMP >>> or LAG is operating in is used, then the layer boundaries are >>> preserved. >> >> preserving layer boundaries is laudable, but operators have networks t= o run. >> >=20 > Which really just sounds like you're saying that operators should > never think and never have to think about long term possible costs and > consequences of their technical choices. we do a lot of things that involve tradeoffs... some of them are bad. building networks without L3/L4 ECMP at any signficant scale is not an option. so lot of people have to live with that tradeoff. --gfoIfIoBWpuDe76XrD2iCxIBfdoB8tOVn 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 iEYEARECAAYFAla3/4MACgkQ8AA1q7Z/VrJwOACePfcUMNbRTuuqJWbB5fN9kqUu CNkAniuMAseUgF0h5jFvcOKEaN1O3J3b =TMO+ -----END PGP SIGNATURE----- --gfoIfIoBWpuDe76XrD2iCxIBfdoB8tOVn-- From nobody Sun Feb 7 22:55:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E11AC3F3 for ; Sun, 7 Feb 2016 22:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXXWPRceuphu for ; Sun, 7 Feb 2016 22:55:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638EA1AC3F5 for ; Sun, 7 Feb 2016 22:55:32 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u186soG0000700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Feb 2016 22:54:52 -0800 (PST) To: Nick Hilliard , Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> From: Joe Touch Message-ID: <56B83BB9.7040704@isi.edu> Date: Sun, 7 Feb 2016 22:54:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B7B919.8090001@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 06:55:33 -0000 Hi, all, I get the impression the most useful way forward is: - use the flow field where it is available and nonzero (i.e., follow available intent where indicated) - if you have to dig it out from other layers, use it to fill in a flow label if it's available - always assume that any method to dig into other layers not only can fail, but should be avoided in the future because it is more likely to fail as time goes by I.e., any document prepared now should not assume continued reliance on the visibility of upper layers indefinitely. Otherwise, you're effectively recommending that security that obscures upper layer headers NOT be deployed, and that seems inappropriate. Joe From nobody Sun Feb 7 23:20:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1C1AC436 for ; Sun, 7 Feb 2016 23:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1SD8JaWlqMK for ; Sun, 7 Feb 2016 23:20:11 -0800 (PST) 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 3A1B11AC435 for ; Sun, 7 Feb 2016 23:20:11 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id k196so23115235vka.0 for ; Sun, 07 Feb 2016 23:20:11 -0800 (PST) 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:content-type; bh=pe1vFB4XyKBldS/+TZQyr9BnngE4fc1GXLt0EAKS8lw=; b=QwUO2ji6G1NvblgFO1b8kapKFpusDvKoJyIpHeb/CUgu4JyakY9jH4T980Lj5NODU0 TPL5KPx4/zLatux44h3xiDKu9RfLeFYlcUguxh3zE5AHEe+hC6G0z2tDndoxUg1Zyvyo 9eL8uTjkZK79kapuEweHr4FAxKq6rTLMBjXQjfDJhDvPw5r1+EGPkKl82YiqUEArBg1U aD1Z89NNOue4GbP3cz6WsVrjTL0wPFWn15fFaT5dsiqjvgyHMMcPLSigQWOUy+2C04GV pRXKYzPkivCdqM1oaQfCjNYcbz8puHQXpuI+w491kb/KBOn/lS1rbp1wnnocGF/0yeiT RLaA== 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-type; bh=pe1vFB4XyKBldS/+TZQyr9BnngE4fc1GXLt0EAKS8lw=; b=cJreX6ZN5BrmhCqfyxphAsED8HiXw+urddlLU+5Fay/YnzThTl4IgqHdwHvrSNwZN+ Z40wOim0AHMokcx95Ebi0R19rLMEg0KdIDoW7ZhkiWm/HiITeuzqrj3T8s535etVc1Pq 3xarfc8dZa8cn8lGjJCxZb/wo/iX6coAuoNyNY5zgjaWvEL9HYlC6mRQPLqms3g4o2vX Acj/6HMM2qtbnAo14ojpSJ/DLl8YBLwvQmLZ183x873nnOiAKHZDIDCAi9/vasmVLh93 ZnzJcQ30Gz1lFs2+//0mGSJJyqkxsj2yEYLV1kh6ghEOmYXnQBvUCE5rDmoUSi7p0MmO 3RYg== X-Gm-Message-State: AG10YOSZtLZ60909V2cq7fqoc+/dkCkBLmca9niZYT1qtcWAPaplpboISFKinVwPX1qjxnGeLs/QgbHz61uDug== MIME-Version: 1.0 X-Received: by 10.31.162.20 with SMTP id l20mr17348474vke.137.1454916010272; Sun, 07 Feb 2016 23:20:10 -0800 (PST) Received: by 10.159.34.103 with HTTP; Sun, 7 Feb 2016 23:20:10 -0800 (PST) Received: by 10.159.34.103 with HTTP; Sun, 7 Feb 2016 23:20:10 -0800 (PST) In-Reply-To: <56B83BB9.7040704@isi.edu> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> Date: Mon, 8 Feb 2016 18:20:10 +1100 Message-ID: From: Mark Smith To: Joe Touch Content-Type: multipart/alternative; boundary=001a1143f2acf86caa052b3d07c9 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 07:20:12 -0000 --001a1143f2acf86caa052b3d07c9 Content-Type: text/plain; charset=UTF-8 +1 I'm not against layer 2 and layer 3 devices peaking at other layers' field values, as long as they are very careful about how they use them*. What I am against is layer 2 limited workarounds (limited workarounds because they don't increase capacity for all upper layer traffic) being used to justify freezing upper layer development and evolution. (* I have been burned by a layer 2 device interpreting IP DST of 0.0.0.0 as a debug switch, causing my testing to fail - I didn't change the testers default layer 3 test traffic addresses because I was testing layer 2, and wasted 2 weeks going thorough various support channels before finding out what was going on.) On 8 Feb 2016 17:55, "Joe Touch" wrote: > > Hi, all, > > I get the impression the most useful way forward is: > > - use the flow field where it is available and nonzero (i.e., follow > available intent where indicated) > > - if you have to dig it out from other layers, use it to fill in a flow > label if it's available > > - always assume that any method to dig into other layers not only can > fail, but should be avoided in the future because it is more likely to > fail as time goes by > > I.e., any document prepared now should not assume continued reliance on > the visibility of upper layers indefinitely. Otherwise, you're > effectively recommending that security that obscures upper layer headers > NOT be deployed, and that seems inappropriate. > > Joe --001a1143f2acf86caa052b3d07c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

I'm not against layer 2 and layer 3 devices peaking at o= ther layers' field values, as long as they are very careful about how t= hey use them*.

What I am against is layer 2 limited=C2=A0 workarounds (limi= ted workarounds because they don't increase capacity for all upper laye= r traffic) being used to justify freezing upper layer development and evolu= tion.

(* I have been burned by a layer 2 device interpreting IP D= ST of 0.0.0.0 as a debug switch, causing my testing to fail - I didn't = change the testers default layer 3 test traffic addresses because I was tes= ting layer 2, and wasted 2 weeks going thorough various support channels be= fore finding out what was going on.)

On 8 Feb 2016 17:55, "Joe Touch" <touch@isi.edu> wrote:
>
> Hi, all,
>
> I get the impression the most useful way forward is:
>
> - use the flow field where it is available and nonzero (i.e., follow > available intent where indicated)
>
> - if you have to dig it out from other layers, use it to fill in a flo= w
> label if it's available
>
> - always assume that any method to dig into other layers not only can<= br> > fail, but should be avoided in the future because it is more likely to=
> fail as time goes by
>
> I.e., any document prepared now should not assume continued reliance o= n
> the visibility of upper layers indefinitely. Otherwise, you're
> effectively recommending that security that obscures upper layer heade= rs
> NOT be deployed, and that seems inappropriate.
>
> Joe

--001a1143f2acf86caa052b3d07c9-- From nobody Mon Feb 8 00:59:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6B81ACDBA for ; Mon, 8 Feb 2016 00:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEZ3xbQqwJZr for ; Mon, 8 Feb 2016 00:59:49 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425E31ACDBB for ; Mon, 8 Feb 2016 00:59:49 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B25CAD7883; Mon, 8 Feb 2016 00:59:48 -0800 (PST) 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=wSc9fbZr/K984ToOgW+MlnlyDvo=; b= cpzHv5xezHpFBMgG5PrtwO7F9ASMqVb8hsJ+4heggjSVIWgBBNZn6XTIWeTvt7nh w3R0cyKi2U/+/OObwse2ZGoZk/k6CLXc4OZlSZVZ+pWeT2iqbR7w1UPeO3mWSUO9 CQMqYNFhMt/AWZ4OJds/LIdWQwoqhEBnXyprVD5tm/w= 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=PbVAi7540Zwqb/So7tS4zwuS0z v8eK2YkrLVmjPO1zstNEzRaBj4KMo6EI9UXViARLXK1eVRz2Qz67wS2mhhUyMvNv wmCtXvnc2KR6VbltDZUfUrpBQGdiIT0M897ezd4Hj57/ek9JIIuTeGBjac1Ugbw6 45hP4YVNoDP79SYFc= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 74694D7882; Mon, 8 Feb 2016 00:59:48 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3379E10894FC; Mon, 8 Feb 2016 09:59:45 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_151B726C-E221-4CF1-9485-1CA8CD6DB6CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160207.143835.41645325.sthaug@nethelp.no> Date: Mon, 8 Feb 2016 09:59:44 +0100 Message-Id: References: <56B4E4FD.7010608@si6networks.com> <20160205.200348.74751017.sthaug@nethelp.no> <56B50759.1080109@si6networks.com> <20160207.143835.41645325.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.3112) Archived-At: Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 08:59:50 -0000 --Apple-Mail=_151B726C-E221-4CF1-9485-1CA8CD6DB6CD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >> just curious: why do you think IPv6 would make a different in this >> respect? -- because extracting such information can be difficult and >> hence everyone would shift to employing the flow-label, or something else? > > I actually *don't* think IPv6 will make a significant difference (at > least not until use of the flow label for entropy is *much* more > widespread). However, IPv4 doesn't have the luxury of the flow label, > and thus link aggregation entropy basically *must* be gained from L3 > and L4 info. what's the ratio of flow label = 0 to set flow labels in your network? anyone studied this over time? Best regards, Ole --Apple-Mail=_151B726C-E221-4CF1-9485-1CA8CD6DB6CD 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 iQIcBAEBCgAGBQJWuFkAAAoJEL7aWKiYQt92+kQQALarLHat01jzQoMkcOfVvhrg 8ZFLq6jKokYsWkuHNL2XsmGmjrzlcB8o4lOd7sxFe2D0vVxRSEW0tjBz1uRka8QV yEN3xlhS6YL3z/l/5cUZtInJrT8en2Ap36dNg/79auUnE4x3eEcZxISWNdtnlSnX aLew4fsmG2ViYXUsdb2zCuUqPFOayJvWogMLPhkoQzRYTYs4qSFFQw+H2XsmTjY6 QKs5FzoX8TpTC2r1dlUW18AigPlkiSzygxeZhA3zKkgZAxxhLT6i22qW+J9vDCnh KAJ8tALdbYPVM0h338v4VGJu5gngpGyBM0z9VZlIA3L1L+coIixlY2q9tWEyC69z kwP42GjxVTk6Lgu1PYefLDrJ+VIgQOT15VJnXfYd9jOB5KCL9zBKSjfTbF9IpUUL k/uLvRQj9towXLJFSy1tSORezy+PeQqDepnibbszkHhIbyMGaQXWwOnC+xVOHt9+ LTkc+w+BIcydpot5B08SNKyun/bdLFsSypI7fD87jmunI49Wnr2DcPwGPEDLU00E MiiM8uXLHvIsj+kDwt1AQHptmYXtbVf/GW/wlLswL6uR3j6eOLdkBKclvd3+0g5w eyYEB+ZuU4xqE70gIUyIYXPyCimXWoK43IZLeL0hzzGn7KF7C9API1m4ECgKmH+n fQbfbYBbrRNbU+ckkn2Q =pP0w -----END PGP SIGNATURE----- --Apple-Mail=_151B726C-E221-4CF1-9485-1CA8CD6DB6CD-- From nobody Mon Feb 8 05:46:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240CB1B2B5F for ; Mon, 8 Feb 2016 05:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP0kXSPTvqM6 for ; Mon, 8 Feb 2016 05:46:01 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5A20E1B2B5D for ; Mon, 8 Feb 2016 05:46:00 -0800 (PST) Received: (qmail 44931 invoked from network); 8 Feb 2016 13:45:58 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Feb 2016 13:45:58 -0000 Date: Mon, 08 Feb 2016 14:45:58 +0100 (CET) Message-Id: <20160208.144558.74710273.sthaug@nethelp.no> To: otroan@employees.org From: sthaug@nethelp.no In-Reply-To: References: <56B50759.1080109@si6networks.com> <20160207.143835.41645325.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:46:04 -0000 > > I actually *don't* think IPv6 will make a significant difference (at > > least not until use of the flow label for entropy is *much* more > > widespread). However, IPv4 doesn't have the luxury of the flow label, > > and thus link aggregation entropy basically *must* be gained from L3 > > and L4 info. > > what's the ratio of flow label = 0 to set flow labels in your network? > anyone studied this over time? Highly initial estimate: Flow label = 0 accounts for around 99% of the IPv6 traffic in my network. YMMV. Steinar Haug, AS 2116 From nobody Mon Feb 8 06:54:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE31B2C40 for ; Mon, 8 Feb 2016 06:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mccIlXIcJZZv for ; Mon, 8 Feb 2016 06:54:14 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002: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 7BBE91B2C8B for ; Mon, 8 Feb 2016 06:54:14 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id q190so103412204ywd.3 for ; Mon, 08 Feb 2016 06:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=jl35JAE54LhMkLoMvTRTwexCPZKD01ijy6/PySVsHHs=; b=FrWo2HNCFIWhuxjcOCRCQuIH8VsVQ9llvtQV7vwAMzKXl1dDk/gcXzj4MfoBfdI2kt KTToRJC1yLn051xPB1nOW8IXVnhZfCr9nZR/Z6NuglrSIwramR5jngEwgqtt9jx4XdE4 JTvKMs/4FhT3ypGr66AB8QrZM9LZxiF4K8PNZC3A8w/u7LmWerX2AwULyoT3/z3JPqcc gaHRF1wiDmLcrha8aXqCqJXZb5Tm37VKMzn1E2RFkKkuPzcS4T29pN7aCrpR1EKRNG// sixl1HUH1/LC4PHYOpFbZeAUyqi9WhaqimxwR5jjPk+mmp04WOE1rmeI37z/9pVXr21t nyiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=jl35JAE54LhMkLoMvTRTwexCPZKD01ijy6/PySVsHHs=; b=H4+VX+vcd289Vu0mpCo1uFFEntmBpsdZ20tGCeBbtGTRsHf84kvq60Y4Zh7z0anNVT xnhRMPmCu55VB3U1conHGHTSnnLLWYKnQFhxaUNi7HIhlAG5WbcJb/krm/CM8PV6szqK 0rh8pGoOA7kkf1VkoT83D9DV2pgH8n2QK1ihCoJTuqDzCD8U88AsRhjXiYgLfFYYoiWO uNAocz3EYDHciUqrEzdvU5VIGOcXSkbp+VPQPedI2GO7tOjRnciZuC6d1HlqVlFW9Ptd ElRGmV7cY5yYGgG5RTRPYdwW2uOsL2GgTMBhf0ccvMu6J44/uH371P6YlhwXQbnulm5/ KsGw== X-Gm-Message-State: AG10YOS7RMmaauqSdZZKq8iOPSuYmnJHMIyDtWOwaNaP/dMuLcvUHGkTb9jZmymqvigTUXvimtAG3nS8hcjM98Ki X-Received: by 10.129.102.10 with SMTP id a10mr15812171ywc.127.1454943253858; Mon, 08 Feb 2016 06:54:13 -0800 (PST) MIME-Version: 1.0 References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> In-Reply-To: <56B7B919.8090001@foobar.org> From: Warren Kumari Date: Mon, 08 Feb 2016 14:54:04 +0000 Message-ID: To: Nick Hilliard , Mark Smith Content-Type: multipart/alternative; boundary=001a11490b70d0bba2052b435fd1 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:54:16 -0000 --001a11490b70d0bba2052b435fd1 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 7, 2016 at 1:37 PM Nick Hilliard wrote: > Mark Smith wrote: > > You're allowed to override it's value if a host sets it to zero (and > > if you override it in *your* network when it isn't zero, nobody > > outside your network is going to know either). > > How are you going to do that in a useful way without inspecting L4 values? > > > Use the tool provided for the purpose, and insist that your LAG/ECMP > > vendor considers the flow label field in their load distribution > > function, as per the RFC. > > this is precisely the problem: it's not my vendor, it's someone else's > vendor. I'm transporting their packets over my link bundles. > > If these packets don't have a flow label set then it comes back to a > choice between poor quality load balancing (which affects me as a > transport provider) or else trying to inspect L4 info to either do > ad-hoc load balancing or to use that info to create a new flow label. > > Another thing to keep in mind with flow labels is that attackers can use them to steer traffic *in an existing connection*, which makes targeting a specific link easier. It you are an attacker, it is *much* simpler to start up a bunch of large flows and twiddle the flow label until you observe an effect (because you've managed to hash >N traffic onto an N sized link) than it it so guess achieve the same thing by fiddling with port numbers, etc - you have more time and feedback. Attackers *enjoy* filling individual links (it makes DoS easier), which is one of the reasons some vendors add a (per-LAG) nonce into the hash, and / or refuse to discuss the hash function - if attackers know the hash, they can preplan attack traffic that hashes to a given link.... W > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11490b70d0bba2052b435fd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Feb 7, 2016 at 1:37 PM Nick Hilliard <nick@foobar.org> wrote:
M= ark Smith wrote:
> You're allowed to override it's value if a host sets it to zer= o (and
> if you override it in *your* network when it isn't zero, nobody > outside your network is going to know either).

How are you going to do that in a useful way without inspecting L4 values?<= br>
> Use the tool provided for the purpose, and insist that your LAG/ECMP > vendor considers the flow label field in their load distribution
> function, as per the RFC.

this is precisely the problem: it's not my vendor, it's someone els= e's
vendor.=C2=A0 I'm transporting their packets over my link bundles.

If these packets don't have a flow label set then it comes back to a choice between poor quality load balancing (which affects me as a
transport provider) or else trying to inspect L4 info to either do
ad-hoc load balancing or to use that info to create a new flow label.


Another thing to keep in mind with flo= w labels is that attackers can use them to steer traffic *in an existing co= nnection*, which makes targeting a specific link easier.=C2=A0
It= you are an attacker, it is *much* simpler to start up a bunch of large flo= ws and twiddle the flow label until you observe an effect (because you'= ve managed to hash >N traffic onto an N sized link) than it it so guess = achieve the same thing by fiddling with port numbers, etc - you have more t= ime and feedback.
Attackers *enjoy* filling individual links (it = makes DoS easier), which is one of the reasons some vendors add a (per-LAG)= nonce into the hash, and / or refuse to discuss the hash function - if att= ackers know the hash, they can preplan attack traffic that hashes to a give= n link....

W

=C2=A0
=
Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a11490b70d0bba2052b435fd1-- From nobody Mon Feb 8 07:08:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08541B2CDD for ; Mon, 8 Feb 2016 07:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQR0WRkD_aKN for ; Mon, 8 Feb 2016 07:08:50 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 1F3481B2CDA for ; Mon, 8 Feb 2016 07:08:50 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g62so136789292wme.0 for ; Mon, 08 Feb 2016 07:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=KX14Mp9SiNvHYJNKQKzKp3WvMlz4pm+XrPGlvXqpWYk=; b=mMeKQS3Z/CxNqMgO2PMi6fxy1y1ew/uCKLc5oGtGSlTLAkwHlN0D6yF8FjKyZl+DG5 XaKg/UXayEY7lWl2exeVFlkTHkj5iPKMe3w3L+xrCBRqkxLgDBgN3xwZutJ5FFpVpu09 RAQPOZBFtSVFDrdIoh9qTK/e8+i4orvKefbDNmUKAXNX4edqiFWMbcs2HBqOAHLvKrWc sjvkh0dEloQW0DhHnW0cgwP5L7eXfUJgC7/K3djzoJvzeOKV8JGs9BbjayeHRF4GrZWV 4TISeS3GITLzeGlbGAWbQcyVubmSvtuFzCWSU2s9IhrrOI1CQ6Y8oZdihK8lmw2PctMF iUlw== 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 :content-type; bh=KX14Mp9SiNvHYJNKQKzKp3WvMlz4pm+XrPGlvXqpWYk=; b=eyO8nIF1rIdTzZovDYG8Ork4+LkQfpQBBmPoMdKiS4HfX0cVUPz/QZsIeJiB77f/Zc lfQARGgTJgtouGp5AdUaXGkgmckNL3kat8+r5ySGuFd2VIIiW7xxl/wwHKtiVUtpdoiU o2ejQGrD6BORtaLNs0Lk3jj7AeAiSikUtJyRSJzFWGWgV5lZNIL0JCU4cLSRQCkEbocM ImCYG6M406gG+ilsr6dHXBOXe82JVpOtdJAKWnSouflNkFmFXhEzwSFLVWn9asMuTiVA uc/binS10c67VAriQRGN/sehfVZfZTxeKyT8wIm8EFGYVFJrRi4r2DMFwnmJIr+Do0Ha 71fQ== X-Gm-Message-State: AG10YOTsOKiGj7eulN2Q14RugentZ8eHa83ORxp/rbtTIRABYf86MzSdcM9wy7L56cmAEo+sl6iwWQFFp1sazw== MIME-Version: 1.0 X-Received: by 10.28.5.203 with SMTP id 194mr12360652wmf.101.1454944128419; Mon, 08 Feb 2016 07:08:48 -0800 (PST) Received: by 10.27.179.7 with HTTP; Mon, 8 Feb 2016 07:08:48 -0800 (PST) Date: Mon, 8 Feb 2016 17:08:48 +0200 Message-ID: From: Saku Ytti To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:08:52 -0000 LARA[0] might have attractive properties in IPv6. Consider MAC address today has 46bits of usable bits, local scope must be set, multicast must be unset. IPv6 speaker could use some algorithm to produce 46 bits identifier and subsequently populate MAC address with it, and combine it with IPv6 prefix to produce IPv6 address. Obviously subnet can be larger than than 46bits, but that gives us another interesting advantage. Consider /64 subnet, where we have 64bits for hosts. This means ID is only sufficient to fill 46 of those hosts bits, and we'd be left with 18 unfilled host bits. Now router would forward all these 18 bits addresses to same 46bits identifier, i.e. same MAC address. This means every IPv6 host in LAN, now essentially have18 bits routed LAN, with 0 config on router. Feature which I've always thought is missing in IPv6. What is the point of having addresses, without having routing. The major problem I see with potential IPv6 implementation is how to produce that unique identifier, there needs to be some sort of DAD, but how do you do DAD when you can't rely on uniqueness of MAC? Do you first use BIA to do DAD before you choose your ID? What about co-existence of LARA and normal ND in same LAN, is it possible? Is it necessary? Can RA declare LAN to be LARA LAN? I hope the other benefits, than this automatic subnetting are more obvious and not needed to iterate. But it means stateless resolution, no ND exhaustion, no attack vectors, no unscalable multicast group in LAN, trivial and robust stateless 'IPSG/DAI'. [0] https://datatracker.ietf.org/doc/draft-eromenko-ipff-lara/ -- ++ytti From nobody Mon Feb 8 07:48:38 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0961B2D64; Mon, 8 Feb 2016 07:48:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208154835.5886.17242.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 07:48:35 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Considerations For Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-considerations-00.txt Pages : 17 Date : 2016-02-06 Abstract: This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them, The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-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/ From nobody Mon Feb 8 07:54:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1411C1B2D95 for ; Mon, 8 Feb 2016 07:54:40 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJSrxHeltdY3 for ; Mon, 8 Feb 2016 07:54:37 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E831B2D92 for ; Mon, 8 Feb 2016 07:54:37 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18FsRGC093060 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 15:54:28 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56B8BA32.3010505@foobar.org> Date: Mon, 08 Feb 2016 15:54:26 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> In-Reply-To: <56B83BB9.7040704@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:54:40 -0000 Joe Touch wrote: > - always assume that any method to dig into other layers not only can > fail, but should be avoided in the future because it is more likely to > fail as time goes by No, always assume that any method to dig into other layers not only can fail, but is likely to fail if EHs are present in the packet. Re: https://www.ietf.org/mail-archive/web/v6ops/current/msg21675.html (for posterity: "Date: Mon, 16 Mar 2015 09:29:35 +0100") It's too late to fix Steve Deering's intentions to make it hard for middleboxes to examine extension headers, but the design choice created a set of problems which are extremely difficult to deal with. Nick From nobody Mon Feb 8 07:54:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489C31B2D9B for ; Mon, 8 Feb 2016 07:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oo2AZqd7uUw for ; Mon, 8 Feb 2016 07:54:42 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 B990A1B2D97 for ; Mon, 8 Feb 2016 07:54:41 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id f81so198249212iof.0 for ; Mon, 08 Feb 2016 07:54:41 -0800 (PST) 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-type; bh=hXTrKOBl9Kt0lHW+QeGuxfQ5W966wtpPgm9aUSA8BD4=; b=gdaxk62eQqhpzQVkZ/HxAIxMSLVRWz3TZBVjWI2xWQs+YjPzdv9B2B0OatinZUtguF WCBeiRpAvU9xWiP8GQs766aL9I8YjowhZ8oD1QaiPOfqfGFoOLQO65dsmqdAGNUrTFfE sQ/BlwJx0skkIoiUiLowseAZ91IpUEHmOXGu7bbrjfZglIKLO94HfENhDGUrNDkoCZph mZF2sIZE9EIkHH83Bhn3DvQwhya/TrnmKmnAnz4ptAzEEwaOEecyR1af+t46EEZZH+na oFzTWRHerQTfoduPXFWaymrTKRlHTPnqjkClgO6vBhcsGqmqQvZXwvLgQDICVgXKtjk7 HNwA== 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-type; bh=hXTrKOBl9Kt0lHW+QeGuxfQ5W966wtpPgm9aUSA8BD4=; b=eCShkqWO2OioMOfh960C2XXx4jYi7FP9TPciwiqHFdkMqde5NkaK1rjfymMSdcBBkR 76mqdQG+FEeEbMYWtJIc/KqgIy9mQnRo5DNoROOv8v8MlSL8ce6Z53kvViq8hUT7ZeyF PYrDhruLRR3Ap5V1kJmT2Im0188R9H1AZm08FXfNf4CevFNA06ThA61RXBqVh6oBUodW E2B5oCGX7muomEoAOCoaUFDzbo7C4jm6XryDy78LvtNsGAzyY055CfuMQJo15B6nerjC 5jObV9sy3YOhl81zxp6qBLsqcRih4PUMY3R2FFGN7X9sCfQSXDVAkv67h19lQ4akOa3S fC1w== X-Gm-Message-State: AG10YOQltZ7w4TrAuoIkXACnja0gwmITzPm7Vk/ych+EiqiEzGf5gdWNwhZooX2c06jWlZUN28+A9hjuhWnxaw== MIME-Version: 1.0 X-Received: by 10.107.152.142 with SMTP id a136mr28890231ioe.84.1454946881131; Mon, 08 Feb 2016 07:54:41 -0800 (PST) Received: by 10.107.160.203 with HTTP; Mon, 8 Feb 2016 07:54:40 -0800 (PST) In-Reply-To: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> Date: Mon, 8 Feb 2016 16:54:40 +0100 Message-ID: From: Tom Herbert To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:54:43 -0000 On Mon, Feb 8, 2016 at 3:54 PM, Warren Kumari wrote: > > > On Sun, Feb 7, 2016 at 1:37 PM Nick Hilliard wrote: >> >> Mark Smith wrote: >> > You're allowed to override it's value if a host sets it to zero (and >> > if you override it in *your* network when it isn't zero, nobody >> > outside your network is going to know either). >> >> How are you going to do that in a useful way without inspecting L4 values? >> >> > Use the tool provided for the purpose, and insist that your LAG/ECMP >> > vendor considers the flow label field in their load distribution >> > function, as per the RFC. >> >> this is precisely the problem: it's not my vendor, it's someone else's >> vendor. I'm transporting their packets over my link bundles. >> >> If these packets don't have a flow label set then it comes back to a >> choice between poor quality load balancing (which affects me as a >> transport provider) or else trying to inspect L4 info to either do >> ad-hoc load balancing or to use that info to create a new flow label. >> > > Another thing to keep in mind with flow labels is that attackers can use > them to steer traffic *in an existing connection*, which makes targeting a > specific link easier. > It you are an attacker, it is *much* simpler to start up a bunch of large > flows and twiddle the flow label until you observe an effect (because you've > managed to hash >N traffic onto an N sized link) than it it so guess achieve > the same thing by fiddling with port numbers, etc - you have more time and > feedback. Is this a significantly worse attack than: 1) UDP attack with randomizing source port 2) TCP SYN attack with random source ports 3) Sending TCP/IPv6 packets with an EH so that devices fallback to doing 3-tuple hash? > Attackers *enjoy* filling individual links (it makes DoS easier), which is > one of the reasons some vendors add a (per-LAG) nonce into the hash, and / > or refuse to discuss the hash function - if attackers know the hash, they > can preplan attack traffic that hashes to a given link.... That's why hashes should be randomly keyed and the keys rotated periodically (I believe at least the first is commonly done?) Thanks, Tom > > W > > >> >> Nick >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 8 07:59:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4E1B2D78 for ; Mon, 8 Feb 2016 07:59:11 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6PshwU0XW0a for ; Mon, 8 Feb 2016 07:59:10 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396241B2D79 for ; Mon, 8 Feb 2016 07:59:10 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18Fx2NL093199 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 15:59:03 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <56B8BB45.2020208@foobar.org> Date: Mon, 08 Feb 2016 15:59:01 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:59:11 -0000 Tom Herbert wrote: > Is this a significantly worse attack than: 1) UDP attack with > randomizing source port 2) TCP SYN attack with random source ports yes, it is significantly worse. Randomised src/dst ports for tcp/udp floods will end up with ~equal load balancing. > 3) Sending TCP/IPv6 packets with an EH so that devices fallback to > doing 3-tuple hash? It is equivalently harmful as this. Having said that, lots of networks drop packets with extension headers. Nick From nobody Mon Feb 8 08:02:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E711B2DB2 for ; Mon, 8 Feb 2016 08:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b13ke3XSh08 for ; Mon, 8 Feb 2016 08:02:07 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 807861B2D9F for ; Mon, 8 Feb 2016 08:02:07 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g73so199297441ioe.3 for ; Mon, 08 Feb 2016 08:02:07 -0800 (PST) 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-type; bh=K+9GLsNhiP/wkZy1WiOAwKO5/eh7ALRhkZ1ws3X+w9E=; b=LgzQ/X6SwdogiJsrNyMoPIiAQ/yLTIvm1JFKcjunNRbUZjgMy87ySxNJuOzxkmwOHD iqo1MiQals5+z5aPRMPLQS14Vx9K8RH6muWGguPA9KLSaYqiNkOkMDXYpcQLPTBTG3ys vh7PVM38peUbfPhRqSKY6ujYD4ZIV6BlBOvq2o/wrgDfUze6LeBAd1cJ1Mklud+U7WRN j1soiO4gc/ODp43vqTEkZkTjsvJjo0liH0cH21MMcDfWFdWsqdo8dmfoZ5UYuoLt62lU GV3NXlAkbUElr/vnbevBYwT/aDHUG+vRqHrQDISxljlhMcHT7LXq6MN9VwTQeKnAXHyz j+Jg== 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-type; bh=K+9GLsNhiP/wkZy1WiOAwKO5/eh7ALRhkZ1ws3X+w9E=; b=GqKfCWBxigi/iGCtGGHXJ67QH1p0LaUeBwRmi3V4KTkir9T5mg37SpLXTE6/FdOfTq xqSGHm5E8Mx4uVE5rUDnnvINQSoF/vbYp1JDjQXyx9iVF2VgkQGq/qNrpnXe1OTEV9IF GgmMn1YM+6vaJukIAW2jRrhZx/epnylrkGOLJUHaOSyO1uUuFEHWu9/3hA2oSaVogwRz tcDlCa2aBbSNjzIQIs/ZW/w613Gc2xtWxVVwSg4lf4vXi7q/n0UZSPH5ve48pimXIeuQ ScjgEDsiW+eYoL6dyyss57FBb5/ROYjH71FCU4/0Rf2xxj9rZVo0gk02yw70w7rROnqh a34g== X-Gm-Message-State: AG10YOQuuUadWCkSG7yh79CTNKNkC8BpdkUJ03v8pXvN5Dc5ZCkTmhplVv8OcKjeLdFSb4MR16ranEL/mhpmtQ== MIME-Version: 1.0 X-Received: by 10.107.136.210 with SMTP id s79mr29200665ioi.50.1454947326880; Mon, 08 Feb 2016 08:02:06 -0800 (PST) Received: by 10.107.160.203 with HTTP; Mon, 8 Feb 2016 08:02:06 -0800 (PST) In-Reply-To: <56B8BB45.2020208@foobar.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B8BB45.2020208@foobar.org> Date: Mon, 8 Feb 2016 17:02:06 +0100 Message-ID: From: Tom Herbert To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:02:08 -0000 On Mon, Feb 8, 2016 at 4:59 PM, Nick Hilliard wrote: > Tom Herbert wrote: >> Is this a significantly worse attack than: 1) UDP attack with >> randomizing source port 2) TCP SYN attack with random source ports > > yes, it is significantly worse. Randomised src/dst ports for tcp/udp > floods will end up with ~equal load balancing. > Randomize was a poor choice of words, I meant using the source port to do probing like in flow label attack. >> 3) Sending TCP/IPv6 packets with an EH so that devices fallback to >> doing 3-tuple hash? > > It is equivalently harmful as this. > > Having said that, lots of networks drop packets with extension headers. > > Nick > From nobody Mon Feb 8 08:03:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97051B2D8A for ; Mon, 8 Feb 2016 08:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHomtU4YBTme for ; Mon, 8 Feb 2016 08:03:41 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689AF1B2D89 for ; Mon, 8 Feb 2016 08:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3525; q=dns/txt; s=iport; t=1454947421; x=1456157021; h=from:to:subject:date:message-id:references:mime-version; bh=60D4nBK6/V/QoBbNoxI6qriRrE9oTps21Hf26CQQPAc=; b=OTPjgTT9zxfelvj9rZYOGayn3EWm7BXRkSBexLShdswQ17tpdVrGl3Ub rK7ciY8a4Lj1ZkGv8XUKveN3kzVLMHyHmF4PoN7Dtggds7etOzPzWfr1E LwyUV3J/NpWu5x5m+JhEPTuj6RzRWYCArgOxuUqcM9MXoUDdgQ65Z0C1m I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AgDOu7hW/4sNJK1egzpSbQaIVbELD?= =?us-ascii?q?oFmFwyFagKBLjgUAQEBAQEBAX8LhEEBAQEDAQEBAWsQCwIBGQMBAi8nCxQHAgg?= =?us-ascii?q?CBBMJBYgFCA68dAEBAQEBAQEBAgEBAQEBAQEBAQ8Ih38IgkKEUhKCFksYgQ8Fk?= =?us-ascii?q?m6EBwGCfYFkaogEgVtKg3mIVYcOhy8BHgFDg2RqAYdWfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="asc'?scan'208";a="74062922" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 16:03:40 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u18G3e2c002703 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Feb 2016 16:03:40 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 10:03:39 -0600 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.1104.009; Mon, 8 Feb 2016 10:03:39 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt Thread-Index: AQHRYopGxuIO6tR8OU60AtCwTkm6jw== Date: Mon, 8 Feb 2016 16:03:39 +0000 Message-ID: References: <20160208154835.5886.17242.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.122] Content-Type: multipart/signed; boundary="Apple-Mail=_99785B59-B0CA-4F14-800A-F9CB6CF3148E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:03:43 -0000 --Apple-Mail=_99785B59-B0CA-4F14-800A-F9CB6CF3148E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bing is trying to revive the ULA discussion with a draft intended to = objectively discuss both sides of the debate we have had in this = context. Not arguing pro or con, but stating both views ("ULAs are evil = and imply NAT" and "ULAs are useful in identified cases that don't = involve NAT"). Commentary appreciated. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt > Date: February 8, 2016 at 7:48:35 AM PST > To: > Cc: v6ops@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations of the IETF. >=20 > Title : Considerations For Using Unique Local = Addresses > Authors : Bing Liu > Sheng Jiang > Filename : = draft-ietf-v6ops-ula-usage-considerations-00.txt > Pages : 17 > Date : 2016-02-06 >=20 > Abstract: > This document provides considerations for using IPv6 Unique Local > Addresses (ULAs). Based on an analysis of different ULA usage > scenarios, this document identifies use cases where ULA addresses = are > helpful as well as potential problems caused by using them, >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations= / >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-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 --Apple-Mail=_99785B59-B0CA-4F14-800A-F9CB6CF3148E 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 iQIVAwUBVri8XkayAOS/EQ8MAQK21Q//boAP6sL6uFahzUt7A9AAyTHYSxrn4NQ+ +9LD7kXI4esMLSoQVNxrJx+wBiO0adMQ8zRgwIK23R8M2eVkceI/FYdn/oOlpD+1 mpOxQfqoQkjnItzC04zTLyFjsHO2sf1fp2uLTvi3xlvFRVCmYiorCuvEaXqFSP+I yjdVz4scoapwtASBQpLzBpRh+pose1F21J5eWZzfrDtiJj7z79Eix42M0bR4t6H/ GushVlilj5qlEPDDUyNED4l/5oOYJXtdJbLg7ri38rmuQaasGlorrAVl7UH2JUd7 FmqD1j3JTywWY0W1TL3SnOPbGr6ZL9QuFh/MJd1JC7BJTu05+sJM+VOPgibgZbvG PYhEkx/qkrowjeRlmcRC581c7oTnJkarzp6eEd5JVl05xbxWOuwi5BkG2DLktHkO 7u+Bl514slv4EyVJqezRbR2wCAefRDEz0FYsGTA5mwStIz02UgrTgNTJRsTj7S3U Nr8pjO59B4gyqjVdbJ+7+OiQR1miCYOgPWOBOdKPWxfsw7Z7fBgehtq+FNiCAMag WgRkGLUMdpyDVTgaBPd6Lw032CCmITUHA1YQedqypuwk6IsgPGgf9HlTNo0wdocX Z+gSzjMHltOtS47bzmMf2Xt51LDjzzA8z1jTSChgjJpWOm6kaRZCUcVAotf+VQa/ 4jBbGP/O6c4= =MoM/ -----END PGP SIGNATURE----- --Apple-Mail=_99785B59-B0CA-4F14-800A-F9CB6CF3148E-- From nobody Mon Feb 8 08:27:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D901B2E9D for ; Mon, 8 Feb 2016 08:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPFaNFUkqVTs for ; Mon, 8 Feb 2016 08:27:40 -0800 (PST) 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 99B8C1B2AEA for ; Mon, 8 Feb 2016 08:27:40 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id g127so105618648ywf.2 for ; Mon, 08 Feb 2016 08:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=pGJ9798Dr9eCj2YbIA4Qtukg29erDEGce1fV+fAzalE=; b=ZZgsBOtkLc9301Tgbg8aBFLms5UiM7TrjrbLDmWFW7hoPaP7xOLKLJtnZJfua7ACdv PMiMi1cOgvZNXt08nxF4aYIoi7fQ8KQvpcJnDXwUD6bWczEFGRZxu3XmA0BWmW3Tk/kl LO8rJe6Cj0GMyIh4djp2RkpOAkejPfcH+yD6mp8ciwkz8qTHkPJ3hrnj/0ksdqIYoyz6 Qa5rt8GJqTvP6QIZNNt/LdGmkGuoS7DA9qk2TLLi4ggdNpB6f/cr3LVPAItbRBAlq1yl wGrSRaOVyHMx/PueVKXAKruIZLnhi12KdqCUOqnDtdUIVgjZuOvnUN2sob68XLoL9SgM Qc7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=pGJ9798Dr9eCj2YbIA4Qtukg29erDEGce1fV+fAzalE=; b=Vo6dMw58YYKeKZyzyHn6ePsax2Zorw/lNLTrCDtXWDX7+xQhk2m4rb6bJZLgNbwPY9 2v/ocn/7SzG4uMrq9+nQRQuDea5xxum1zEHWQGmz/UYPzmcWDXg4aLxjnRebCbcJZsUz 4alel7hiGMMsZMsKnx3WJM1tiQAVqChZqefGl4CcU6RKpaBHoeTgrb06PEekIRedDLw3 idSNiCSR8sUpnhvlaHuO2dJjmti/vgLieAuHDdV9TyoNI3RtXiShOQ2SzmjUJAfmM5UX RNPd6f9m300dnVI74nDFPswU9bby8Z9lWfGW8w35qTLOa/MYvHNm4HS7nwHDrSqxc07Y iAzg== X-Gm-Message-State: AG10YOSJOAXMfWfmwCGQ/8H7zanKQevqmuY0oAMMZ0kUgTmrpBtQsXSzg03pcFeETGLGvK8aRIRnHCcNdFk6iWzR X-Received: by 10.129.145.82 with SMTP id i79mr14578726ywg.345.1454948859831; Mon, 08 Feb 2016 08:27:39 -0800 (PST) MIME-Version: 1.0 References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> In-Reply-To: From: Warren Kumari Date: Mon, 08 Feb 2016 16:27:30 +0000 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=94eb2c093a3ef51487052b44ad6b Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:27:43 -0000 --94eb2c093a3ef51487052b44ad6b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 8, 2016 at 7:54 AM Tom Herbert wrote: > On Mon, Feb 8, 2016 at 3:54 PM, Warren Kumari wrote: > > > > > > On Sun, Feb 7, 2016 at 1:37 PM Nick Hilliard wrote: > >> > >> Mark Smith wrote: > >> > You're allowed to override it's value if a host sets it to zero (and > >> > if you override it in *your* network when it isn't zero, nobody > >> > outside your network is going to know either). > >> > >> How are you going to do that in a useful way without inspecting L4 > values? > >> > >> > Use the tool provided for the purpose, and insist that your LAG/ECMP > >> > vendor considers the flow label field in their load distribution > >> > function, as per the RFC. > >> > >> this is precisely the problem: it's not my vendor, it's someone else's > >> vendor. I'm transporting their packets over my link bundles. > >> > >> If these packets don't have a flow label set then it comes back to a > >> choice between poor quality load balancing (which affects me as a > >> transport provider) or else trying to inspect L4 info to either do > >> ad-hoc load balancing or to use that info to create a new flow label. > >> > > > > Another thing to keep in mind with flow labels is that attackers can use > > them to steer traffic *in an existing connection*, which makes targeting > a > > specific link easier. > > It you are an attacker, it is *much* simpler to start up a bunch of large > > flows and twiddle the flow label until you observe an effect (because > you've > > managed to hash >N traffic onto an N sized link) than it it so guess > achieve > > the same thing by fiddling with port numbers, etc - you have more time > and > > feedback. > > Is this a significantly worse attack than: 1) UDP attack with > randomizing source port 2) TCP SYN attack with random source ports 3) > Sending TCP/IPv6 packets with an EH so that devices fallback to doing > 3-tuple hash? > > Perhaps, perhaps not. Managing to get all of your attack traffic onto a single LAG member means that you only need N bps of attack traffic to cause issues, not N * M bps (where N is the size of the LAG members, and M is the number) - you steer all of your traffic onto one link, saturate it and then wait. Usually LACP will fail, and the link falls out of the bundle - you now steer onto the next link (keeping in mind that the bundle now has less bandwidth), lather, rinse, repeat. If you have a number of long lived TCP flows, and can steer their LAG assignment by twiddling flow labels (without changing anything else) you get good telemetry (the stack even does some nice stats collections for you!), and so tell when you have gotten a bunch of flows to hash onto the same link. A UDP / TCP SYN attack doesn't provide you with nearly as much feedback to know when you are hashing onto the same link. You *can* achieve similar results by making lots of TCP connections and choosing the source port yourself, but this is much more time consuming, not nearly as convenient, requires mote flows, and shows up more in analysis.... > > Attackers *enjoy* filling individual links (it makes DoS easier), which > is > > one of the reasons some vendors add a (per-LAG) nonce into the hash, and > / > > or refuse to discuss the hash function - if attackers know the hash, they > > can preplan attack traffic that hashes to a given link.... > > That's why hashes should be randomly keyed and the keys rotated > periodically (I believe at least the first is commonly done?) > Vendors are very reluctant to talk about their hashing strategies - some do include a nonce / key but I'm not sure if anyone rotates this in use - it would cause some sloshing... The "hashing: that vendors use is actually often quite complex - for example, even if you have lots of small flows, with lots of entropy, you often get distinctly unbalanced links. Some vendors also *appear* to try hard to keep traffic on a link it is already hashed to - and so if a new link is added, it seems to run significantly "cooler"quite a while. This is one of those things that doesn't really seem to make sense[0], but does show up in practice. W [0]: How can you do this without having to keep state? > > Thanks, > Tom > > > > > W > > > > > >> > >> Nick > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --94eb2c093a3ef51487052b44ad6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Feb 8, 2016 at 7:54 AM Tom Herbert <tom@herbertland.com> wrote:
On Mon, Feb 8, 2016 at 3:54 PM, Warren Kumari <warren@kumari.net> wrote:
>
>
> On Sun, Feb 7, 2016 at 1:37 PM Nick Hilliard <nick@foobar.org> wrote:
>>
>> Mark Smith wrote:
>> > You're allowed to override it's value if a host sets = it to zero (and
>> > if you override it in *your* network when it isn't zero, = nobody
>> > outside your network is going to know either).
>>
>> How are you going to do that in a useful way without inspecting L4= values?
>>
>> > Use the tool provided for the purpose, and insist that your L= AG/ECMP
>> > vendor considers the flow label field in their load distribut= ion
>> > function, as per the RFC.
>>
>> this is precisely the problem: it's not my vendor, it's so= meone else's
>> vendor.=C2=A0 I'm transporting their packets over my link bund= les.
>>
>> If these packets don't have a flow label set then it comes bac= k to a
>> choice between poor quality load balancing (which affects me as a<= br> >> transport provider) or else trying to inspect L4 info to either do=
>> ad-hoc load balancing or to use that info to create a new flow lab= el.
>>
>
> Another thing to keep in mind with flow labels is that attackers can u= se
> them to steer traffic *in an existing connection*, which makes targeti= ng a
> specific link easier.
> It you are an attacker, it is *much* simpler to start up a bunch of la= rge
> flows and twiddle the flow label until you observe an effect (because = you've
> managed to hash >N traffic onto an N sized link) than it it so gues= s achieve
> the same thing by fiddling with port numbers, etc - you have more time= and
> feedback.

Is this a significantly worse attack than: 1) UDP attack with
randomizing source port 2) TCP SYN attack with random source ports 3)
Sending TCP/IPv6 packets with an EH so that devices fallback to doing
3-tuple hash?


Perhaps, perhaps not.

Managing to get all of your attack traffic onto a single LAG membe= r means that you only need N bps of attack traffic to cause issues, not N *= M bps (where N is the size of the LAG members, and M is the number) - you = steer all of your traffic onto one link, saturate it and then wait. Usually= LACP will fail, and the link falls out of the bundle - you now steer onto = the next link (keeping in mind that the bundle now has less bandwidth), lat= her, rinse, repeat.=C2=A0

If you have a number of = long lived TCP flows, and can steer their LAG assignment by twiddling flow = labels (without changing anything else) you get good telemetry (the stack e= ven does some nice stats collections for you!), and so tell when you have g= otten a bunch of flows to hash onto the same link.=C2=A0

A UDP / TCP SYN attack doesn't provide you with nearly as much f= eedback to know when you are hashing onto the same link. You *can* achieve = similar results by making lots of TCP connections and choosing the source p= ort yourself, but this is much more time consuming, not nearly as convenien= t, requires mote flows, and shows up more in analysis....

=C2=A0
> Attackers *enjoy* filling individual links (it makes DoS easier), whic= h is
> one of the reasons some vendors add a (per-LAG) nonce into the hash, a= nd /
> or refuse to discuss the hash function - if attackers know the hash, t= hey
> can preplan attack traffic that hashes to a given link....

That's why hashes should be randomly keyed and the keys rotated
periodically (I believe at least the first is commonly done?)

Vendors are very reluctant to talk about their hashi= ng strategies - some do include a nonce / key but I'm not sure if anyon= e rotates this in use - it would cause some sloshing...
The "= ;hashing: that vendors use is actually often quite complex =C2=A0- for exam= ple, even if you have lots of small flows, with lots of entropy, you often = get distinctly unbalanced links. Some vendors also *appear* to try hard to = keep traffic on a link it is already hashed to - and so if a new link is ad= ded, it seems to run significantly "cooler"quite a while. This is= one of those things that doesn't really seem to make sense[0], but doe= s show up in practice.=C2=A0

W
[0]: How = can you do this without having to keep state?=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Thanks,
Tom

>
> W
>
>
>>
>> Nick
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>
--94eb2c093a3ef51487052b44ad6b-- From nobody Mon Feb 8 11:19:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A741ACEBF for ; Mon, 8 Feb 2016 11:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFgYYvEReOIH for ; Mon, 8 Feb 2016 11:19:30 -0800 (PST) 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 E7A0D1B31D3 for ; Mon, 8 Feb 2016 11:19:29 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id o185so114049857pfb.1 for ; Mon, 08 Feb 2016 11:19:29 -0800 (PST) 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-type :content-transfer-encoding; bh=pXL/Wzxuji2lG5J3kcMJQV01T6kCkmtsFknnH3VOES8=; b=y9vFoGzn24LmHXDS5dOkTYDJGUFwGJNx7eawsLHUiYiRq+jvTqn2x8WDAmZD6K8c+J dvZwxHqtzS5iHFIXu6/X0JTk6XUtPiXXHbsvoAof1LNGdPOnFz55vQ6V4/ba8sYQUh5A J1gTOQCXPq3ZHNteYrotXibkF7ZgTlfErK0uEUBkliQi22RfO0YYYTO0yCyOBW8sP0gD gHCESMKrCpHqeOqoN2pzbny4H5XtQ0e3P4LYzUg/CpOtY91PsFWuJxTeBSXMF3ezGdGi wlLzYIv9itHJQKjQ4f2sc9heh5BVU0n8ihohmWoQ8Pm4g2w91RPDIpxC8CqHrTO+QM/D t8VQ== 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-type :content-transfer-encoding; bh=pXL/Wzxuji2lG5J3kcMJQV01T6kCkmtsFknnH3VOES8=; b=iCNu77nF4rj4wlzcbS77SzXenkEnFrRk1TAwwYaw6OE6ojYBDN35nBAupF17oMFKe7 2odxdpvcl1r3YIx41wxv15IwSmxbSARbAZ5IHDHdxEV+ylu1a9yoNhUaPU1yfYaaWsHC 0lrVcYXmbbvkkmioC4ej7By45HRVqMtiwt8qMCnQiAJNNdYshSUlU0waHPjsYEDNeJLp +XEM+xxS5bdEYgjhQHGe4TRF+hecS//GlTRtlVsYM0kYUfnYNQrhfa+49qa4SRYmJmVo 5sf54pKEjI6GyboyMj78az1h9KctlsrCWFZMKiQFOlhzrc1z+NLn91ysETdvb1lvuJ/D UIuw== X-Gm-Message-State: AG10YOQqy0WzWjIkv/ETK17q1P/VG/KwH5WwWTscOVg7apEj/z0Dy0O5MOoHsmze3oPoEw== X-Received: by 10.98.33.70 with SMTP id h67mr43846204pfh.54.1454959169641; Mon, 08 Feb 2016 11:19:29 -0800 (PST) Received: from ?IPv6:2406:e007:67f3:1:28cc:dc4c:9703:6781? ([2406:e007:67f3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e14sm45251346pap.24.2016.02.08.11.19.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 11:19:27 -0800 (PST) To: Joe Touch , Nick Hilliard , Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B8EA3F.2070505@gmail.com> Date: Tue, 9 Feb 2016 08:19:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B83BB9.7040704@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:19:31 -0000 On 08/02/2016 19:54, Joe Touch wrote: > Hi, all, > > I get the impression the most useful way forward is: > > - use the flow field where it is available and nonzero (i.e., follow > available intent where indicated) > > - if you have to dig it out from other layers, use it to fill in a flow > label if it's available There are some restrictions on middleboxes doing that in RFC 6437. On 08/02/2016 21:59, otroan@employees.org wrote: ... > what's the ratio of flow label = 0 to set flow labels in your network? > anyone studied this over time? We're planning for the long term here. While I agree that this is a very interesting question, we shouldn't base future practice on it. On 09/02/2016 05:27, Warren Kumari wrote: ... > > Managing to get all of your attack traffic onto a single LAG member means > that you only need N bps of attack traffic to cause issues, not N * M bps > (where N is the size of the LAG members, and M is the number) - you steer > all of your traffic onto one link, saturate it and then wait. Usually LACP > will fail, and the link falls out of the bundle - you now steer onto the > next link (keeping in mind that the bundle now has less bandwidth), lather, > rinse, repeat. > > If you have a number of long lived TCP flows, and can steer their LAG > assignment by twiddling flow labels (without changing anything else) you > get good telemetry (the stack even does some nice stats collections for > you!), and so tell when you have gotten a bunch of flows to hash onto the > same link. Interesting. This wasn't really in scope for RFC 6438. We covered some related points in the security considerations of RFC 7098 (Flow Label for Load Balancing in Server Farms) but maybe this needs writing up. Brian From nobody Mon Feb 8 11:35:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8601B3236 for ; Mon, 8 Feb 2016 11:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGzezhZjhRDv for ; Mon, 8 Feb 2016 11:35:09 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 111661B3237 for ; Mon, 8 Feb 2016 11:35:09 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id c3so55997283vkb.3 for ; Mon, 08 Feb 2016 11:35:09 -0800 (PST) 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-type; bh=4fMemqS2kB1rvS+HOSjrlE3z1CieUjxoUS0h4KL+zPI=; b=uGASUxyiQjmaG+SynqKa2WHf97fqe2WddQIBgjIR8SUP7wbycdPJm5V/xjIAqCKK0z 3R/iVS36VQVBF/GES2eJ3fbwqi/cUi5wmBtC59VPn4dKkBYB7vyZETdGvvqgLYVt3rCm azOlyGYSYRORtUQjglWtD1ye8e5rVSQb7BoHCdeElMSjcg5i0EhTIFzQS73Fr4Z5CnMm OIBqF1TiPU2R0xDyJdyUA1+52JDS47UwF3VQdFaMScjfSBM+oa3ObL6M6Fy2tA4ChoY4 1JfbiAYPa3QGha4HJes8fXCws4HR8mFFlUmSr/TvvqzK8zahZ1Aoz6X/PjBFKjFgKv09 DfVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4fMemqS2kB1rvS+HOSjrlE3z1CieUjxoUS0h4KL+zPI=; b=IYBFEzcEdwlExnO2gCuA1W9rYq8iEGX5vDCHkulit7bY6q2Y56KRCkyN/lE4xONxbB ngNwXdSZwqIp/a1FQu5fy7d1ny5DdTEV85u41g+NGhsKp7RS7FXqYmS+Sww3DV3tg8TL md2XpZ4vVPLRRGZ+ASDwqEfNz0fORyqh1tpkUSNFy5NuyR2ziTRURZIvugnLhhLVbPY1 qXhk7Bt9jmnbaHygW362tQq6be8SXFVgYzlpNzbOOSpW6Bw+gku9ZrfXMh0fBYKJnHKt 8biQH9Gmd5UB6BnGqoPhgU6CT3AdsoQ0D/pDcuPktx+pkPPZ/EJc9j7iPE25hphmQpKC 7QAA== X-Gm-Message-State: AG10YOQ/pPmfjYica9Pb89jeW9rLIyevthaaPumHhKP+VHyISoAJhA+1suAcnJOXiZvVqJ5gsuyX61OfjcVeQw== X-Received: by 10.31.107.1 with SMTP id g1mr22378974vkc.15.1454960108134; Mon, 08 Feb 2016 11:35:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Mon, 8 Feb 2016 11:34:38 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Tue, 9 Feb 2016 06:34:38 +1100 Message-ID: To: Saku Ytti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:35:10 -0000 On 9 February 2016 at 02:08, Saku Ytti wrote: > LARA[0] might have attractive properties in IPv6. > > Consider MAC address today has 46bits of usable bits, local scope must > be set, multicast must be unset. > IPv6 speaker could use some algorithm to produce 46 bits identifier > and subsequently populate MAC address with it, and combine it with > IPv6 prefix to produce IPv6 address. > So this looks to be basically a re-invention of how DECnet Phase IV did layer 3 to layer 2 - search for "HIORD". "DECnet, DIGITAL Network Architecture, Routing Layer Functional Specification, Version 2.0.0, May 1983" http://linux-decnet.sourceforge.net/docs/route20.txt One of the drawbacks, which is probably a show stopper, is that it limits the number of layer 3 addresses on a link to the maximum number of layer 2 addresses supported on a link. While links with large numbers of layer 2 addresses are common, tightly coupling the size of the layer 3 address space on a link to the size of the available layer 2 address space is probably an unacceptable layer 3 limitation. > Obviously subnet can be larger than than 46bits, but that gives us > another interesting advantage. Consider /64 subnet, where we have > 64bits for hosts. This means ID is only sufficient to fill 46 of those > hosts bits, and we'd be left with 18 unfilled host bits. > Now router would forward all these 18 bits addresses to same 46bits > identifier, i.e. same MAC address. > This means every IPv6 host in LAN, now essentially have18 bits routed > LAN, with 0 config on router. Feature which I've always thought is > missing in IPv6. What is the point of having addresses, without having > routing. > > The major problem I see with potential IPv6 implementation is how to > produce that unique identifier, there needs to be some sort of DAD, > but how do you do DAD when you can't rely on uniqueness of MAC? Do you > first use BIA to do DAD before you choose your ID? > What about co-existence of LARA and normal ND in same LAN, is it > possible? Is it necessary? Can RA declare LAN to be LARA LAN? > > I hope the other benefits, than this automatic subnetting are more > obvious and not needed to iterate. But it means stateless resolution, > no ND exhaustion, no attack vectors, no unscalable multicast group in > LAN, trivial and robust stateless 'IPSG/DAI'. > > > [0] https://datatracker.ietf.org/doc/draft-eromenko-ipff-lara/ > -- > ++ytti > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 8 11:45:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7881A1A6B for ; Mon, 8 Feb 2016 11:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXGfJivbooeo for ; Mon, 8 Feb 2016 11:45:14 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 4AFD71A1A59 for ; Mon, 8 Feb 2016 11:45:14 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g62so147273185wme.0 for ; Mon, 08 Feb 2016 11:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cKhYg06bYk3o9pFwFMeaXdR8b+HSckpNEsbgjiIL1NI=; b=G0q76BSom9qEHxi8dXp94Tstcgnd+qYGn1fLLysutSrUsRWceRoh0YWUpez2zh+6Ft DW6It8D7Y15yQC5GZGisU3HIwrs8Q00xM66GR6pZzROijuLiCPQiKtrXAyzsW8bGB/Pz oP8UcFpHcLG2rr+xnENdAx9Q0pf8HB0RlG56bkEldnjJjAWnKg07T5YFVUXCT36h73YK 3bYnJaZQB9FhWRLvjtM9U2LV2Z90LuYqXJOjwkx0Z7VlZN77xwN8zMFuHEx6Fp5M0Mvl 7M4K4uNQ/8/qSiHqqmssvF007xE9BDn8lgsxrxyhyIATPazHUdD8cBcFqXZ2dLD85uZY 9ecw== 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-type; bh=cKhYg06bYk3o9pFwFMeaXdR8b+HSckpNEsbgjiIL1NI=; b=UhK9BiTZHDX7SY8ns7qlcWynMFkTryz3WlfnCwF+aqe+/5PHUSMxoZRihK2z2h591z 7+fPB5OGbTOZ80aA8Y0aSUqxEYNPGOUumhfJ9CSeVLDY4KY3mqqMU8PnnyYN99PQcL9v UaQDH4aZq6LA1266f+rlVJ3Fm9OPI4VL3v1pa9GxiMDet1593dehR7BbA0otRSuR9vbU 1+O3VkHB/qhk28TTRoClY+UXK5wV44AWbyXAW5Ai3XbR0/F5B5Errib4Ye7qNknTqaef rvfN9a6itViTJRcDVhLHUUGYAhDWGXLiNL+UjK3i+gp4fBpItqFXmnw+dfe1y1NN8QK+ qoRA== X-Gm-Message-State: AG10YOTRv2ZdWpfZe3lh0G8zN3PXqI/r83pzKzaNbl6qkRKabpg6Dt1RFU1uWQA/Dlzyku2dh7hT5A3OW9ALFA== MIME-Version: 1.0 X-Received: by 10.28.90.133 with SMTP id o127mr554539wmb.101.1454960712844; Mon, 08 Feb 2016 11:45:12 -0800 (PST) Received: by 10.27.179.7 with HTTP; Mon, 8 Feb 2016 11:45:12 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Feb 2016 21:45:12 +0200 Message-ID: From: Saku Ytti To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:45:15 -0000 On 8 February 2016 at 21:34, Mark Smith wrote: > One of the drawbacks, which is probably a show stopper, is that it > limits the number of layer 3 addresses on a link to the maximum number > of layer 2 addresses supported on a link. While links with large > numbers of layer 2 addresses are common, tightly coupling the size of > the layer 3 address space on a link to the size of the available layer > 2 address space is probably an unacceptable layer 3 limitation. Can you elaborate on the problem? I think it only limits that every L3 subnet will have same identifier (can be different size L3 network though). -- ++ytti From nobody Mon Feb 8 11:49:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341BB1B325D for ; Mon, 8 Feb 2016 11:49:35 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHZhpvBZQ39t for ; Mon, 8 Feb 2016 11:49:32 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF271B3259 for ; Mon, 8 Feb 2016 11:49:32 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u18Jn5W4028962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 11:49:05 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> From: Joe Touch Message-ID: <56B8F12F.30307@isi.edu> Date: Mon, 8 Feb 2016 11:49:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B8BA32.3010505@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u18Jn5W4028962 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:49:35 -0000 On 2/8/2016 7:54 AM, Nick Hilliard wrote: > Joe Touch wrote: >> - always assume that any method to dig into other layers not only can >> fail, but should be avoided in the future because it is more likely to >> fail as time goes by > > No, always assume that any method to dig into other layers not only can > fail, but is likely to fail if EHs are present in the packet. My point is that EHs aren't the only issue, and thus deprecating EHs is a temporary fix that isn't justified by this issue. ... > It's too late to fix Steve Deering's intentions to make it hard for > middleboxes to examine extension headers, but the design choice created > a set of problems which are extremely difficult to deal with. Well, I could turn it around and say that if it "hurts" when you do that (i.e., use middleboxes), then perhaps the problem lies in what you're trying to do, not what gets in its way. I.e., middleboxes are the design choice that has caused that problem. Joe From nobody Mon Feb 8 13:00:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163AC1B331E for ; Mon, 8 Feb 2016 13:00:57 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVBucQ29-cpi for ; Mon, 8 Feb 2016 13:00:55 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02EC1B3323 for ; Mon, 8 Feb 2016 13:00:54 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18L0pid000988 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 21:00:51 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B90202.9070603@foobar.org> Date: Mon, 08 Feb 2016 21:00:50 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> In-Reply-To: <56B8F12F.30307@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:00:57 -0000 Joe Touch wrote: > My point is that EHs aren't the only issue, and thus deprecating EHs is > a temporary fix that isn't justified by this issue. we need to agree to disagree on this then. The draft only attempts to raise awareness of some operational issues. > Well, I could turn it around and say that if it "hurts" when you do that > (i.e., use middleboxes), then perhaps the problem lies in what you're > trying to do, not what gets in its way. > > I.e., middleboxes are the design choice that has caused that problem. Could you read the draft and comment on the issues that it raises? Nick From nobody Mon Feb 8 13:18:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E91B2F61 for ; Mon, 8 Feb 2016 13:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDuPgATEsnSi for ; Mon, 8 Feb 2016 13:18:09 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 CCD6B1ACEF1 for ; Mon, 8 Feb 2016 13:17:59 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e6so104175853vkh.2 for ; Mon, 08 Feb 2016 13:17:59 -0800 (PST) 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:content-type; bh=4VtNprEzLPD8biV3lKLNZNoe0bnUpYNjpMN4wFas6Lc=; b=gxn3QkHQb/RsLZBIK/N3FLfF5oaZmLzPo1FrfsXHZt0a4Ht+QQdYDf1MEkJgLvPmRL 1CQyibZMNWQ46lX+3QKIgKl1SevvlRPLKEReMl0/XDQbQ/MqKDAW2ufLov7shi7G7J0Y 5jXRG84PBt+qIQgQ33G+w4ey+PiGtiJx4lW3jXKeEmnT/hyT+nZXZYCF/NJ4hYya+E0G SGNgHf6ai8QX5RM9NqzPQjElgEyKvnGcSCNG/2muOTS4taIgMBcdzllFUcip10My6IeM Xwrum/azQfQJyfutYCRcjCbqCwvDlNVTsfuLTp3h2xaFdfvKQaoixxfEhaZvJaHnIGAr oZdw== 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-type; bh=4VtNprEzLPD8biV3lKLNZNoe0bnUpYNjpMN4wFas6Lc=; b=LmimYb4JusfYDGLKDX8BHOyTe29/gK6vZk2jqqkpG/V3P5rgL5T2Ac1Lz/hvSusGDl UejJfTGv13Ffr6LqorZLCjiSjpuc7uArK8Wj7R/lXFR3gK9vuIaGN3df9v5h/LYQxmFo DUoHVua6qC6jEgC5u7aQWMJU/zwtT0PMuC2uLfadfPyU1jYQ0N9dkKgN6ibdJ/OS5N1L pFCRwWYR2kNR21eWQXtpOtz2KB6HgqK00lV/7ff08GaU5JP8/E1ldrgLcV6/Dwfh1r/a TNT+4s9+A56S1T702fnp4M7WMn1nAEHmWpTjbxxcNR9PqNLuGqyGrAjuGWUREOwsD5Cz 67gA== X-Gm-Message-State: AG10YOSu2HbrToPDTTA0p+OmQJAaWoJPM3HtvnNPIRshDL0d14L9/52fAOLdFsqWaEr8U16CNJTwMaNgVPcLtQ== MIME-Version: 1.0 X-Received: by 10.31.107.1 with SMTP id g1mr22758293vkc.15.1454966278922; Mon, 08 Feb 2016 13:17:58 -0800 (PST) Received: by 10.159.34.103 with HTTP; Mon, 8 Feb 2016 13:17:58 -0800 (PST) Received: by 10.159.34.103 with HTTP; Mon, 8 Feb 2016 13:17:58 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Feb 2016 08:17:58 +1100 Message-ID: From: Mark Smith To: Saku Ytti Content-Type: multipart/alternative; boundary=001a114790a8372826052b48bca7 Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:18:10 -0000 --001a114790a8372826052b48bca7 Content-Type: text/plain; charset=UTF-8 On 9 February 2016 at 06:45, Saku Ytti wrote: > On 8 February 2016 at 21:34, Mark Smith wrote: > >> One of the drawbacks, which is probably a show stopper, is that it >> limits the number of layer 3 addresses on a link to the maximum number >> of layer 2 addresses supported on a link. While links with large >> numbers of layer 2 addresses are common, tightly coupling the size of >> the layer 3 address space on a link to the size of the available layer >> 2 address space is probably an unacceptable layer 3 limitation. > > Can you elaborate on the problem? I think it only limits that every L3 > subnet will have same identifier (can be different size L3 network > though). > Actually my criticism above is not quite right, although I think on the right path. With a smaller layer 2 address space, the likelihood of hash collisions goes up, so this doesn't eliminate the issue of dealing with duplicate addresses, and creates it at layer 2 where no DAD solution currently exists. Another issue is Node support for multiple layer 3 addresses. That would likely translate into multiple layer 2 addresses, meaning nodes need to support multiple MAC addresses. I think some NICs support that, but most would have to be switched into promiscuous mode, disabling all NIC level address based filtering. Also, as there is no neighbour presence discovery protocol, every unicast layer 3 packet translates into a layer 2 frame, even if the layer 3 and therefore layer 2 destination doesn't exist. That's an opportunity for a flooding attack at layer 2, because bridges and switches will flood those unknowns to all devices - and nodes with NICs in promiscuous mode will hand all of them up to the main CPU to be thrown away. > -- > ++ytti --001a114790a8372826052b48bca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 9 February 2016 at 06:45, Saku Ytti <saku@ytti.fi> wrote:
> On 8 February 2016 at 21:34, Mark Smith <markzzzsmith@gmail.com> wrote:
>
>> One of the drawbacks, which is probably a show stopper, is that it=
>> limits the number of layer 3 addresses on a link to the maximum nu= mber
>> of layer 2 addresses supported on a link. While links with large >> numbers of layer 2 addresses are common, tightly coupling the size= of
>> the layer 3 address space on a link to the size of the available l= ayer
>> 2 address space is probably an unacceptable layer 3 limitation. >
> Can you elaborate on the problem? I think it only limits that every L3=
> subnet will have same identifier (can be different size L3 network
> though).
>

Actually my criticism above is not quite right, although I t= hink on the right path.

With a smaller layer 2 address space, the likelihood of hash= collisions goes up, so this doesn't eliminate the issue of dealing wit= h duplicate addresses, and creates it at layer 2=C2=A0 where no DAD solutio= n currently exists.

Another issue is Node support for multiple layer 3 addresses= . That would likely translate into multiple layer 2 addresses, meaning node= s need to support multiple MAC addresses. I think some NICs support that, b= ut most would have to be switched into promiscuous mode, disabling all NIC = level address based filtering.

Also, as there is no neighbour presence discovery protocol, = every unicast layer 3 packet translates into a layer 2 frame, even if the l= ayer 3 and therefore layer 2 destination doesn't exist. That's an o= pportunity for a flooding attack at layer 2, because bridges and switches w= ill flood those unknowns to all devices - and nodes with NICs in promiscuou= s mode will hand all of them up to the main CPU to be thrown away.

<= /p>

> --
> ++ytti

--001a114790a8372826052b48bca7-- From nobody Mon Feb 8 13:23:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A3F1AD074 for ; Mon, 8 Feb 2016 13:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGzJ302wrtbO for ; Mon, 8 Feb 2016 13:23:15 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 066401AD04E for ; Mon, 8 Feb 2016 13:23:15 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id p63so133912761wmp.1 for ; Mon, 08 Feb 2016 13:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3m7s133omQLIj0lUUdaLfr+1YPZzoaPwDex94HFrloA=; b=mpw63N9c4PG6420wA4Jo6KYGy0Eek4Zbt4mZT24v7vffQZUsCslt6Sxnzp3c0iRnHl kkOoWcIAbpe1IZpFlVNLLIlN6YIiGh2pr71GVo2+xLWjIJBlvxX4dQCN+R1Wwm/C5dJY LB0cx/aZJQ5B03U8rDr4h5LQO7pEcI3P7LJF3eSn4VtjCmxpM6i9eYcmrhP/79w+N2rc w4GS9l0dCvBb1z5eXJ90VPn2iclYV2Z9LqHFTZKshJSInoj8jMf6u/r0EyjFhbOQCi4I XJHgo9bLiJ6iZyYikoQjPtukbHE/hXSC66IwkZ+jGqOZgbTD7rRz5G1zyXFxKTdPN+mz rntQ== 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-type; bh=3m7s133omQLIj0lUUdaLfr+1YPZzoaPwDex94HFrloA=; b=XMKgksrDhrfaDNItpFE+1TE8Cw1lLx5+PQC3UrUwIXRTmI2cWeQbiBmOLToDkxOAYc mFyD06IW356LALMBnhc5OKMpUJeANH3k6BSSDYVOKpGlQM3b8ZcMtiy9sW16fbqSWHn6 iGxkugKHzRfifNIWpxG254SGECATulzZtgVe3PEpg2hKB6cQntfiIFlWQqF5hRK7IUmj 7k+W0pwUKW24w5jstbSmpvfcfURMrbAmZPgt9zt+eFRU2ncNauoDHDfUGsRLmwP9o3i0 eVDpsxBos/TJdSLPZ7w81WzQiQBzqlqwsrDZkjJL9mft6Aa+RJlB0u/u5ZRKPzG4zyIS zSkA== X-Gm-Message-State: AG10YOTjVkbuQ4fjKY7jm8ADaR8tuoqEsbDLeGl51ME5E/Q0EnvQUZ4uneFiX7khlnowhqWoSU1TuaCtA/v1Jw== MIME-Version: 1.0 X-Received: by 10.194.243.10 with SMTP id wu10mr29197990wjc.14.1454966593613; Mon, 08 Feb 2016 13:23:13 -0800 (PST) Received: by 10.27.179.7 with HTTP; Mon, 8 Feb 2016 13:23:13 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Feb 2016 23:23:13 +0200 Message-ID: From: Saku Ytti To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:23:16 -0000 On 8 February 2016 at 23:17, Mark Smith wrote: > With a smaller layer 2 address space, the likelihood of hash collisions goes > up, so this doesn't eliminate the issue of dealing with duplicate addresses, > and creates it at layer 2 where no DAD solution currently exists. If you use BIA when doing DAD, you can verify your ID is unique. And you can verify it on link-local scope, so you verify all 46 bits for uniqueness at once, regardless what your GUA prefix-size is. > Another issue is Node support for multiple layer 3 addresses. That would > likely translate into multiple layer 2 addresses, meaning nodes need to > support multiple MAC addresses. I think some NICs support that, but most > would have to be switched into promiscuous mode, disabling all NIC level > address based filtering. Why? Just fill all the host bits you need, from the 46 bits ID you have, for every prefix you have. > Also, as there is no neighbour presence discovery protocol, every unicast > layer 3 packet translates into a layer 2 frame, even if the layer 3 and > therefore layer 2 destination doesn't exist. That's an opportunity for a > flooding attack at layer 2, because bridges and switches will flood those > unknowns to all devices - and nodes with NICs in promiscuous mode will hand > all of them up to the main CPU to be thrown away. Unknown unicast is easily HW limited by switch, and should be done anyhow, regardless how L2 network is ran, so this protection should already be in place. ARP/ND resolution is HW limited as well, as to avoid punting too much to control-plane. -- ++ytti From nobody Mon Feb 8 13:34:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686321B338B for ; Mon, 8 Feb 2016 13:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gIp4pV5Jt1J for ; Mon, 8 Feb 2016 13:34:02 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 1DA081B2F19 for ; Mon, 8 Feb 2016 13:34:02 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id c10so48998668pfc.2 for ; Mon, 08 Feb 2016 13:34:02 -0800 (PST) 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-type:content-transfer-encoding; bh=SHIOvVWdeIWXkvT4v24aGYYvDmFauMAuI52L+Vts1tA=; b=xGgIkzP8DJR3QLwMnsDzP5W1q+ea20tpO9Fmsg8dVZMsA2iLvHzCpsjCuIIZ9pNP5L f/Pm/HAnu5Ahud7Id5fUzBSAjK5/FiqbifCE0bmxJI5PIa9hqDQOlCFB8BLsPD5h4/tB TjgCPDPrqlDSPFU3mXbeCZkY99fnY1/6CN6Hc90VKVLqKbof1D7qHhhrFGppzh/c7pik doDt8uxkJCh3CFEm3+qnnYYN1F2bz4TtJVgzsP5XOvqPNcJFYqVnk7COoF1yjfjzu8ZO gFuuYU/C5yCNpJgg+RhXFHDbSpfNZ4f+cDRus1HVP/BR8oDcEROuqpGc3QN25z64tHHf +6LA== 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-type :content-transfer-encoding; bh=SHIOvVWdeIWXkvT4v24aGYYvDmFauMAuI52L+Vts1tA=; b=K0oqvBWOBaVgGf0My7zk6XHrw5lu+rZM0+gnqJewOQI4VtJ5/nnhHglu1zSGF5BMOw xHz0AmkzZhJjGpMEYNHKX5OtNp4VTq8PjXBeDknY7fmDs8hY59RP82rvGRgwJ5U2Jx9r r4do59PwVFjU9AHukvlsY9CZLcD8kHTlgUqN9PQJvzA2Y3+CdwDdYyp66vsc26HGTLq1 Dsu9uvnUYT9rp72ksg3XjfCjiHWRH9Qm6+Sl8bQI1MPRExL3n56GA3V7FiuKB5qnEZkZ 4bL1KXdi/XuOsg2ZTch1BKnxU5//A8zCbQhb6ghf9XzGosvhvIKWUzKIBvy5v1ypx/Dm FZXQ== X-Gm-Message-State: AG10YOQN8M8m9w7oVF6QUM0bjflMJ0pDjXuL/yUQVLviacgmdlrLihrzxGk5F29+u/+Ztg== X-Received: by 10.98.64.202 with SMTP id f71mr45493622pfd.113.1454967241730; Mon, 08 Feb 2016 13:34:01 -0800 (PST) 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 w89sm19176067pfi.13.2016.02.08.13.33.59 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 13:34:00 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B909C9.4090303@gmail.com> Date: Tue, 9 Feb 2016 10:34:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:34:03 -0000 I'm not quite sure why we're having this discussion on the operations list when it's a protocol design issue, and one that has been actively debated on the 6man list for some years, resulting in: RFC 6164 RFC 7136 RFC 7217 RFC 7421 draft-ietf-6man-ipv6-address-generation-privacy draft-ietf-6man-default-iids and some of the wording details in draft-ietf-6man-rfc4291bis Regards Brian From nobody Mon Feb 8 13:37:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70A1B3397 for ; Mon, 8 Feb 2016 13:37:08 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgpMS6ycDrw4 for ; Mon, 8 Feb 2016 13:37:04 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265081B3394 for ; Mon, 8 Feb 2016 13:37:04 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u18LamKr023570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 13:36:48 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56B90A6F.7010803@isi.edu> Date: Mon, 8 Feb 2016 13:36:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90202.9070603@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u18LamKr023570 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:37:08 -0000 On 2/8/2016 1:00 PM, Nick Hilliard wrote: > Joe Touch wrote: >> My point is that EHs aren't the only issue, and thus deprecating EHs is >> a temporary fix that isn't justified by this issue. ... > Could you read the draft and comment on the issues that it raises? Sec 4.1 and 4.1.2 has been the context for my views. Joe From nobody Mon Feb 8 13:39:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126321B3394 for ; Mon, 8 Feb 2016 13:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wdA7cfQbrSB for ; Mon, 8 Feb 2016 13:39:23 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 BDDC81B3125 for ; Mon, 8 Feb 2016 13:39:22 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id p63so133061734wmp.1 for ; Mon, 08 Feb 2016 13:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g5u7E10N5c/228Tz8FjZ9NvGICW2dV0hva9385OfFJg=; b=EzyG6z0Q9Y1RKj51tC3tzlwM9ZRiE5Ry72h8RSVwZG4AEIKX9rcDKYwyvL3RT1vurA FvydfvZBOgOqe+YLAQI7ImWA+B9dyBlG2mrhSKcv3/UWZ0wzBj5bwe8tLI0B3mIQIuS3 KIxjxnn4lu4Q73x3dS1ss53lV5T/rVG55/Tg+CfJSoCtmettTIO6IPLJN18kZCQifCLy xUPd+QA/MKOSEEsj2C9hWOfHBp+L3lp3I7ulIT+rAa9cOVKlrGH8Ly8J+5d1D2hdILEB bHWVJTEBaEFTo3/ETxLLBG6XtwwBOxXMEKBYZTX2tCDS1hztdBiUsVctnPwIZ/9OKGHv eBaw== 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-type; bh=g5u7E10N5c/228Tz8FjZ9NvGICW2dV0hva9385OfFJg=; b=YOgRmPYsR4dbu9gX1UyF2Y9RgXJ6kdXUbS2ai9tzG+q/tb0jMj4+M5Ua+kPPNKduNO QcDCwRxoFwZwg3lghqycx9pUaQZfv1ByC0lNq2v6VA1X5bdLx6g3KfxFAgILft53dW11 R6CFJ0HL+Gnn9NfVFxE/jnKAK5GQMs5o8BBVcvEW3bFkUkew0jUt9uo3bO1XI7x3cISD WWnVyG4FuW9VMb4shS0UCo7Bx+hSgUqBGcSDg2GodQbmxub5YvIvr8u9PQw/yKInWJ4p TR4IQtT1lTiVEDuJQAVPQGjwmP3y8qz+xKqu5Y7UNMdV54QLkWoXtzKLuYyEJZumtNh1 KmdA== X-Gm-Message-State: AG10YOSy5fQMRgQBuSXxHGFE369PoAaqO/KzRTwT563/5K7wil4MlJvTzMGUZW2U8M3DZUgfs3HscRDP4bnrOg== MIME-Version: 1.0 X-Received: by 10.28.5.203 with SMTP id 194mr971752wmf.101.1454967561330; Mon, 08 Feb 2016 13:39:21 -0800 (PST) Received: by 10.27.179.7 with HTTP; Mon, 8 Feb 2016 13:39:21 -0800 (PST) In-Reply-To: <56B909C9.4090303@gmail.com> References: <56B909C9.4090303@gmail.com> Date: Mon, 8 Feb 2016 23:39:21 +0200 Message-ID: From: Saku Ytti To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:39:24 -0000 On 8 February 2016 at 23:34, Brian E Carpenter wrote: > I'm not quite sure why we're having this discussion on the operations > list when it's a protocol design issue, and one that has been Yeah maybe 6man would be better. > actively debated on the 6man list for some years, resulting in: > > RFC 6164 > RFC 7136 > RFC 7217 > RFC 7421 > draft-ietf-6man-ipv6-address-generation-privacy > draft-ietf-6man-default-iids > > and some of the wording details in draft-ietf-6man-rfc4291bis I don't think any of these propose method for doing away with ND resolution and cache. -- ++ytti From nobody Mon Feb 8 13:40:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90281A924A for ; Mon, 8 Feb 2016 13:40:45 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOPUUExjdOv8 for ; Mon, 8 Feb 2016 13:40:44 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6941B3125 for ; Mon, 8 Feb 2016 13:40:42 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18LedDG001947 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 21:40:40 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B90B56.5010507@foobar.org> Date: Mon, 08 Feb 2016 21:40:38 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> In-Reply-To: <56B90A6F.7010803@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:40:45 -0000 Joe Touch wrote: > On 2/8/2016 1:00 PM, Nick Hilliard wrote: >> Could you read the draft and comment on the issues that it raises? > > Sec 4.1 and 4.1.2 has been the context for my views. Any take on the other subsections in 4.1? Nick From nobody Mon Feb 8 13:42:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487C1A9250 for ; Mon, 8 Feb 2016 13:42:18 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSTDaciQIepK for ; Mon, 8 Feb 2016 13:42:15 -0800 (PST) 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 9FB2E1A924A for ; Mon, 8 Feb 2016 13:42:15 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.164.217]) (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 E6361206B3F; Mon, 8 Feb 2016 22:42:09 +0100 (CET) To: Brian E Carpenter , Joe Touch , Nick Hilliard , Mark Smith References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B8FD18.7030601@si6networks.com> Date: Mon, 8 Feb 2016 17:39:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B8EA3F.2070505@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:42:18 -0000 On 02/08/2016 04:19 PM, Brian E Carpenter wrote: >> >> Managing to get all of your attack traffic onto a single LAG member means >> that you only need N bps of attack traffic to cause issues, not N * M bps >> (where N is the size of the LAG members, and M is the number) - you steer >> all of your traffic onto one link, saturate it and then wait. Usually LACP >> will fail, and the link falls out of the bundle - you now steer onto the >> next link (keeping in mind that the bundle now has less bandwidth), lather, >> rinse, repeat. >> >> If you have a number of long lived TCP flows, and can steer their LAG >> assignment by twiddling flow labels (without changing anything else) you >> get good telemetry (the stack even does some nice stats collections for >> you!), and so tell when you have gotten a bunch of flows to hash onto the >> same link. > > Interesting. This wasn't really in scope for RFC 6438. We covered some related > points in the security considerations of RFC 7098 (Flow Label for Load Balancing > in Server Farms) but maybe this needs writing up. Our intent to do something along these lines was: . Although the coverage of the topic under discussion is, if anything, very poor. I may resubmit some version of this.. if anything, for the sake of discussion. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 8 13:42:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8652F1B33A4 for ; Mon, 8 Feb 2016 13:42:27 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUy9zh80SuMd for ; Mon, 8 Feb 2016 13:42:23 -0800 (PST) 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 A2D331B33A0 for ; Mon, 8 Feb 2016 13:42:23 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.164.217]) (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 A4C0A206B42; Mon, 8 Feb 2016 22:42:18 +0100 (CET) To: Joe Touch , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B90B6C.9060105@si6networks.com> Date: Mon, 8 Feb 2016 18:41:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B8F12F.30307@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:42:27 -0000 On 02/08/2016 04:49 PM, Joe Touch wrote: [....] >> No, always assume that any method to dig into other layers not only can >> fail, but is likely to fail if EHs are present in the packet. > > My point is that EHs aren't the only issue, and thus deprecating EHs is > a temporary fix that isn't justified by this issue. > > ... >> It's too late to fix Steve Deering's intentions to make it hard for >> middleboxes to examine extension headers, but the design choice created >> a set of problems which are extremely difficult to deal with. > > Well, I could turn it around and say that if it "hurts" when you do that > (i.e., use middleboxes), then perhaps the problem lies in what you're > trying to do, not what gets in its way. > > I.e., middleboxes are the design choice that has caused that problem. Real-world networks run on a variety of middle-boxes. At the end of the day, it turns out that if what you try to deploy does not work nicely with the devices you have in the realworld (e.g., a plethora of middleboxes), the end result is that your protocol is not deployable. The current situation with EHs is that you cannot really rely on them. As long as they are not friendly with the deployed world, the end result is drops rates of around 30%-50% which means that in practice you cannot really rely on them. So eventually it becomes a question of of whether you want to "be friendly with the network, and be deployable", or whether you want your packets to be dropped. I'm not saying that the situation is "nice"... but it's the current reality. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 8 13:46:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F71B33A3 for ; Mon, 8 Feb 2016 13:46:45 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWXy2f-7wdOd for ; Mon, 8 Feb 2016 13:46:44 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1320C1B33AC for ; Mon, 8 Feb 2016 13:46:44 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u18Lk4xt025470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 13:46:06 -0800 (PST) To: Fernando Gont , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> From: Joe Touch Message-ID: <56B90C9B.3070604@isi.edu> Date: Mon, 8 Feb 2016 13:46:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90B6C.9060105@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u18Lk4xt025470 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:46:45 -0000 On 2/8/2016 1:41 PM, Fernando Gont wrote: >> I.e., middleboxes are the design choice that has caused that problem. > Real-world networks run on a variety of middle-boxes. At the end of the > day, it turns out that if what you try to deploy does not work nicely > with the devices you have in the realworld (e.g., a plethora of > middleboxes), the end result is that your protocol is not deployable. > > The current situation with EHs is that you cannot really rely on them. The current situation with EHsmiddleboxes is that you cannot really rely on them. From nobody Mon Feb 8 13:48:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35B41B33AF for ; Mon, 8 Feb 2016 13:48:35 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzZPWZRVb2S8 for ; Mon, 8 Feb 2016 13:48:35 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4641B33AA for ; Mon, 8 Feb 2016 13:48:34 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u18LmEsr026298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 13:48:15 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> From: Joe Touch Message-ID: <56B90D1D.7010105@isi.edu> Date: Mon, 8 Feb 2016 13:48:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90B56.5010507@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u18LmEsr026298 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:48:36 -0000 On 2/8/2016 1:40 PM, Nick Hilliard wrote: > Any take on the other subsections in 4.1? I disagree with most of them for similar reasons, but I've already raised these issues repeatedly in v6ops. Continuing to dumb down the net to support the busted revenue model of vendors at the expense of the Internet architecture is not something I intend to support by detailed engagement. Joe From nobody Mon Feb 8 13:52:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B6F1B33BB for ; Mon, 8 Feb 2016 13:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhcrOffNyNPP for ; Mon, 8 Feb 2016 13:52:23 -0800 (PST) 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 C6D871B33B9 for ; Mon, 8 Feb 2016 13:52:23 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id uo6so81178787pac.1 for ; Mon, 08 Feb 2016 13:52:23 -0800 (PST) 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-type:content-transfer-encoding; bh=slMW2YTyy+XkGSbDfqTsQyJjIOrRSzyaRz7UP7UQHDk=; b=Av5W10lfWJeCoBXAlJWmoJ2Lt+lUwde5OV5h+aupxmjtMw8BmyamfSKU5ZhnKzG+W6 Ezf5PEvSlOwzTKs3a2ic/zwFMm0fQXIStFRvYZX8VND6KSRIOGcZrj0/Q9CSgLFcsvjo vMaZaJ7Yrl2GyLOu5mx8m0iT0H9QX9wbgyoVAyDP1vW4XfTlQXPhvdPxLcl5/I12g8lE pUVB/+1JyVRGlPFpmKLoeVtK5PMnj6IRHsmXmx+Ur8J2JkBwnkRJvA58LXaxgx8PvEXh BWeHUagflCRX+0d2scsBsWmA/sAhSkJeYG9hWYB5adIwD5zDsNinKbhRIBEL9vgd5IUP 8guA== 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-type :content-transfer-encoding; bh=slMW2YTyy+XkGSbDfqTsQyJjIOrRSzyaRz7UP7UQHDk=; b=d+Jt8irnQIMqtrd07VFbcLut0bYXh9te1ZF0tcQK6hFGAGWPo2hOeBP9dFeMvlzFUA +odwLQTLTTTOosJQp8hnGtWRtFIDA1owQVmU48L/ANdvn8Py58cf9JJ1K0mcjvh4V76B +vjEIKCOprUF6Cxn3jzcoDNrk76pk1pc0++VXxIHGSGhRBW9wRNSaTwOz28y0irA61Y8 VbdDLdtt95SKY9+XD8y+NSs/tFRgDhJqs2wDrso0qZk4fGlM1owzGEiAAQZ1uyLbPRsW Jagl9EGGXjbh1uoeBcPyLNA5P5Vf1e+5cgdB+CcAhfY7bXu+XqRRuuEgynU8CZLeXoW6 uNww== X-Gm-Message-State: AG10YORc3C4reZ+x1yTFwwC/wWD7Z1sMvYo5joAADElH9Gr1nFlB5EL7JJBkGU0mm4tR8w== X-Received: by 10.67.22.166 with SMTP id ht6mr45881787pad.9.1454968343500; Mon, 08 Feb 2016 13:52:23 -0800 (PST) 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 tp3sm45634163pac.16.2016.02.08.13.52.20 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 13:52:21 -0800 (PST) To: v6ops@ietf.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B90E16.1090402@gmail.com> Date: Tue, 9 Feb 2016 10:52:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90B6C.9060105@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:52:25 -0000 On 09/02/2016 10:41, Fernando Gont wrote: > On 02/08/2016 04:49 PM, Joe Touch wrote: > [....] >>> No, always assume that any method to dig into other layers not only can >>> fail, but is likely to fail if EHs are present in the packet. >> >> My point is that EHs aren't the only issue, and thus deprecating EHs is >> a temporary fix that isn't justified by this issue. >> >> ... >>> It's too late to fix Steve Deering's intentions to make it hard for >>> middleboxes to examine extension headers, but the design choice created >>> a set of problems which are extremely difficult to deal with. >> >> Well, I could turn it around and say that if it "hurts" when you do that >> (i.e., use middleboxes), then perhaps the problem lies in what you're >> trying to do, not what gets in its way. >> >> I.e., middleboxes are the design choice that has caused that problem. > > Real-world networks run on a variety of middle-boxes. At the end of the > day, it turns out that if what you try to deploy does not work nicely > with the devices you have in the realworld (e.g., a plethora of > middleboxes), the end result is that your protocol is not deployable. > > The current situation with EHs is that you cannot really rely on them. > As long as they are not friendly with the deployed world, It takes two to tango. The middleboxes need to implement RFC7045. Until that happens, no amount of accommodation by the hosts will solve the problem. Brian > the end result > is drops rates of around 30%-50% which means that in practice you cannot > really rely on them. So eventually it becomes a question of of whether > you want to "be friendly with the network, and be deployable", or > whether you want your packets to be dropped. > > I'm not saying that the situation is "nice"... but it's the current reality. > > Cheers, > From nobody Mon Feb 8 13:53:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882361B33BC for ; Mon, 8 Feb 2016 13:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OXtRA2Txf5y for ; Mon, 8 Feb 2016 13:53:54 -0800 (PST) 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 5E80B1B2DA1 for ; Mon, 8 Feb 2016 13:53:54 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id c10so49235260pfc.2 for ; Mon, 08 Feb 2016 13:53:54 -0800 (PST) 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-type :content-transfer-encoding; bh=cC6cciCszGZ5IEH/AkOfK8leOvkmj6jPnlsWSdHetn0=; b=sjw7TVXwxmNZ/4YFWM9GpyEsfMlMvd0bCATn469gY3p1GzUiZXbay7sOrkIs7nz5dX 7taKk0OjUB4Kw668bMh+KDl1sVpdr+FHgeNnvrr73ku/ioURJF2M0z4Dkp1yaQl5+vOB J0oIquILFI7mZHAPnN7Xbw0oRf/r+MFD5ouIKnLf/hh+w/EyxJSiCuJSOGytxuvLb0tU 0jmOU2eyG9sn6yRxEF9Y87lQykCoUEPGmVAdlqtELemWlD44q4qJGhRzUQIReOcnrB86 xqL2J7z2haG0y8z25lv9gBVUau8LiIY+HdabauBnQSX4W64GMGW7oWL/MO9hURaJeBcl +04A== 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-type :content-transfer-encoding; bh=cC6cciCszGZ5IEH/AkOfK8leOvkmj6jPnlsWSdHetn0=; b=UVAPLP/2nEd5ETfIhU2lNxZUMjSFGdgl+eqSqob25Q0AcE8TJqWil3fQ24LjpkwZ/j ruNUl29RcSglybWyBAd4mKTPBGCYk+81U3kE33+wsbLOKdqlNY8Ph9y9YnQx0EcDTr8R 8K1WX9FA5jipo4+jtW8ttyar+/+i+S3jfyjHLXNO4RygWYvFK58xGNu0LuSJUPSdJFGK zGVgSUwoZlMaWkvdMCer511pcFQGGtSu7yfKshjfY5zuo1+D5y62wuY2nFN3dHzsWJ4X O8QCqOEaf2kdahOCSm+SjztAwKjBBkcUW97VHuDXwN4mz34nzU9xGG2oUNsSOdechnbP COIA== X-Gm-Message-State: AG10YOT9xkoIepnwb56HdNlrZhJ+TmgrmPXvwOSRjT5lOr8jkEwb065w2ShRRwYkl605Jw== X-Received: by 10.98.1.197 with SMTP id 188mr46011192pfb.8.1454968434028; Mon, 08 Feb 2016 13:53:54 -0800 (PST) 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 69sm45615451pfj.20.2016.02.08.13.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 13:53:52 -0800 (PST) To: Saku Ytti References: <56B909C9.4090303@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56B90E71.4020905@gmail.com> Date: Tue, 9 Feb 2016 10:53:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] FF LARA for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:53:55 -0000 On 09/02/2016 10:39, Saku Ytti wrote: > On 8 February 2016 at 23:34, Brian E Carpenter > wrote: > >> I'm not quite sure why we're having this discussion on the operations >> list when it's a protocol design issue, and one that has been > > Yeah maybe 6man would be better. > >> actively debated on the 6man list for some years, resulting in: >> >> RFC 6164 >> RFC 7136 >> RFC 7217 >> RFC 7421 >> draft-ietf-6man-ipv6-address-generation-privacy >> draft-ietf-6man-default-iids >> >> and some of the wording details in draft-ietf-6man-rfc4291bis > > I don't think any of these propose method for doing away with ND > resolution and cache. I am quite sure they don't. Brian From nobody Mon Feb 8 13:57:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33181B33CD for ; Mon, 8 Feb 2016 13:57:41 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0tmIPVC5PJY for ; Mon, 8 Feb 2016 13:57:39 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FEC1B33DD for ; Mon, 8 Feb 2016 13:57:06 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18Lv3ae002379 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 21:57:04 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B90F2E.6050204@foobar.org> Date: Mon, 08 Feb 2016 21:57:02 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> In-Reply-To: <56B90D1D.7010105@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 21:57:42 -0000 Joe Touch wrote: > I disagree with most of them for similar reasons, but I've already > raised these issues repeatedly in v6ops. > > Continuing to dumb down the net to support the busted revenue model of > vendors at the expense of the Internet architecture is not something I > intend to support by detailed engagement. Some of us need to deal with these problems though. Do you have any workable alternatives? Nick From nobody Mon Feb 8 14:10:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4FC1B33FA for ; Mon, 8 Feb 2016 14:10:10 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVjGW5lz_gYN for ; Mon, 8 Feb 2016 14:10:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0981B2D46 for ; Mon, 8 Feb 2016 14:10:08 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u18M9Tha002057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 14:09:30 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56B91218.6060402@isi.edu> Date: Mon, 8 Feb 2016 14:09:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90F2E.6050204@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u18M9Tha002057 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:10:10 -0000 On 2/8/2016 1:57 PM, Nick Hilliard wrote: >> Continuing to dumb down the net to support the busted revenue model of >> > vendors at the expense of the Internet architecture is not something I >> > intend to support by detailed engagement. > > Some of us need to deal with these problems though. > > Do you have any workable alternatives? I gave you some when you implied I was off-topic and hadn't read your doc. Notably: - focus on the difference between core net devices and those operating on behalf of an end system at the edge - core devices SHOULD limit HBH header use, but MUST allow HBH headers; when they present a DOS issue because of underdesign, the device MAY preferentially drop those that require increased investment, but this drop SHOULD be noted in claims of device capacity - core devices SHOULD NOT inspect above L3; if they feel the need, it SHOULD be only to fill in missing flow labels and not on a persistent basis, and MUST NOT assume that such actions will always be possible - code devices that choose to inspect above L3 MUST NOT drop packets simply because of performance limits of that inspection (i.e., they MUST forward them instead) - edge devices MAY act on behalf of an end system by inspecting above L3, but only when they can ensure that such action would not err in ways the end system would not I.e., if it hurts do do what you WANT (loadbalance, reduce reordering, etc.), then backoff and do what you've contracted (i.e., forward at L3). These are all workable. These mean that you can do what you want only as long as you CAN; if you can't, you don't get to move forward by disabling the Internet. You move forward by disabling the feature you're trying to support that isn't compatible with the Internet because you can't keep up. Beyond that, I'd be writing my own RFC. Joe From nobody Mon Feb 8 15:52:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74181B3DBC for ; Mon, 8 Feb 2016 15:52:35 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT33CrQ9jkuw for ; Mon, 8 Feb 2016 15:52:35 -0800 (PST) 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 0150E1B3D9D for ; Mon, 8 Feb 2016 15:52:06 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.164.217]) (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 368E7206B3F; Tue, 9 Feb 2016 00:52:01 +0100 (CET) To: Joe Touch , Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B91ADB.1030806@si6networks.com> Date: Mon, 8 Feb 2016 19:46:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90A6F.7010803@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 23:52:36 -0000 On 02/08/2016 06:36 PM, Joe Touch wrote: > > > On 2/8/2016 1:00 PM, Nick Hilliard wrote: >> Joe Touch wrote: >>> My point is that EHs aren't the only issue, and thus deprecating EHs is >>> a temporary fix that isn't justified by this issue. > ... >> Could you read the draft and comment on the issues that it raises? > > Sec 4.1 and 4.1.2 has been the context for my views. FWIW, out I-D doesn't propose or suggest that EHs should be deprecated. We simply raise awareness about the challenge they currently represent, which eventually leads to packet drops in many network scenarios. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 8 15:59:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA91B3DAB for ; Mon, 8 Feb 2016 15:59:57 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfXNYVSpbTVX for ; Mon, 8 Feb 2016 15:59:55 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B39E1B3DB7 for ; Mon, 8 Feb 2016 15:59:46 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u18NxhMm006082 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 23:59:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B92BEE.2020800@foobar.org> Date: Mon, 08 Feb 2016 23:59:42 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> In-Reply-To: <56B91218.6060402@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 23:59:57 -0000 Joe Touch wrote: > - focus on the difference between core net devices and those > operating on behalf of an end system at the edge in real-world networks, the line separating core and edge is often not clear-cut, if it exists at all. > - core devices SHOULD limit HBH header use, but MUST allow HBH > headers; when they present a DOS issue because of underdesign, > the device MAY preferentially drop those that require increased > investment, but this drop SHOULD be noted in claims of device > capacity > > - core devices SHOULD NOT inspect above L3; if they feel the > need, it SHOULD be only to fill in missing flow labels and not > on a persistent basis, and MUST NOT assume that such actions > will always be possible > > - code devices that choose to inspect above L3 MUST NOT drop > packets simply because of performance limits of that inspection > (i.e., they MUST forward them instead) If you specify something like this, you should expect it to be abused. I don't like that something like this would be abused, but it would happen. > - edge devices MAY act on behalf of an end system by inspecting > above L3, but only when they can ensure that such action > would not err in ways the end system would not > > I.e., if it hurts do do what you WANT (loadbalance, reduce reordering, > etc.), then backoff and do what you've contracted (i.e., forward at L3). ... which is fine until what you've contracted hurts transmission of other packets because you can't do what you want. > These are all workable. Your suggestions are doable. Silicon could be spun to inspect packet header extensions to arbitrary chain lengths. ASICs could be designed to intercept packets with hbh headers at line rate on all ports and to handle things appropriately. Workable is the intersection of doable and practical. When spinning silicon, a designer needs to make a choice about what's reasonable and what's not. I.e. is it reasonable to look past 64k worth of EHs over multiple packet fragments or is that just a corner case which is unlikely ever to be hit? Or is it reasonable to expect that most ipv6 packets will include a hbh header and that a router should be able to handle packets with hbh headers at line rate on all ports. It's not useful to deny the existence of practical limitations of any particular design. It's a lot more more useful to acknowledge that trade-offs occur and to create a set of reasonable implementation expectations. For example, that ipv6 implementations should process up to N bytes of EHs, or that EHs should only be attached to the first packet and not on subsequent fragments. If this isn't done, then vendors will make their own decisions about what's practical for them, and the results may not be what you want. Nick From nobody Mon Feb 8 16:24:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AF51B3E2D for ; Mon, 8 Feb 2016 16:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHn3WfDlvkK8 for ; Mon, 8 Feb 2016 16:24:47 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 AE8651B3E2E for ; Mon, 8 Feb 2016 16:24:47 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id u9so94316903ykd.1 for ; Mon, 08 Feb 2016 16:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=geaZ8gWsSg6FVAgK9zKGZHGqeG8vBjpoxVxD67CUSB4=; b=fnyuC4UtO4NCYkBA0s3IKc4BgmOEuEgy26z6iFDxA43nUG09vypBUL8m5mHkDXAVCW 8ug+hf3OtLICUoVTkJRR7uvameKg8K523jeobH2Qch2QJdfF7rSD8e4BbDcZnTm+7uzz hni2QnIG6s7zUbTgmeGYov/mBB3z05a71fbvjaR54pfkYQFbod3ND4q+SZjMFXRycqDr DUd3Ld7jfO+7mKagcXbqg1OkHUgUYiRmTn8tJp+9of9Q7B+/1VknJJc+uLrGAgD0EH8n HT/iFwE52RBB3rgJPMhIEvBYOaLSWisfNTXea9cXV51exv5eOig4EOgac97aUHh9dsK0 Vm3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=geaZ8gWsSg6FVAgK9zKGZHGqeG8vBjpoxVxD67CUSB4=; b=JNqPs3M27nPd6k557XHTU2XWIVGfo77o+6PxpMvjqZJwYy7BhVtgRP88dnBbAshBx5 Uz7I3C8ucEFHlLTaVSPn3z52PBFnLIwY6PBlbRuxhRPTlJqieicKrSpMFqvG5FHuQAZd if0vj9ix2HtrmvdrpBnVF126rqtaRaEYXmyH0ZipCASfkYhgIsE+Sm+YsFLuaNrK1LRn JoXddstULVRpenfuYNNwQt6xEGc4jwv1/SJxQeXlDiYZx9zyw/7+P7822cAxJn54oxpG ZcA1GNs1JuzBuJBx08L6JpRMLX7zrODjyU5jwSP4BafBcNVpHV/gJVEXTjBo7M+pfC49 GsKg== X-Gm-Message-State: AG10YORLyEohcyTdtdyQovlx+28+Ne/SDSbVyIpbiELIW7PnZGM9B+Df9BvylNJlUI3+E8n67XnZR3FXqMJvEMuW X-Received: by 10.37.97.210 with SMTP id v201mr16704956ybb.77.1454977486940; Mon, 08 Feb 2016 16:24:46 -0800 (PST) MIME-Version: 1.0 References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> In-Reply-To: <56B92BEE.2020800@foobar.org> From: Warren Kumari Date: Tue, 09 Feb 2016 00:24:37 +0000 Message-ID: To: Nick Hilliard , Joe Touch Content-Type: multipart/alternative; boundary=001a1142ed04441d7f052b4b58e0 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 00:24:49 -0000 --001a1142ed04441d7f052b4b58e0 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 8, 2016 at 4:00 PM Nick Hilliard wrote: > Joe Touch wrote: > > - focus on the difference between core net devices and those > > operating on behalf of an end system at the edge > > in real-world networks, the line separating core and edge is often not > clear-cut, if it exists at all. > > > - core devices SHOULD limit HBH header use, but MUST allow HBH > > headers; when they present a DOS issue because of underdesign, > > the device MAY preferentially drop those that require increased > > investment, but this drop SHOULD be noted in claims of device > > capacity > > > > - core devices SHOULD NOT inspect above L3; if they feel the > > need, it SHOULD be only to fill in missing flow labels and not > > on a persistent basis, and MUST NOT assume that such actions > > will always be possible > > > > - code devices that choose to inspect above L3 MUST NOT drop > > packets simply because of performance limits of that inspection > > (i.e., they MUST forward them instead) > > If you specify something like this, you should expect it to be abused. > I don't like that something like this would be abused, but it would happen. > > > - edge devices MAY act on behalf of an end system by inspecting > > above L3, but only when they can ensure that such action > > would not err in ways the end system would not > > > > I.e., if it hurts do do what you WANT (loadbalance, reduce reordering, > > etc.), then backoff and do what you've contracted (i.e., forward at L3). > > ... which is fine until what you've contracted hurts transmission of > other packets because you can't do what you want. > > > These are all workable. > > Your suggestions are doable. Silicon could be spun to inspect packet > header extensions to arbitrary chain lengths. ASICs could be designed > to intercept packets with hbh headers at line rate on all ports and to > handle things appropriately. > > Workable is the intersection of doable and practical. When spinning > silicon, a designer needs to make a choice about what's reasonable and > what's not. I.e. is it reasonable to look past 64k worth of EHs over > multiple packet fragments or is that just a corner case which is > unlikely ever to be hit? Or is it reasonable to expect that most ipv6 > packets will include a hbh header and that a router should be able to > handle packets with hbh headers at line rate on all ports. > > It's not useful to deny the existence of practical limitations of any > particular design. It's a lot more more useful to acknowledge that > trade-offs occur and to create a set of reasonable implementation > expectations. For example, that ipv6 implementations should process up > to N bytes of EHs, or that EHs should only be attached to the first > packet and not on subsequent fragments. If this isn't done, then > vendors will make their own decisions about what's practical for them, > and the results may not be what you want. > > If I can add to that: "If this isn't done, then vendors will make their own decisions about what's practical for them **and what their customers will actually pay for**, and the results may not be what you want." ("practical for them" included this, but I think it is worth spelling out) Customers (like anyone else) are only willing to pay for things that they need, at at the moment they don't seem to be needing this. Telling vendors (and their customers) that they are wrong because the RFCs say so, or because some corner case doesn't work doesn't really help... W > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1142ed04441d7f052b4b58e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon= , Feb 8, 2016 at 4:00 PM Nick Hilliard <nick@foobar.org> wrote:
J= oe Touch wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- focus on the difference between core net d= evices and those
>=C2=A0 =C2=A0 =C2=A0 =C2=A0operating on behalf of an end system at the = edge

in real-world networks, the line separating core and edge is often not
clear-cut, if it exists at all.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- core devices SHOULD limit HBH header use, = but MUST allow HBH
>=C2=A0 =C2=A0 =C2=A0 =C2=A0headers; when they present a DOS issue becau= se of underdesign,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the device MAY preferentially drop those tha= t require increased
>=C2=A0 =C2=A0 =C2=A0 =C2=A0investment, but this drop SHOULD be noted in= claims of device
>=C2=A0 =C2=A0 =C2=A0 =C2=A0capacity
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- core devices SHOULD NOT inspect above L3; = if they feel the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0need, it SHOULD be only to fill in missing f= low labels and not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0on a persistent basis, and MUST NOT assume t= hat such actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0will always be possible
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- code devices that choose to inspect above = L3 MUST NOT drop
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets simply because of performance limits= of that inspection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., they MUST forward them instead)

If you specify something like this, you should expect it to be abused.
I don't like that something like this would be abused, but it would hap= pen.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- edge devices MAY act on behalf of an end s= ystem by inspecting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0above L3, but only when they can ensure that= such action
>=C2=A0 =C2=A0 =C2=A0 =C2=A0would not err in ways the end system would n= ot
>
> I.e., if it hurts do do what you WANT (loadbalance, reduce reordering,=
> etc.), then backoff and do what you've contracted (i.e., forward a= t L3).

... which is fine until what you've contracted hurts transmission of other packets because you can't do what you want.

> These are all workable.

Your suggestions are doable.=C2=A0 Silicon could be spun to inspect packet<= br> header extensions to arbitrary chain lengths.=C2=A0 ASICs could be designed=
to intercept packets with hbh headers at line rate on all ports and to
handle things appropriately.

Workable is the intersection of doable and practical.=C2=A0 When spinning silicon, a designer needs to make a choice about what's reasonable and<= br> what's not.=C2=A0 I.e. is it reasonable to look past 64k worth of EHs o= ver
multiple packet fragments or is that just a corner case which is
unlikely ever to be hit?=C2=A0 Or is it reasonable to expect that most ipv6=
packets will include a hbh header and that a router should be able to
handle packets with hbh headers at line rate on all ports.

It's not useful to deny the existence of practical limitations of any particular design.=C2=A0 It's a lot more more useful to acknowledge tha= t
trade-offs occur and to create a set of reasonable implementation
expectations.=C2=A0 For example, that ipv6 implementations should process u= p
to N bytes of EHs, or that EHs should only be attached to the first
packet and not on subsequent fragments.=C2=A0 If this isn't done, then<= br> vendors will make their own decisions about what's practical for them,<= br> and the results may not be what you want.


If I can add to that:
"= If this isn't done, then vendors will make their own decisions about wh= at's practical for them **and what their customers will actually pay fo= r**, and the results may not be what you want." ("practical for t= hem" included this, but I think it is worth spelling out)
Customers (like anyone else) are only willing to pay for thing= s that they need, at at the moment they don't seem to be needing this.<= /div>

Telling vendors (and their customers) that they ar= e wrong because the RFCs say so, or because some corner case doesn't wo= rk doesn't really help...

W

=C2=A0
Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a1142ed04441d7f052b4b58e0-- From nobody Mon Feb 8 17:06:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BAF1B3EB3 for ; Mon, 8 Feb 2016 17:06:46 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EhM3iqzRVoT for ; Mon, 8 Feb 2016 17:06:44 -0800 (PST) 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 A68741A7030 for ; Mon, 8 Feb 2016 17:06:44 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.164.217]) (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 4C3EE206B3D; Tue, 9 Feb 2016 02:06:39 +0100 (CET) To: Philip Homburg , v6ops@ietf.org, sthaug@nethelp.no References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.152151.71101099.sthaug@nethelp.no> From: Fernando Gont Message-ID: <56B9312A.4020305@si6networks.com> Date: Mon, 8 Feb 2016 21:22:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:06:46 -0000 On 02/07/2016 11:28 AM, Philip Homburg wrote: >>> So an alternative way to go forward is to fix the higher level protocols >>> to deal with out of order packets and then switch to statistical multiplexin >> g. >> >> Possibly. Not holding my breath waiting for this to happen, though. > > One option is to do statistical multiplexing for packets protected by an > EH. A small extension header inside EH can easily deal with reordered > packets. Or people using IPSEC tunnels can try to get TCP implementations > fixed. Could you elaborate a bit on the EH thing? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 8 17:06:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EA91B3EBF for ; Mon, 8 Feb 2016 17:06:56 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj5ayp9Jfvv9 for ; Mon, 8 Feb 2016 17:06:50 -0800 (PST) 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 6B9761B3EB9 for ; Mon, 8 Feb 2016 17:06:50 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.164.217]) (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 CE830206B42; Tue, 9 Feb 2016 02:06:46 +0100 (CET) To: Brian E Carpenter , v6ops@ietf.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B933A4.6060405@si6networks.com> Date: Mon, 8 Feb 2016 21:32:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B90E16.1090402@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:06:56 -0000 On 02/08/2016 06:52 PM, Brian E Carpenter wrote: > On 09/02/2016 10:41, Fernando Gont wrote: >> On 02/08/2016 04:49 PM, Joe Touch wrote: >> [....] >>>> No, always assume that any method to dig into other layers not only can >>>> fail, but is likely to fail if EHs are present in the packet. >>> >>> My point is that EHs aren't the only issue, and thus deprecating EHs is >>> a temporary fix that isn't justified by this issue. >>> >>> ... >>>> It's too late to fix Steve Deering's intentions to make it hard for >>>> middleboxes to examine extension headers, but the design choice created >>>> a set of problems which are extremely difficult to deal with. >>> >>> Well, I could turn it around and say that if it "hurts" when you do that >>> (i.e., use middleboxes), then perhaps the problem lies in what you're >>> trying to do, not what gets in its way. >>> >>> I.e., middleboxes are the design choice that has caused that problem. >> >> Real-world networks run on a variety of middle-boxes. At the end of the >> day, it turns out that if what you try to deploy does not work nicely >> with the devices you have in the realworld (e.g., a plethora of >> middleboxes), the end result is that your protocol is not deployable. >> >> The current situation with EHs is that you cannot really rely on them. >> As long as they are not friendly with the deployed world, > > It takes two to tango. The middleboxes need to implement RFC7045. Until > that happens, no amount of accommodation by the hosts will solve the > problem. My comment is that any "feature" that is unfriendly to middleboxes by design is doomed to be blocked. RFC7045 addresses part of the problem. draft-gont-6man-rfc6564bis is another part of the problem which, surprisingly to me, we've done nothing about. Then there's the issue of how long we allow EH chains to be: so far the only current limit is "up to the PMTUD" (RFC7112). Maybe if we were to reduce this to something more sensible (even at the operational level), we could move forward a bit. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 8 17:08:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97A21B3EC7 for ; Mon, 8 Feb 2016 17:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmfBiYZuquAa for ; Mon, 8 Feb 2016 17:08:23 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89A21A7030 for ; Mon, 8 Feb 2016 17:08:23 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u1917pYu025799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 17:07:52 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> From: Joe Touch Message-ID: <56B93BE5.7010902@isi.edu> Date: Mon, 8 Feb 2016 17:07:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B92BEE.2020800@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:08:24 -0000 On 2/8/2016 3:59 PM, Nick Hilliard wrote: > It's not useful to deny the existence of practical limitations of any > particular design. I agree, but when faced with alternatives, the appropriate action is to support L3 forwarding when you can and give up on "higher services" when they become your DOS vector. I.e., it's the support for these higher services that is the issue, not just (or primarily) the use of EHs. Let's please not get that backwards. Joe From nobody Tue Feb 9 00:20:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7021A6F93 for ; Tue, 9 Feb 2016 00:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzzMSBgmH7Zs for ; Tue, 9 Feb 2016 00:20:42 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05721A6F92 for ; Tue, 9 Feb 2016 00:20:42 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2946AD7881; Tue, 9 Feb 2016 00:20:41 -0800 (PST) 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=uEvXkqgB5lvEElr7Vezd5uktNLI=; b= RM+tr29bIdLd/Kd/dWnTGpXuTVAXypm5EJRBjI7ZCIEFlwiIxcBgiXDOOeFJ3Mj7 jxENOFNCRlkEi5XukS1yEbczp9kGKG9VhylAx4labg48EZI39KRsApOWh0e9tXID wTXA9aTuHkHnnhuRYJjnWhRqTDYdpVv5zZ0R5BuaR7E= 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=Oc9Q+nMcVktrvVCTbOFVb9LgmI xgDgC89/Ge8Fzq2szIEHP96zZMEx0lyceiicaAWg1TTxxHfAaRqeb7ghhYmDaVuX gOa2+yqehqrBDjgElvxcTLzVS/keBpZxdu4kLKB6wz3RMBBOzaNR+G3GWpcwaDLb pY6htCQ6JqshAHZcA= Received: from h.hanazo.no (unknown [173.38.220.49]) (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 DC1F4D7884; Tue, 9 Feb 2016 00:20:40 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6758D109B27C; Tue, 9 Feb 2016 09:20:28 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E1AA98CF-1B5E-46DC-AED8-0C7C8ED0267C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56B8EA3F.2070505@gmail.com> Date: Tue, 9 Feb 2016 09:20:27 +0100 Message-Id: <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 08:20:44 -0000 --Apple-Mail=_E1AA98CF-1B5E-46DC-AED8-0C7C8ED0267C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > ... >> what's the ratio of flow label =3D 0 to set flow labels in your = network? >> anyone studied this over time? >=20 > We're planning for the long term here. While I agree that this is a = very > interesting question, we shouldn't base future practice on it. I'm not sure what you imply by that. if the flow label is set, then router implementations / deployments can = be changed to use the 3-tuple for ECMP instead of the 5-tuple. if generally flow label =3D 0, then we could at least identify = implementations that needs to be fixed so that we at some point can = change. cheers, Ole --Apple-Mail=_E1AA98CF-1B5E-46DC-AED8-0C7C8ED0267C 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 iQIcBAEBCgAGBQJWuaFMAAoJEL7aWKiYQt92Dt8P/3oQ3lhhJD9ktraBbmDhAZcu bHNRPBfxdR6kh/wHpsmB0DKbsi1yw0jRWlZ+84n4O3KiYVIrcLINFhTXLZLIVgic T/KjYKzJTEyYVr3q4X6yqGF3Nf/qyXbDiG/3y8FHe8GRpROA93tJ82Dc+PTG0j+7 vCovoiTH7ZMdel3dNUMEcx/H/4jCHR2BKpcUBdArbXTjsNng2mgO8gRZCs/fqhr3 MG0yOmw4dK7w5j4HBdgws89VzPGE21ptQgBj/P/VJpRZsx1mOSjH7Z+fMi8cZ3ES Jc7oVmjQmjJQaBC1y87tjlqW/g1+ZkJwSkkmr2AlsSMxRUZyPw5qEO+g0tF1FHk/ 0fjiIqxG9aOhC9FmBSK0MB/mr9esKpcb0lNF+ikUhSlfIQIk1PEE5DOJU+JLqlOn WwVG1tkSi8pv1wGA00UVOSb60HtiHJ2LcPKsTJgWgdKZW/zMQSZ7HaEwbfYwwU53 YcZIPeI8WU/UwNk2vfVA6orTVvB6goazZqbWEYF7QZFP5dFVxV3j0FnI1Ohsg5oH GRf9QHyD9Ke2h4BBuhLfuVlt/5YJdjqrbw12ExlimOTEA9+Yb2zxEGpiN0frf9Pg kdmVE+6YJzNQ8JFNUv9lTyXKPx2BfZYqm2QY8karZSLRLt4RxVqlgBpxdFu6KlCv bpFVPGo/g3PhpKc3byC1 =04Oi -----END PGP SIGNATURE----- --Apple-Mail=_E1AA98CF-1B5E-46DC-AED8-0C7C8ED0267C-- From nobody Tue Feb 9 00:29:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7A1A6FB2 for ; Tue, 9 Feb 2016 00:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhsReedn8KP2 for ; Tue, 9 Feb 2016 00:29:13 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07F91A6FAE for ; Tue, 9 Feb 2016 00:29:13 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 50362D7883; Tue, 9 Feb 2016 00:29:13 -0800 (PST) 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=5Czi2irIfgE/0pHGGHGgSwgN1Os=; b= LL5wIEK+INyWqn70GVJirIUrj/sGYhFaoqBgN4RWNdV1WHwgh12qVyBzIhJVSUGa Xl01ksmzkyIewS4THBu+TNm3rKInWofOUdVdcVduffuxzYLNTno6THgpDuYRgtut hI32qM5/oNSnMEHyu3fGzo7P9mjdFLlywkKEyKNiNoU= 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=E4nbE9pmqERqFoLvMMNOl5NX75 /OyrNCg8CDsi7edD2L3KEZARMiHnJKwds9jwV6QQ9I6my4QC2jut6k8E9eqxLrGf 8bsqufVZr/hr4DqDnAR4K9iAznYpjRRc7NMXa4xfYbD8+mrwMAQm9eXCZhNiIByh Vra+Aj5r/gydeLe9U= Received: from h.hanazo.no (unknown [173.38.220.49]) (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 0F655D7881; Tue, 9 Feb 2016 00:29:13 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 147FA109B79A; Tue, 9 Feb 2016 09:29:10 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3B39703B-EAB2-475A-AC55-5B844647DDCF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56B933A4.6060405@si6networks.com> Date: Tue, 9 Feb 2016 09:29:09 +0100 Message-Id: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 08:29:15 -0000 --Apple-Mail=_3B39703B-EAB2-475A-AC55-5B844647DDCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >> It takes two to tango. The middleboxes need to implement RFC7045. = Until >> that happens, no amount of accommodation by the hosts will solve the >> problem. >=20 > My comment is that any "feature" that is unfriendly to middleboxes by > design is doomed to be blocked. if we were to design the network according to that "principle", we would = at least: - not do IP fragmentation - not have asymmetric paths - ban crypto. no reason why middleboxes need to contain themselves below = L7 I would claim your line of argumentation is fundamentally incompatible = with rfc1958. Best regards, Ole --Apple-Mail=_3B39703B-EAB2-475A-AC55-5B844647DDCF 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 iQIcBAEBCgAGBQJWuaNVAAoJEL7aWKiYQt92vAQP/1XH/lLxB2KgZxt1T0zbya5Z MkbWVRhgPnXdMS8KrmjD0+BY80iVohtQelaf8oJW/CeaKFEn/IQSTpy/V4LlGw0R 04Vq2ZpgpUaCIXjovhNs96x78xi/65sg4EcSvlNxqtZBVWR8oS0OdJLjiydsx2+x yH4FomPTy2LUQrM4bryxGkhLCPjXCcSxoqbOvFLPcoMwh/chph3db5tUfAZXBqmk VPZV1ApvVeGrADPIFJmE/LQVtq0Rof1zZki7lxhxH/gb15nkfzp40d4crrkyYEAb 9sLePeKaA+UU/eppXqNwdH5YINQDSqKc/i+RUUsYwh/xg4sWnNi/C24Ybmn/Vw3P 9T76aIBMCgLI1fFOMN2sZryyWg39UgpiSr1QEXf19//BpmfjOVkl9VAq3cSNnKAz gW7d5MdTZ1Kby5k48rAGYKIXpHD8iwVdfaSS3QqvwF0WnCYFvWDEvdc2p//PZn8t RuL0lA3cgr+Z3yaKYKiidGbq6hNMwr+u1XXg8l8baf01jXc7KHuePjhJaTPhilA6 WUJdrIpKNDEkLNVokozhOGa3SQ9dji//0TEt+5WlotLzmPaAa5PI7EAb7jkqHBpb DW8pxv7Z2z1Go59gxDrA+LV0thTLQNeZs92M3r3LiCccsrPRl1M2ru/onmRikpuq yea8ghGTggfcgGVioP06 =6jGW -----END PGP SIGNATURE----- --Apple-Mail=_3B39703B-EAB2-475A-AC55-5B844647DDCF-- From nobody Tue Feb 9 00:55:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE811A86DD for ; Tue, 9 Feb 2016 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMeA2NBO5Oa1 for ; Tue, 9 Feb 2016 00:55:40 -0800 (PST) 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 241791A854D for ; Tue, 9 Feb 2016 00:55:40 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id c3so66242008vkb.3 for ; Tue, 09 Feb 2016 00:55:40 -0800 (PST) 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:content-type; bh=haly6NniWJ5LnU9pAy2hffdE+gwkMjHjCCK7cC5Zmww=; b=kxuKN8nBWWCusEJccwsE8D2VwdbKhv2D5d8lWPAighzvWEkyUbcaF8uhiMZMNIxVSD bheDsy/eE47t8gw0jJy52LyFW2wtcnH5778cLz7SyXwQtNIePHMNQWSJ2RejgmCynLG4 xCcgRDwujBPXnOD4/TqJ4Ib59pGfM2bS8Lbv0ZgK6UhOU/2WDWoh8Lw+y4w/q74UiVod 0qOHRcD9/dcgLMepjUaFX1AtAg0dHwO3uopTrEg6IoKUUHcxdOP8Pal1BWf+PaMLx4BE eEFfXApwDlgpwCQJCkGrsqDpBFsd6uTpOq1CYR3bNLf8RcRP2G0CswS87A/7rP+buHZO 7w6g== 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-type; bh=haly6NniWJ5LnU9pAy2hffdE+gwkMjHjCCK7cC5Zmww=; b=dTvI3G1psfcDJPBlj2T8kcXJk1ATWMlyz0Z+NLIbCRj0v0wGzjAXutipoxNoEvHCKn tXEoahXIze7/P3gec5dS7oMczNVurc0D1ok1OeQTGy9u9vMNMLTDjCpb5m1CmCP4zOps UKtDdTgX8M2s0itvEDbXqdrKhNbk6wOmMm5y819ZJRkYVmEJhqC40DRZDhaClWGCZfaT +4Z7J+nKsxk1DP9SG0uhZOjeB0vIs2/R4ORrOPO6MTy4bjbFPoEcBPYYWc+vU950dOF7 aebgvFR4QzFuf/XXsYI87k6pnHkeOkB0cfqLOIgLSS9kiF4K8hf08GJI+zjuBtN+Adk1 YBZQ== X-Gm-Message-State: AG10YORXfnoqVrOjeqAM6morcuuHHi8SV6F1nOLTSw4MMUoVl4+VdAICiG+fonnnsO3u3yn/MFn82f4Be+3Xog== MIME-Version: 1.0 X-Received: by 10.31.162.20 with SMTP id l20mr21995218vke.137.1455008138860; Tue, 09 Feb 2016 00:55:38 -0800 (PST) Received: by 10.159.34.103 with HTTP; Tue, 9 Feb 2016 00:55:38 -0800 (PST) Received: by 10.159.34.103 with HTTP; Tue, 9 Feb 2016 00:55:38 -0800 (PST) In-Reply-To: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> Date: Tue, 9 Feb 2016 19:55:38 +1100 Message-ID: From: Mark Smith To: Ole Troan Content-Type: multipart/alternative; boundary=001a1143f2ac4323c6052b527b62 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 08:55:41 -0000 --001a1143f2ac4323c6052b527b62 Content-Type: text/plain; charset=UTF-8 On 9 Feb 2016 19:29, wrote: > > Fernando, > > >> It takes two to tango. The middleboxes need to implement RFC7045. Until > >> that happens, no amount of accommodation by the hosts will solve the > >> problem. > > > > My comment is that any "feature" that is unfriendly to middleboxes by > > design is doomed to be blocked. > > if we were to design the network according to that "principle", we would at least: > > - not do IP fragmentation > - not have asymmetric paths > - ban crypto. no reason why middleboxes need to contain themselves below L7 > > I would claim your line of argumentation is fundamentally incompatible with rfc1958. > So a few years ago I'd noticed MPTCP, a general rise in crypto and also the rise in Smartphones, and thought about what that might mean to middleboxes and the network. "The Rapid Rise of the Mobile Multihomed Host, and what it might mean to the network" http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf I ended up picking the wrong organisation, it was Apple about a week later with IOS 7. > Best regards, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1143f2ac4323c6052b527b62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Feb 2016 19:29, <otroan@emp= loyees.org> wrote:
>
> Fernando,
>
> >> It takes two to tango. The middleboxes need to implement RFC7= 045. Until
> >> that happens, no amount of accommodation by the hosts will so= lve the
> >> problem.
> >
> > My comment is that any "feature" that is unfriendly to = middleboxes by
> > design is doomed to be blocked.
>
> if we were to design the network according to that "principle&quo= t;, we would at least:
>
> - not do IP fragmentation
> - not have asymmetric paths
> - ban crypto. no reason why middleboxes need to contain themselves bel= ow L7
>
> I would claim your line of argumentation is fundamentally incompatible= with rfc1958.
>

So a few years ago I'd noticed MPTCP, a general rise in = crypto and also the rise in Smartphones, and thought about what that might = mean to middleboxes and the network.

"The Rapid Rise of the Mobile=20
Multihomed Host,
and what it might mean to the network"
http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%= 20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf

I ended up picking the wrong organisation, it was Apple abou= t a week later with IOS 7.

> Best regards,
> Ole
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a1143f2ac4323c6052b527b62-- From nobody Tue Feb 9 04:14:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F71A8982 for ; Tue, 9 Feb 2016 04:14:32 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGsxg6acAvDX for ; Tue, 9 Feb 2016 04:14:30 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A591A8977 for ; Tue, 9 Feb 2016 04:14:29 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u19CEQjg030146 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 12:14:26 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56B9D820.1010003@foobar.org> Date: Tue, 09 Feb 2016 12:14:24 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> In-Reply-To: <56B93BE5.7010902@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 12:14:32 -0000 Joe Touch wrote: > I agree, but when faced with alternatives, the appropriate action is to > support L3 forwarding when you can and give up on "higher services" when > they become your DOS vector. which bring us back to: > - code devices that choose to inspect above L3 MUST NOT drop > packets simply because of performance limits of that inspection > (i.e., they MUST forward them instead) If you can't install layer 3 ACLs to protect either your infrastructure or other peoples' infrastructure because your kit can't inspect far enough into an ipv6 packet because the spec allows for 64k of EHs before you see the L4 header, then from an operational point of view, you need an option to block by default. You need this option because some silicon designer or product manager made a decision that it was more important to spend development resources building some other feature rather than optimising their design to handle quantities of EHs that would never been seen unless someone was attempting to abuse a corner case. > I.e., it's the support for these higher services that is the issue, not > just (or primarily) the use of EHs. > > Let's please not get that backwards. We have an operational problem on the Internet in that packets with EHs are routinely dropped: draft-ietf-v6ops-ipv6-ehs-in-real-world We need to stop ignoring this problem because ipv6 extension headers are unusable in production at the moment. You cannot run a protocol if you know that it simply won't work on between 10% and 55% of end points. The first step is to measure the scale of the problem. The second is to analyse why this might be happening. This is what we're trying to do in this document. Nick From nobody Tue Feb 9 04:24:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3FD1A89FC for ; Tue, 9 Feb 2016 04:24:14 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzFKYFwtxjkL for ; Tue, 9 Feb 2016 04:24:12 -0800 (PST) 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 16B931A89FA for ; Tue, 9 Feb 2016 04:24:11 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.188.93]) (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 CFA0D206B5A; Tue, 9 Feb 2016 13:24:06 +0100 (CET) To: otroan@employees.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56B9D9BE.6050405@si6networks.com> Date: Tue, 9 Feb 2016 09:21:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 12:24:14 -0000 On 02/09/2016 05:29 AM, otroan@employees.org wrote: > Fernando, > >>> It takes two to tango. The middleboxes need to implement RFC7045. Until >>> that happens, no amount of accommodation by the hosts will solve the >>> problem. >> >> My comment is that any "feature" that is unfriendly to middleboxes by >> design is doomed to be blocked. > > if we were to design the network according to that "principle", we would at least: > > - not do IP fragmentation > - not have asymmetric paths > - ban crypto. no reason why middleboxes need to contain themselves below L7 > > I would claim your line of argumentation is fundamentally incompatible with rfc1958. Well, it depends on what you look at in that RFC. e.g., the aforementioned RFC says: "Engineering feed-back from real implementations is more important than any architectural principles." I'd say that, if anything, the EH structure is more of an "architectural principle", and the folks commenting on them being rather implementation-unfriendly () and the ops folks dropping the packets are the "engineering feedback and real implementations". The same RFC says: " 3.12 Objects should be self decribing (include type and size), within reasonable limits." -- in this respect, the Net-Header space is not self describing (see draft-gont-6man-rfc6564bis-01) That said, I'm not happy with the current state of affairs regarding EHs. I'm just saying that I'm not surprised (for instance, we finally got to fully specify the FL not that long ago, and hence there was no alternative to simply walking the EH chain). FWIW, I'm all for improving the current state of affairs, rather than sitting happily with the current situation regarding EHs. And, in any case, IMHO the only point of looking back at design choices is for the exercise of trying to learn lessons such that, if one was to design such a protocol again, one could know which things would make sense to make different (me, I'm not sure I would have options at the network-layer.. but if I had, I would opt for something that is limited in size and that can be easily skipped (more a la IPv4) than for a daisy-chain structure with no pointer to the upper layer as in IPv6). -- obviously, I realize that it's 2016 and not the early 90s... (so you may argue that this is like "betting on the horses with Monday's newspaper in your hands", as we say here). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 9 04:47:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BC61A8A6D for ; Tue, 9 Feb 2016 04:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ljEj5VfBM5F for ; Tue, 9 Feb 2016 04:47:04 -0800 (PST) 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 0EDDC1A8A6E for ; Tue, 9 Feb 2016 04:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141; q=dns/txt; s=iport; t=1455022024; x=1456231624; h=date:from:message-id:to:subject:cc; bh=HztpTzAU8Hq8En5NBGJIpP1v03dI9gnpKZmtuWXGbMc=; b=SkJtOdjWV5MimxtHl6/L4NFvBnKwZjsRvcERiq7BIw+zRcVQ6DNKxfr2 +CoV3mvVOMyhiqH8YU48aDQR4dD6HQtRqmnalEF77UV8AYP8UVotvhtre uAQs/MPCHtCLYzhPKnngy5mfUa5RCos8CxOmWM0YikPdIzUZMXkY7v8NS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkCQDo3rlW/5hdJa1egzpSbohboSkBi?= =?us-ascii?q?EyHLoFmIYVjCYEyORMBAQEBAQEBgQqERH08NIh7AQ6+HQEBAQcBAQEBARuKSYR?= =?us-ascii?q?+g24FjhuIXYVMiV9Kg3mIVY4/IQFAhAWJHAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,420,1449532800"; d="scan'208";a="235026358" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2016 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u19Cl2wU023138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 12:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u19Cl2or004639; Tue, 9 Feb 2016 04:47:02 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u19Cl2m5004613; Tue, 9 Feb 2016 04:47:02 -0800 Date: Tue, 9 Feb 2016 04:47:02 -0800 From: fred@cisco.com Message-Id: <201602091247.u19Cl2m5004613@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 12:47:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations. Please take a look at it and comment. From nobody Tue Feb 9 04:57:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F41A8A89 for ; Tue, 9 Feb 2016 04:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFrqK_9x5TW7 for ; Tue, 9 Feb 2016 04:57:01 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BCB1A8A87 for ; Tue, 9 Feb 2016 04:57:01 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6969ED7883; Tue, 9 Feb 2016 04:57:00 -0800 (PST) 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=gCGyTknvmI/VuuWmBfWod0zuNBo=; b= ApaGPaH3JUQbNFBNXe6ndrrRfkCFzZaxHnUJe/iW6gbb5TSSGbp/w/lBzUQpgagY 3Mdqsjd1ru8lPktVLo0b0HeDAYuICvOKI+ARh7ZfSeqEglhkeQHRftLU1tY8WHtl 4Sq0KMn0Dn2+DNRL7LJLLrW6OUgtu0cThFXo58+Z7aE= 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=PGzQZIgKXx5VQIjdQmenKN1YNk 23dXUXj2pLIB7ITEfjQ8uelIQlXUw4TrKdydxuaxbY/5joGyiDvwGMropsQUPfWk TVBUjs+5LoIZZhbuHR0zIXLEr51ZGPieaCSCAnznOLERWn/F4UY3Se8yBN9Je4oq hsQna/I+xcI/w3Zkc= Received: from h.hanazo.no (unknown [173.38.220.49]) (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 EA3DAD7881; Tue, 9 Feb 2016 04:56:59 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D35F110A3DE4; Tue, 9 Feb 2016 13:56:57 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5DB4BED0-FA87-49A8-A6A7-076567541B3B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56B9D9BE.6050405@si6networks.com> Date: Tue, 9 Feb 2016 13:56:56 +0100 Message-Id: <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 12:57:04 -0000 --Apple-Mail=_5DB4BED0-FA87-49A8-A6A7-076567541B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fernando, my point was that it was absurd to try to design network protocols in a = way that they would accommodate any possible policy decision made in the = network or by end-hosts. it isn't the IETFs job to try to bypass = whatever policy a network choses to implement. if we accept that e.g. a transit network needs to look into L4 or = deeper, then we also accept we can never make any innovations at this = layer. (and we've essentially accepted that the Internet is going to be = just an underlay for whatever comes next). I can't think of many examples where a transit network would require to = parse the extension chain. in the case of ECMP, we are better off with IPv6 than IPv4, although we = have to do something to get flow-label based ECMP deployed / = implemented. but even today you can do reasonably well without parsing EHs: if (flow_label > 0) { flow_hash =3D f4(sa,da,protocol, flow) } else { if (nh =3D=3D UDP|TCP) { flow_hash =3D f5(sa,da,protocol,sport,dport) } // Do something with GRE keys } else { flow_hash f3(sa,da,protocol) } adj_index =3D flow_hash & (nadj - 1) Best regards, Ole > On 09 Feb 2016, at 13:21, Fernando Gont wrote: >=20 > On 02/09/2016 05:29 AM, otroan@employees.org wrote: >> Fernando, >>=20 >>>> It takes two to tango. The middleboxes need to implement RFC7045. = Until >>>> that happens, no amount of accommodation by the hosts will solve = the >>>> problem. >>>=20 >>> My comment is that any "feature" that is unfriendly to middleboxes = by >>> design is doomed to be blocked. >>=20 >> if we were to design the network according to that "principle", we = would at least: >>=20 >> - not do IP fragmentation >> - not have asymmetric paths >> - ban crypto. no reason why middleboxes need to contain themselves = below L7 >>=20 >> I would claim your line of argumentation is fundamentally = incompatible with rfc1958. >=20 > Well, it depends on what you look at in that RFC. e.g., the > aforementioned RFC says: >=20 > "Engineering feed-back from real implementations is more important > than any architectural principles." >=20 > I'd say that, if anything, the EH structure is more of an = "architectural > principle", and the folks commenting on them being rather > implementation-unfriendly > = () = and > the ops folks dropping the packets are the "engineering feedback and > real implementations". >=20 >=20 > The same RFC says: > " 3.12 Objects should be self decribing (include type and size), = within > reasonable limits." >=20 > -- in this respect, the Net-Header space is not self describing (see > draft-gont-6man-rfc6564bis-01) >=20 >=20 > That said, I'm not happy with the current state of affairs regarding > EHs. I'm just saying that I'm not surprised (for instance, we finally > got to fully specify the FL not that long ago, and hence there was no > alternative to simply walking the EH chain). >=20 > FWIW, I'm all for improving the current state of affairs, rather than > sitting happily with the current situation regarding EHs. >=20 > And, in any case, IMHO the only point of looking back at design = choices > is for the exercise of trying to learn lessons such that, if one was = to > design such a protocol again, one could know which things would make > sense to make different (me, I'm not sure I would have options at the > network-layer.. but if I had, I would opt for something that is = limited > in size and that can be easily skipped (more a la IPv4) than for a > daisy-chain structure with no pointer to the upper layer as in IPv6). = -- > obviously, I realize that it's 2016 and not the early 90s... (so you = may > argue that this is like "betting on the horses with Monday's newspaper > in your hands", as we say here). >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --Apple-Mail=_5DB4BED0-FA87-49A8-A6A7-076567541B3B 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 iQIcBAEBCgAGBQJWueIZAAoJEL7aWKiYQt92udcP/j7+jyFXv/PaecR3dRMtMW4Q nPcb10SlPdQdnCmY/+ubEqHMaVaMWarRef0Jq7eCBeAGYYMr3HFsK8t64tRY+Ti5 DmeAiVx13V4Bn3EVs2oq+KnnImFpSckLQqrAxpag9ANX06hATfxErgAuzNtT/A5q KisIz6BZVXC6581eGjvdeUeuqXb+/fWQDXPDIhfxxL31Pt1KuXWlM896VYvfb1+t kFZ3Cnr6JJKFGwav89yAjxot7cvYpRBjr7tLAbp7edf1umHg+WFhUXYi9SVtWX2o HmY/61ijgKggS23VyxoUHblHV2ZtovOtU95PX5VDpk91NQrdLLC3nMCSpTjnfae9 JQQW9WHow/ZY4UXquJF1n0AB/pPsEA0k/dhKF8bsJ7yjSlVeC+r0ZCq0/3Op/J5f hwywAU7PChiAFHVWJ7pndv1Xut6phpKrb57Q12dW5Dp4+vj/uu50fU9Iq6P2a2nt ASLmLF6IIB8QA6H9Q+r1EpCapsJ2IlbzpoFB5CrYfAFdteompiz8kF3W9UyG28bh zAyAS/LFfXaHjNYRtRvdDSg1Pm2Je9RWK1fgjD+assUNhLNLDadw+cipNrq18EBU MggaSK5hbOHlPI713WrM9vs80jvpNLZVFFgvIXf8wo0q2fvglvwycpvPEB+jKUzn Sjx7X4vdOfFX51CxHdKr =urt1 -----END PGP SIGNATURE----- --Apple-Mail=_5DB4BED0-FA87-49A8-A6A7-076567541B3B-- From nobody Tue Feb 9 05:51:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F191A9004 for ; Tue, 9 Feb 2016 05:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdGTpxaOOsYL for ; Tue, 9 Feb 2016 05:50:58 -0800 (PST) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id AC9041A8FD7 for ; Tue, 9 Feb 2016 05:50:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 356AB40170; Tue, 9 Feb 2016 14:50:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwhhmkB3GnaN; Tue, 9 Feb 2016 14:50:54 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 346FE4015F; Tue, 9 Feb 2016 14:50:54 +0100 (CET) Message-ID: <56B9EEBC.7030007@globis.net> Date: Tue, 09 Feb 2016 14:50:52 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030909090803090603080008" Archived-At: Cc: v6ops list Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 13:51:00 -0000 This is a multi-part message in MIME format. --------------030909090803090603080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mark Smith wrote: > HI, > > I'm revisiting a few of my drafts that I've been intending to update, > and here is the first. > > My basic realisation was that Solicited-Node joins also could serve as > a low resolution address (or address space range) registration method, > which could then be used by a router to determine whether it needs to > send a ND NS or not. If the Solicited-Node group is present, send the > ND NS, if the group isn't, then don't. > > This update adds a few sections and modes based on Lorenzo's feedback: > > - Strict and Relaxed discard modes. Universal discarding is Strict > mode, Relaxed mode only discards if there is an indication a DoS is > occurring, to allow for lower MLD reliability or implementations that > don't support MLD > > - Some discussion on MLD reliability and how it would effect this method. > > Comments and suggestions appreciated. > > Regards, > Mark. > > > ---------- Forwarded message ---------- > From: > Date: 8 February 2016 at 06:14 > Subject: New Version Notification for > draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt > To: "markzzzsmith+ietf-dt@gmail.com" > > > > A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt > has been successfully submitted by Mark Smith and posted to the > IETF repository. > > Name: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node > Revision: 01 > Title: Further Mitigating Router ND Cache Exhaustion DoS > Attacks Using Solicited-Node Group Membership > Document date: 2016-02-07 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt > Status: > https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/ > Htmlized: > https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01 > > Abstract: > For each of their IPv6 unicast or anycast addresses, nodes join a > Solicited-Node multicast group, formed using the lower 24 bits of the > address. This Solicited-Node group membership could be used by > routers to further mitigate a Neighbor Discovery cache Denial of > Service attack. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > I have read this draft. At first glance it looks like a smart idea, because a defending router only has to track perhaps a thousand entries of state versus potentially having to store state for billions of "incomplete" queries. A couple of questions. 1) How often/when is the MLD cache updated/ timed out? My concern here is that you now have two caches interacting (mulitcast group membership and ND cache), and the timing of adding and deleting entries could cause race conditions. Some discussion of how the caches interact (or not) could be useful IMHO. 2) Why would a router track multicast membership when potentially it could also just track DAD queries directly when nodes join a link? Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN)." Couldn't such a cache also be used as a mechanism for defending against off-link NS exhaustion attacks? Obviously if the router joins the link after some nodes are already on link, then there's a potential for nodes to have already completed DAD before the router boots, so maybe a poll mechanism triggered by monitoring on-link ND requests might be appropriate. But then again, if the nodes send any off-link traffic via this router at all, they'll trigger ND to the router directly, so it's only a problem for normally silent nodes that receive inbound sessions. That could be mitigated by scheduling a simple 'ping' on end nodes acting as servers when they add a new router to their default router list (with appropriate delays/back off etc.). -- regards, RayH --------------030909090803090603080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Mark Smith wrote:
HI,

I'm revisiting a few of my drafts that I've been intending to update,
and here is the first.

My basic realisation was that Solicited-Node joins also could serve as
a low resolution address (or address space range) registration method,
which could then be used by a router to determine whether it needs to
send a ND NS or not. If the Solicited-Node group is present, send the
ND NS, if the group isn't, then don't.

This update adds a few sections and modes based on Lorenzo's feedback:

- Strict and Relaxed discard modes. Universal discarding is Strict
mode, Relaxed mode only discards if there is an indication a DoS is
occurring, to allow for lower MLD reliability or implementations that
don't support MLD

- Some discussion on MLD reliability and how it would effect this method.

Comments and suggestions appreciated.

Regards,
Mark.


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: 8 February 2016 at 06:14
Subject: New Version Notification for
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
To: "markzzzsmith+ietf-dt@gmail.com" <markzzzsmith@gmail.com>



A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
Revision:       01
Title:          Further Mitigating Router ND Cache Exhaustion DoS
Attacks Using Solicited-Node Group Membership
Document date:  2016-02-07
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
Htmlized:
https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01

Abstract:
   For each of their IPv6 unicast or anycast addresses, nodes join a
   Solicited-Node multicast group, formed using the lower 24 bits of the
   address.  This Solicited-Node group membership could be used by
   routers to further mitigate a Neighbor Discovery cache Denial of
   Service attack.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
I have read this draft.

At first glance it looks like a smart idea, because a defending router only has to track perhaps a thousand entries of state versus potentially having to store state for billions of "incomplete" queries.

A couple of questions.

1) How often/when is the MLD cache updated/ timed out?

My concern here is that you now have two caches interacting (mulitcast group membership and ND cache), and the timing of adding and deleting entries could cause race conditions. Some discussion of how the caches interact (or not) could be useful IMHO.

2) Why would a router track multicast membership when potentially it could also just track DAD queries directly when nodes join a link?

Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and Fiber access architectures.  Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN)." 

Couldn't such a cache also be used as a mechanism for defending against off-link NS exhaustion attacks?

Obviously if the router joins the link after some nodes are already on link, then there's a potential for nodes to have already completed DAD before the router boots, so maybe a poll mechanism triggered by monitoring on-link ND requests might be appropriate. But then again, if the nodes send any off-link traffic via this router at all, they'll trigger ND to the router directly, so it's only a problem for normally silent nodes that receive inbound sessions. That could be mitigated by scheduling a simple 'ping' on end nodes acting as servers when they add a new router to their default router list (with appropriate delays/back off etc.).

--
regards,
RayH
--------------030909090803090603080008-- From nobody Tue Feb 9 06:47:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC631A90AA for ; Tue, 9 Feb 2016 06:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FDjIeq-NSW1 for ; Tue, 9 Feb 2016 06:47:25 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 B9C0C1A90A5 for ; Tue, 9 Feb 2016 06:47:25 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D09A962B9E for ; Tue, 9 Feb 2016 15:47:22 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 83EE6602B3 for ; Tue, 9 Feb 2016 15:47:22 +0100 (CET) Received: (qmail 31381 invoked by uid 1007); 9 Feb 2016 15:47:22 +0100 Date: Tue, 9 Feb 2016 15:47:22 +0100 From: Gert Doering To: otroan@employees.org Message-ID: <20160209144722.GD58491@Space.Net> References: <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RqVm8+6q+lpb1Q5O" Content-Disposition: inline In-Reply-To: <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 14:47:27 -0000 --RqVm8+6q+lpb1Q5O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Feb 09, 2016 at 01:56:56PM +0100, otroan@employees.org wrote: > I can't think of many examples where a transit network would require to p= arse the extension chain. You might want to read Fernando's draft :-) - there's quite a number=20 of examples in there. Many cases boil down to "protection of which need differenciation on L4" (like, control plane). Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --RqVm8+6q+lpb1Q5O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVrn7+t9WwGXkzn/FAQJagg//XMC2hP3cRnK2IcYvy5N17H6DRIGZMIFa cXH32Fd22kjOhpCSVycvAnpMaK1amVlgsyCcpVHkoEQDlXJ1+hTMKZqRZcG0Emxc bUUFc3UWcrDnaeCzfuh2I+Jv2vB0iFs/7DgGXBQ4XpZYt922DDfgFC1tGm3MZFrf 6Hk1aSdS56ayWyNmbdqv6jMNu8ztWgZdp1H4bUf/UbtdfsEqOufrXZ94TO3JqhHx koTiRf93F/WQumiDNUdqYH4sYCqall0roxTyWdtpXtbF/sBG4TiUEkHlVn5UbVAD 7p8tzMp8GXUKhSBMq0RxsiKspgbkDNJKE7DE2+DSPr31AHPd/64mODpHLZItRsyZ P89QRR7FxlZqwjIH/eDbdrw17D7CufqGsX9OqtfkwsToKzfkLFnc9Y3vLblkesSt 9+3ViBBhhQbvQQ2HaP2eivObu5KXuTgg9RLZIhmMDG1pCGKMG1YedEPqHQidVHMl i7cg0UFT7lwtGf7YuprKlqPhtd1zLOpSc/9tM+aJJVEJq/WKbs+mqChIkUyYYXUh KeFz4Mt1GQ7/WtR18eDS9LCAmBxzv7S7u+WPk1S1F/NVfhaRKbUIKMWm0y2E9JwF 85Dw4WO4X249NTzLoM/6S4VWx0f4YR4ulS1H4Uqxfxpz0hGcE6RRBWJy+pIbfQxo lhJc0oEqIec= =zhPz -----END PGP SIGNATURE----- --RqVm8+6q+lpb1Q5O-- From nobody Tue Feb 9 07:17:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9528D1A9140 for ; Tue, 9 Feb 2016 07:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbEdEPrQbo04 for ; Tue, 9 Feb 2016 07:17:33 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 6700C1A913A for ; Tue, 9 Feb 2016 07:17:33 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id mw1so13764356igb.1 for ; Tue, 09 Feb 2016 07:17:33 -0800 (PST) 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-type; bh=crHk3AV65NyzIK4po3wrv6HIEl0fTGVXIerdabbBDR4=; b=WGVpxRTcG65Dzyhc002zFz6DjPfsMiIta+uPf/G2mfJTsHiywnWEK76e61F+Z7CAkL G2HdfoYjWeypHKjg0wxl0kimSHd4fb3P5jrYNYOT7Z0fdr7fpq+2nptlGWpyp6uv6WZW EWt1CcZ3WsV67XPLMNuThWf64ipNM7myW+ASJGfZsovGkJus79PQrPOa4CRAakEm8heR Yi0HKQcaOgUzG/CYa0QXPaRMl1PD5JmbzpApRwjMGLBa89TINP2txauas+xeiakXwxNQ LthMH2XF19TkIIzCo8+RYkRVs1UsKN7Z8T2m+uTqdE+49TMvQ9f50wApALHYICgwZrx4 qCsw== 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-type; bh=crHk3AV65NyzIK4po3wrv6HIEl0fTGVXIerdabbBDR4=; b=Y91J1dx/CNV6UHb4YIZtU7czSe52MzjDEhEXBB2+zSgFjTxAAvEU/b49bfrOV4RfdO AWij2SobIa3xrxkOT+HxxP5zMpCT3bOa8OkB/qwM55b0LdvI0J4YtfmaZN8/SBImpqEZ uG5BZhQ8r2JJfx0FlOSKae3YLXlkanC6wA4jb/HY3AkPAsbajLuAQW3MYfMTXItMqscO qhtOpgSDi2dfpgUxRzCWVEGXzrseyzdS/QeYkNTwk2VyEdFLDuWKsUHNN9tOfbTHy3Bp 3dQvyxZjZgXdIiPhty/74Zrl/uSCbRZYix60f+PLfqClcMKR07M64ygGAuidZjYuEvas 2zqw== X-Gm-Message-State: AG10YORThDTlxPI7ZZJtDlSb9DmCi+V4ZYD/BwfwFsDZ+qORTqP8DJZV7yEsLRmgb08rwS9tQFAZKPMRXCzd5A== MIME-Version: 1.0 X-Received: by 10.50.87.7 with SMTP id t7mr5041426igz.65.1455031052644; Tue, 09 Feb 2016 07:17:32 -0800 (PST) Received: by 10.107.160.203 with HTTP; Tue, 9 Feb 2016 07:17:32 -0800 (PST) In-Reply-To: <20160209144722.GD58491@Space.Net> References: <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <20160209144722.GD58491@Space.Net> Date: Tue, 9 Feb 2016 16:17:32 +0100 Message-ID: From: Tom Herbert To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:17:34 -0000 On Tue, Feb 9, 2016 at 3:47 PM, Gert Doering wrote: > Hi, > > On Tue, Feb 09, 2016 at 01:56:56PM +0100, otroan@employees.org wrote: >> I can't think of many examples where a transit network would require to parse the extension chain. > > You might want to read Fernando's draft :-) - there's quite a number > of examples in there. > > Many cases boil down to "protection of which need differenciation > on L4" (like, control plane). > Most of the examples in the draft refer to network edge device functionality (e.g. filtering, ACLs, DDOS mitigation, NAT). For devices that are just switch packets (i.e. fabric switches in our network) the only reason I see that the would want to parse the header chain is either hop-by-hop options or for ECMP (the latter case is what we are addressing using flow label). Are there any other reasons they need to parse the chain? Tom > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Feb 9 07:58:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD59A1AC3C1 for ; Tue, 9 Feb 2016 07:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QfKaVinqwX4 for ; Tue, 9 Feb 2016 07:58:55 -0800 (PST) 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 6C4211AC3BC for ; Tue, 9 Feb 2016 07:58:54 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aTAgm-0000DOC; Tue, 9 Feb 2016 16:58:52 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.152151.71101099.sthaug@nethelp.no> <56B9312A.4020305@si6networks.com> In-reply-to: Your message of "Mon, 8 Feb 2016 21:22:02 -0300 ." <56B9312A.4020305@si6networks.com> Date: Tue, 09 Feb 2016 16:58:51 +0100 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 15:58:57 -0000 In your letter dated Mon, 8 Feb 2016 21:22:02 -0300 you wrote: >On 02/07/2016 11:28 AM, Philip Homburg wrote: >>>> So an alternative way to go forward is to fix the higher level protocols >>>> to deal with out of order packets and then switch to statistical multiplexi >n >>> g. >>> >>> Possibly. Not holding my breath waiting for this to happen, though. >> >> One option is to do statistical multiplexing for packets protected by an >> EH. A small extension header inside EH can easily deal with reordered >> packets. Or people using IPSEC tunnels can try to get TCP implementations >> fixed. > >Could you elaborate a bit on the EH thing? I seem to have skipped a few steps. It seems that in practice we have defined 'The Internet' as a network that does not reorder packets. Then I was thinking about IPSEC tunnels, and one way to restore that property for an IPSEC tunnel, if statistical multiplexing is going on some in the network, is to define a new extension header that just contains a sequence number. The sending side just increments the number for each packet that goes out. The receiving side has some heuristics how long to wait to reorder packets. You could do the same thing in TCP, but it might be easier to write it as a separate layer to avoid modifiying TCP stacks. The same way an option could be added to hbh or destination options. (And then a destination option is really all you need) I assume streams do not contain fragmented packets. The main idea is that if a load balancer cannot handle an EH, it should just use statistical multiplexing and let the hosts deal with the result. From nobody Tue Feb 9 08:41:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1F1ACD13 for ; Tue, 9 Feb 2016 08:41:46 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBFZ_xvkKDw6 for ; Tue, 9 Feb 2016 08:41:42 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD21ACC91 for ; Tue, 9 Feb 2016 08:41:41 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u19GfCdN021544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2016 08:41:13 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56BA16A6.50602@isi.edu> Date: Tue, 9 Feb 2016 08:41:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B9D820.1010003@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u19GfCdN021544 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:41:46 -0000 On 2/9/2016 4:14 AM, Nick Hilliard wrote: > Joe Touch wrote: >> I agree, but when faced with alternatives, the appropriate action is to >> support L3 forwarding when you can and give up on "higher services" when >> they become your DOS vector. > > which bring us back to: > >> - code devices that choose to inspect above L3 MUST NOT drop >> packets simply because of performance limits of that inspection >> (i.e., they MUST forward them instead) > > If you can't install layer 3 ACLs to protect either your infrastructure > or other peoples' infrastructure because your kit can't inspect far > enough into an ipv6 packet because the spec allows for 64k of EHs before > you see the L4 header, then from an operational point of view, you need > an option to block by default. > > You need this option because some silicon designer or product manager > made a decision that it was more important to spend development > resources building some other feature rather than optimising their > design to handle quantities of EHs that would never been seen unless > someone was attempting to abuse a corner case. We should not dumb down Internet protocols simply because vendors are greedy. And we cannot continue to let vendors simply declare that they support IPv6 without supporting it's costlier features. What's missing here is consideration of the following: a) v6ops needs to live within the specs written by intarea operational issues should describe how to comply with requirements, not be an end-run around them b) v6ops needs to remember that these issues were discussed when IPv6 was designed you might think we'd pick different decisions given what we know now, but all we'd get are different requirements that vendors want to do end-runs around c) middleboxes and DPI routers create their own problems if it "hurts" when you do something, perhaps it's time to reconsider Operators wanting to do something doesn't make it so. They should direct their dissatisfaction to vendors who misrepresent their products. E.g., VW owners don't go to the EPA asking them to redefine "clean diesel" simply because it's "really hard" for engine designers to comply. Joe From nobody Tue Feb 9 08:57:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D09B1ACD39 for ; Tue, 9 Feb 2016 08:57:23 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-7gf0rRlaXy for ; Tue, 9 Feb 2016 08:57:22 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5791D1ACD38 for ; Tue, 9 Feb 2016 08:57:22 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u19GvHX2026979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2016 08:57:18 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.152151.71101099.sthaug@nethelp.no> <56B9312A.4020305@si6networks.com> From: Joe Touch Message-ID: <56BA1A6B.9000005@isi.edu> Date: Tue, 9 Feb 2016 08:57:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u19GvHX2026979 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:57:23 -0000 On 2/9/2016 7:58 AM, Philip Homburg wrote: > It seems that in practice we have defined 'The Internet' as a network that > does not reorder packets. > > Then I was thinking about IPSEC tunnels, and one way to restore that property > for an IPSEC tunnel, if statistical multiplexing is going on some in the > network, is to define a new extension header that just contains a sequence > number. The sending side just increments the number for each packet that goes > out. The receiving side has some heuristics how long to wait to reorder packets. IP (and IP forwarding) doesn't care about order. The only time order matters is when an intermediate device tries to act like an end system (inspecting L4) but doesn't want to *do the work* of being an end system (by reordering or reassembling). > You could do the same thing in TCP, but it might be easier to write it as a > separate layer to avoid modifiying TCP stacks. TCP already reorders packets. Modern extensions handle out-of-order arrivals much better than older versions. ... > The main idea is that if a load balancer cannot handle an EH, it should > just use statistical multiplexing and let the hosts deal with the result. +1 From nobody Tue Feb 9 09:14:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DBB1AC3A1 for ; Tue, 9 Feb 2016 09:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I17m5vUaQO4Y for ; Tue, 9 Feb 2016 09:14:50 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 DE0571ACD56 for ; Tue, 9 Feb 2016 09:14:49 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id 128so205419813wmz.1 for ; Tue, 09 Feb 2016 09:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9tUog75sL9bIM38mjeTGkuo1KPc1IBjJfPXyr9r0CDM=; b=1VC0Obu8TvSG7sa1teLqA0jskenFloz9LJKK8x7FPzrO0i5yT61UGlxTXDgqaPqBJ/ 9a0z0rWIG4bP1EdWfu//4CkWQk9WouLbUEPwsNcCsRXiVkVq4K96B32LTCgwH5/4zv+r Ks6jLYzmGnXUIG2NnT7CMgmYpSsff6b54e3C41W3QjGks+ud9CruElB8DpU2GmgACN62 QsxCXr8xQQDFepW5Cejz0TDSPQcxQ6xtHVksl2Bd0RD0OQ3MIaJDYMersW8McerX5E7p uH3vjkDPkimKNz60i+3WOcnQPQh594FPoAIYT9s6btutLXTY9guV0FGxBV+79qQqUEV0 wJBw== 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-type; bh=9tUog75sL9bIM38mjeTGkuo1KPc1IBjJfPXyr9r0CDM=; b=ONUMtG8YyBohhpPwMhm2BL56xZkz31Ds46OB488oM9QmMAo+64ZJFjW+y3XFrfeDM9 5jPGyDVxsL+92spaVJEBzEO5THV7J9uhHfa2QcpaEchj40xVpQPgTxfPX1eV0oWiJdMg lEnOZzv62gQztLmA51H8BaOqJujjtCd0LQB6EC0vfKIb/LrYUzz0NPidgiRepnJaNO1f q8XMF3LodBEaaqeVQUOqoOTtnUfEUGCldpCrzkPeWoTTAFTfoNc7wMI0hZCPG/CKEF8q +GjJt5h35EvxAj7rpL3gj9JFle5hrqhcBbSPSn9ZcgMvTLylOc1ZVm9aS1zNAuwkDkGz lXYw== X-Gm-Message-State: AG10YORciftzZONAdrO862JTYU5nki8hm9ZJs7E4yu4tz624kKTtEqY4Buy5RG59frZZTqNM9ZNywgFbpjyuXA== MIME-Version: 1.0 X-Received: by 10.194.203.5 with SMTP id km5mr15313158wjc.172.1455038088303; Tue, 09 Feb 2016 09:14:48 -0800 (PST) Received: by 10.27.179.7 with HTTP; Tue, 9 Feb 2016 09:14:47 -0800 (PST) In-Reply-To: <56BA16A6.50602@isi.edu> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@isi.edu> Date: Tue, 9 Feb 2016 19:14:47 +0200 Message-ID: From: Saku Ytti To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:14:51 -0000 On 9 February 2016 at 18:41, Joe Touch wrote: Hey, > We should not dumb down Internet protocols simply because vendors are > greedy. > Operators wanting to do something doesn't make it so. They should direct > their dissatisfaction to vendors who misrepresent their products. E.g., > VW owners don't go to the EPA asking them to redefine "clean diesel" > simply because it's "really hard" for engine designers to comply. If end users demand that EH options work, operators will demand from vendors, and vendors will produce devices where this is true. Right now operators are just demanding cheaper and faster boxes with existing feature sets, if device which always drops all EH is cheaper than competitors device which can somehow process them, operators will choose the cheaper box without any EH support. This is classical chicken-egg situation, no one will write application needing EH, as they do not work, and thus customers won't demand that they work, as no application needs them. It shouldn't come as surprise on EH, as we've already experienced it on IP options. We're starting to experience it on fragmentation, market does not complain when device is unable to fragment at high rate, as long as the device is cheaper, it is marketable. Vast majority of operators do not know if they pass or drop EH/IP-options, particularly if they pass or drop HBH and just accept what ever default behaviour device has, and no customer will complain about it. I think it's good that EH is better described in RFC, but I don't think there is any way to press 'reverse' button regardless what documents and standards are written, I don't believe EH can be made to work on IPv6 Internet anymore. Heck, only reason ICMP works, is because machine won't work when it's blocked. When google tested QUIC, I believe they tried to use new IP protocol number, as well as riding on top of UDP, and reach of new IP protocol number was just not sufficient for practical deployment. This really bothers me, it means that even developing new L4 protocol on the Internet is going to be huge challenge if possible at all. -- ++ytti From nobody Tue Feb 9 09:20:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB11ACD5F for ; Tue, 9 Feb 2016 09:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpLObWWjeuRH for ; Tue, 9 Feb 2016 09:20:55 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D69E1ACD44 for ; Tue, 9 Feb 2016 09:20:55 -0800 (PST) Received: from mail-wm0-f45.google.com ([74.125.82.45]:35454) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:matthew@walster.org) (TLS1.0:RSA_ARCFOUR_SHA1:16) id 1aTBy7-0006je-8a (Exim 4.72) for v6ops@ietf.org (return-path ); Tue, 09 Feb 2016 17:20:51 +0000 Received: by mail-wm0-f45.google.com with SMTP id c200so70322568wme.0 for ; Tue, 09 Feb 2016 09:20:53 -0800 (PST) X-Gm-Message-State: AG10YOTM4t65UFW49qovgmUTXneReA07u0Eg9S90vRnDAme449R7AdY3S/uqofPnyC3PNBHQLvabbcEosN8Y1A== X-Received: by 10.28.125.211 with SMTP id y202mr5820842wmc.18.1455038453652; Tue, 09 Feb 2016 09:20:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.46.17 with HTTP; Tue, 9 Feb 2016 09:20:33 -0800 (PST) In-Reply-To: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@isi.edu> From: Matthew Walster Date: Tue, 9 Feb 2016 17:20:33 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Saku Ytti Content-Type: multipart/alternative; boundary=001a114192262a268c052b598ab7 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:20:57 -0000 --001a114192262a268c052b598ab7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 February 2016 at 17:14, Saku Ytti wrote: > When google tested QUIC, I believe they tried to use new IP protocol > number, as well as riding on top of UDP, and reach of new IP protocol > number was just not sufficient for practical deployment. This really > bothers me, it means that even developing new L4 protocol on the > Internet is going to be huge challenge if possible at all. > =E2=80=8BGiven enough time, all new protocols seemingly end up served by an= HTTP daemon :S M=E2=80=8B --001a114192262a268c052b598ab7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9 Febru= ary 2016 at 17:14, Saku Ytti <sak= u@ytti.fi> wrote= :
When google tested QUIC, I believe they tried t= o use new IP protocol
number, as well as riding on top of UDP, and reach of new IP protocol
number was just not sufficient for practical deployment. This really
bothers me, it means that even developing new L4 protocol on the
Internet is going to be huge challenge if possible at all.
=

=E2=80=8BGiven enough time, all new p= rotocols seemingly end up served by an HTTP daemon :S

M=E2=80=8B
=C2=A0<= /div>
--001a114192262a268c052b598ab7-- From nobody Tue Feb 9 09:48:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C241ACD88 for ; Tue, 9 Feb 2016 09:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPrL6Y9l-cq0 for ; Tue, 9 Feb 2016 09:48:22 -0800 (PST) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 897701A87CB for ; Tue, 9 Feb 2016 09:48:21 -0800 (PST) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 424E01C1915 for ; Tue, 9 Feb 2016 11:48:21 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id D0AAA1C17A8; Tue, 9 Feb 2016 11:48:20 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id BE20C420004; Tue, 9 Feb 2016 12:48:19 -0500 (EST) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id BCCAC420003; Tue, 9 Feb 2016 12:48:19 -0500 (EST) Received: from PWN401EA115.ent.corp.bcbsm.com (10.64.140.167) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 9 Feb 2016 12:48:20 -0500 Received: from PWN401EA120.ent.corp.bcbsm.com ([169.254.12.25]) by PWN401EA115.ent.corp.bcbsm.com ([10.64.140.167]) with mapi id 14.03.0266.001; Tue, 9 Feb 2016 12:48:19 -0500 From: "Ackermann, Michael" To: Joe Touch , Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) Thread-Index: AQHRX890IONiwGgTu0iQYnoqIYUoiJ8dwHUAgAAeiACAAA42AIAAAVSAgAAKYoCAAAXDAIAAAXEAgAABkoCAACHjAIABsouAgAAMoICAAAmRgIAABr6AgAAb4QCAANeVAIAABSiA//+1EjqAAFk8gP//rjOcgAKL0gCAALIEZoAAZAyA//+47AA= Date: Tue, 9 Feb 2016 17:48:19 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0D919E30@PWN401EA120.ent.corp.bcbsm.com> References: <56B742AC.7010307@foobar.org> <20160207.143039.74735886.sthaug@nethelp.no> <20160207.152151.71101099.sthaug@nethelp.no> <56B9312A.4020305@si6networks.com> <56BA1A6B.9000005@isi.edu> In-Reply-To: <56BA1A6B.9000005@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: a08cb755-8465-47e0-bfee-79026bc120b2 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: d0bc2b24-99ed-446a-8626-aae1c6cc8df7 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:48:24 -0000 Regards to your statement --- =22, is to define a new extension header that just=20 > contains a sequence number.=22 Please see = https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-01 Which already proposes a sequence number, in a DOH extension header, for = diagnostic and performance monitoring purposes. =20 Thanks Mike -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Joe Touch Sent: Tuesday, February 09, 2016 11:57 AM To: Philip Homburg ; v6ops=40ietf.org Cc: Fernando Gont Subject: Re: =5Bv6ops=5D IPv6 EHs Packet Drops (Fwd: New Version = Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) On 2/9/2016 7:58 AM, Philip Homburg wrote: > It seems that in practice we have defined 'The Internet' as a network=20 > that does not reorder packets. >=20 > Then I was thinking about IPSEC tunnels, and one way to restore that=20 > property for an IPSEC tunnel, if statistical multiplexing is going on=20 > some in the network, is to define a new extension header that just=20 > contains a sequence number. The sending side just increments the=20 > number for each packet that goes out. The receiving side has some = heuristics how long to wait to reorder packets. IP (and IP forwarding) doesn't care about order. The only time order matters is when an intermediate device tries to act = like an end system (inspecting L4) but doesn't want to *do the work* of = being an end system (by reordering or reassembling). > You could do the same thing in TCP, but it might be easier to write it=20 > as a separate layer to avoid modifiying TCP stacks. TCP already reorders packets. Modern extensions handle out-of-order = arrivals much better than older versions. =2E.. > The main idea is that if a load balancer cannot handle an EH, it=20 > should just use statistical multiplexing and let the hosts deal with the = result. +1 _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Tue Feb 9 09:49:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D671ACD8B for ; Tue, 9 Feb 2016 09:49:51 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcGjANPSJS6X for ; Tue, 9 Feb 2016 09:49:50 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3AF1ACD92 for ; Tue, 9 Feb 2016 09:49:46 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u19HnhFI038800 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 17:49:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56BA26B6.2030807@foobar.org> Date: Tue, 09 Feb 2016 17:49:42 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@! isi.edu> In-Reply-To: <56BA16A6.50602@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:49:52 -0000 Joe Touch wrote: > a) v6ops needs to live within the specs written by intarea > operational issues should describe how to comply > with requirements, not be an end-run around them As far as I can tell, this draft is compatible with v6ops charter objective #1: > 1. Solicit input from network operators and users to identify > operational issues with the IPv6 Internet, and determine solutions > or workarounds to those issues. If you feel that there's a problem with the v6ops charter itself, then that's a different issue. Nick From nobody Tue Feb 9 10:26:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162D41ACE22 for ; Tue, 9 Feb 2016 10:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Ly8rHaajIj for ; Tue, 9 Feb 2016 10:26:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BD41ACE2A for ; Tue, 9 Feb 2016 10:26:15 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u19IPp4E005397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2016 10:25:51 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@! isi.edu> <56BA26B6.2030807@foobar.org> From: Joe Touch Message-ID: <56BA2F2D.5020302@isi.edu> Date: Tue, 9 Feb 2016 10:25:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BA26B6.2030807@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:26:16 -0000 On 2/9/2016 9:49 AM, Nick Hilliard wrote: > Joe Touch wrote: >> a) v6ops needs to live within the specs written by intarea >> operational issues should describe how to comply >> with requirements, not be an end-run around them > > As far as I can tell, this draft is compatible with v6ops charter > objective #1: > >> 1. Solicit input from network operators and users to identify >> operational issues with the IPv6 Internet, and determine solutions >> or workarounds to those issues. Solutions or workarounds != deprecating specs. Joe From nobody Tue Feb 9 10:30:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E431ACE2A for ; Tue, 9 Feb 2016 10:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0UdRwdf9CEB for ; Tue, 9 Feb 2016 10:30:03 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639941ACE02 for ; Tue, 9 Feb 2016 10:30:03 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u19ITWfj028829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2016 10:29:33 -0800 (PST) To: Nick Hilliard References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@! isi.edu> <56BA26B6.2030807@foobar.org> <56BA2F2D.5020302@isi.edu> From: Joe Touch Message-ID: <56BA300C.2020705@isi.edu> Date: Tue, 9 Feb 2016 10:29:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BA2F2D.5020302@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 18:30:05 -0000 On 2/9/2016 10:25 AM, Joe Touch wrote: > > > On 2/9/2016 9:49 AM, Nick Hilliard wrote: >> Joe Touch wrote: >>> a) v6ops needs to live within the specs written by intarea >>> operational issues should describe how to comply >>> with requirements, not be an end-run around them >> >> As far as I can tell, this draft is compatible with v6ops charter >> objective #1: >> >>> 1. Solicit input from network operators and users to identify >>> operational issues with the IPv6 Internet, and determine solutions >>> or workarounds to those issues. > > Solutions or workarounds != deprecating specs. FWIW, a good example of reasonable workarounds includes limiting the max length of the chain in typical use *at this time*. All such recommendations should be limited and should focus on supporting capabilities, not merely redefining the Internet for convenience. There are plenty of ways to get there, but the trade-off needs to recognize that what an operator *wants* to do that isn't supported by vendors does not necessarily indicate the need to redefine a protocol spec. Sometimes it's the operator or vendor's problem. Joe From nobody Tue Feb 9 11:07:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93501ACE7D for ; Tue, 9 Feb 2016 11:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiaP1dwqHmQt for ; Tue, 9 Feb 2016 11:07:40 -0800 (PST) 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 8FA9D1ACE89 for ; Tue, 9 Feb 2016 11:07:40 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id c10so65310224pfc.2 for ; Tue, 09 Feb 2016 11:07:40 -0800 (PST) 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-type :content-transfer-encoding; bh=7JVuJWF9UUl0GJrmYJdg1QEwwXGD5Dq/CcAyr0I5XFw=; b=eLZwPtZ3au45mMltPUwuYA4/I9dniOqXDK4rSfiaJq4mrQSIhXwz39v/1w2YnbpFFa x2zDjMNXyELzZP08JR3CAoeDjMpoknhunmyjdF9dCPS6Cv5TeTh7T8qqDXtkll+IN0OD Kib9sheCT9cEVYSM4wXMMXhbUJ1mDMieMKLpHNBx2eN0hY7HF7BUHwm2jgs63ItUd35n DhF9cwiuD2Hb37Dwc7qKofOmuPzXqd5lxdlHUwKEuv7WnKijKsjTYKfJOF2/4Uz2JUWN dwhyDs2CaiBLP9O/y059WgPO7WEOOzlrrtqR8jelg8kUJkPY4j2NC4DuNg4IsMZNcSbE dsWA== 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-type :content-transfer-encoding; bh=7JVuJWF9UUl0GJrmYJdg1QEwwXGD5Dq/CcAyr0I5XFw=; b=UZHZv38aM9sEDW2HRTy30UFb1B2+vNk9iRJbIlT9NIwpH+a7gZ+NOp9kjdjkont/WU ydf/KwEK6FGYY+pzw/mLueFegzHJ62t7wZO5cifwOMT9jFjztlw0kdjqqYY5ub3HEQru kQFn2PyHQY78lyAitC93cpkOUqXk8lV2zTF3mddeeGxpyRcfwWpnJv1lo+3ABDVMnYMN 49WN43IEX7/7OXnweuE8le6E1yn4y/e6DPpa+9kKtqye3vdf0qW6EAbVSrKtr3CYmCh0 Iu27nCJUhjkgHiakRUuARBSXs5AsZhgoV3gpMXcTXIk4xRWG+xpHZppvok2gImlORMKg n4uQ== X-Gm-Message-State: AG10YORKcXjLY++nvv179eEZwn/M203HxXjkxMQMKnMQi5dUXMxxz2leJ5PN2elQ8Jc0jg== X-Received: by 10.98.9.92 with SMTP id e89mr53019370pfd.34.1455044860291; Tue, 09 Feb 2016 11:07:40 -0800 (PST) Received: from ?IPv6:2406:e007:59fb:1:28cc:dc4c:9703:6781? ([2406:e007:59fb:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q16sm52226338pfi.80.2016.02.09.11.07.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 11:07:38 -0800 (PST) To: otroan@employees.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56BA38FC.9020306@gmail.com> Date: Wed, 10 Feb 2016 08:07:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 19:07:42 -0000 Ole, On 09/02/2016 21:20, otroan@employees.org wrote: >> ... >>> what's the ratio of flow label = 0 to set flow labels in your network? >>> anyone studied this over time? >> >> We're planning for the long term here. While I agree that this is a very >> interesting question, we shouldn't base future practice on it. > > I'm not sure what you imply by that. > if the flow label is set, then router implementations / deployments can be changed to use the 3-tuple for ECMP instead of the 5-tuple. Because of the chicken/egg problem, we need operators to require ECMP/LAG and server load balancing products that support the flow label, in order to create an incentive for users to run host stacks that set the flow label by default. Actually I think the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back to 3-tuple if the transport header isn't the first Next Header. > if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change. Windows, Linux, OS X, iOS and Android would be a good start. Brian From nobody Tue Feb 9 11:59:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603111ACD3B for ; Tue, 9 Feb 2016 11:59:03 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_g3M0G04dHE for ; Tue, 9 Feb 2016 11:59:01 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606631ACDA8 for ; Tue, 9 Feb 2016 11:59:01 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u19JwuRq042086 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 19:58:57 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <56BA44FF.40009@foobar.org> Date: Tue, 09 Feb 2016 19:58:55 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@! isi.edu> <56BA26B6.2030807@foobar.org> <56BA2F2D.5020302@isi.edu> In-Reply-To: <56BA2F2D.5020302@isi.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 19:59:03 -0000 Joe Touch wrote: > Solutions or workarounds != deprecating specs. this ID doesn't deprecate any specs. It only attempts to identify problems that people have seen on the Internet when EHs are used, and why the problems might occur. Nick From nobody Tue Feb 9 13:33:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FAE1B2A4A for ; Tue, 9 Feb 2016 13:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5HeLfx98ByN for ; Tue, 9 Feb 2016 13:33:24 -0800 (PST) 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 4760E1B2A49 for ; Tue, 9 Feb 2016 13:33:24 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id d63so1632604ioj.2 for ; Tue, 09 Feb 2016 13:33:24 -0800 (PST) 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-type; bh=5qAkUa4DMhhuONZR0KqJpGyzEH5hcgVB2OLIT2HcCog=; b=XdyP82LAQgGG8ibQMYgUcFmfRyitZYGrISsCNcXOUlHEyL75e7E2xhgQqNG4dclwxq Gv/lSZVdknKCPN86jLXCJpFbeupLo9zuFLDWPm16kq+qbrzIkKNGpkY/ZWUQhMDx6KR3 yVAaRvTl1TdrQL6dp5ajceVNTggazUwAKf+21KkUe9aK648vyeb4l3Q9vR9JKAuP74NE qpAqfTUcfpxmG7+WW3n5eHmhnuVdnpCR0blzL2AxTStlJPI1dvH5qa1Jk66q3DFBGqzw 1QaajYywRxmOBAsLBlqMUGz3PpWWNp3YaALp9wG7B76wBfuEitUHCOQf2ykScfdYEhFv UIsA== 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-type; bh=5qAkUa4DMhhuONZR0KqJpGyzEH5hcgVB2OLIT2HcCog=; b=GHfIRq1Q1Vw0745vrryDN+/8WCfvLK0NcJMprA1EEnUcoOYqzzYG+1uSFiBW9oYWAJ u5H774LqgH+bfzWfs5Wd+RUzRcEimS4RfZABnXBKqTSxy62uIDomwtXJv7TQPCK05Pw1 uopqc1WZEtbsGPA5mk6YoTZDUHEgadRLkJg3wUCrNwM/axXjp4HiJT7YrpjsRR4c2kl8 PqF1tgkmKtumYu3otkcE4icj7qujX7CmMlu2JFpsgAcyz3G8LYbZ7mo/9rV/1omVpQA8 tznbxA2UbhPJZqwvlvsMYg/fnhpgosyOD3+qf8PHUZyXRpQg/FQAzz8MIwmSAFUDbA1w Q/GA== X-Gm-Message-State: AG10YORfyvag0sUNu8SMy56WaFZJx/NOVYnjYENB7kuRPhy93D0VTiPsxnK/3aCM/SYs9cBu5eHaSS/ZxWeL/A== MIME-Version: 1.0 X-Received: by 10.107.138.203 with SMTP id c72mr35290083ioj.107.1455053603735; Tue, 09 Feb 2016 13:33:23 -0800 (PST) Received: by 10.107.160.203 with HTTP; Tue, 9 Feb 2016 13:33:23 -0800 (PST) In-Reply-To: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@isi.edu> Date: Tue, 9 Feb 2016 22:33:23 +0100 Message-ID: From: Tom Herbert To: Saku Ytti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:33:25 -0000 > When google tested QUIC, I believe they tried to use new IP protocol > number, as well as riding on top of UDP, and reach of new IP protocol > number was just not sufficient for practical deployment. This really > bothers me, it means that even developing new L4 protocol on the > Internet is going to be huge challenge if possible at all. > I think you can take this as once data point that end users are "demanding" that networks and the Internet can support alternative transport protocols. The current work being done on extension headers, such as segment routing, can be taken as evidence extensibility of IP is required also. Tom > -- > ++ytti > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Feb 9 13:41:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116F1B2A6A for ; Tue, 9 Feb 2016 13:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9PCBIzk8V_5 for ; Tue, 9 Feb 2016 13:41:05 -0800 (PST) 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 AD9931B2A61 for ; Tue, 9 Feb 2016 13:41:05 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id d63so1827757ioj.2 for ; Tue, 09 Feb 2016 13:41:05 -0800 (PST) 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-type; bh=JwihJxhrcnDL7XytboM7AZ+UOay3bkwpR51ZMM6YDF8=; b=a9C5Yk0xJw1OWoMntwz3SS5vtQx8m5Xj0djzuRt8oRwb+zosExVYA7VhU28alpXRbf t35/KcVBALCfa+ZC9FO/JMN3FgGgE+L3DPGtWqjiB6u8S7iCjZJOZS+V9q2y7viA5OjS Hvr1epZpuRQpL0DAOOYKRFw52zHRpYQe7fFGccE0aFePWIOD4+DrHQWC3ehdCatjP7wD claXTk99yZySZuMGp4JT7jPhyy6NI9vflGUDb6WOEFwdNJakrqSYLU67IS1o3wolZFeA aI0xaarTZF81pa6p6WQOox0AsVTWRQlCEK23I4J5KM/dzU0d8ToB0XFrSbHLTVb2Tj4H tp2Q== 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-type; bh=JwihJxhrcnDL7XytboM7AZ+UOay3bkwpR51ZMM6YDF8=; b=jL9TFz+FLnnmg2oR+hMOpk1rwfQa8VG1UNYP5UNovj4ZOd2G2PWxMUmpZ9C90iJQ/5 o2bHA9ax0QNJKte1/LOh8iPDS2fqg4GtYzwdx4OWPFwF81J/37jkdwaAqs2BrwQH8jIv y/4jIJEpEIt4NfGjuofdS8p2NwPSl97BiuzJOK6CQwSVdBT0TZ9qtbTG7jeO3EL295RW 5LkwlMwzBNvpnUHd/iyuQhbMOynWBSCa48Aej9o0vZ+O8jk03oanmqgEb2IS7jhDLsJn oA/YNW9wNJkxfmpEd0JUyI5cDuotecO5AicsxUqoywO+k5SNZXCsTjsz8eWAPq1aHXdB pLmA== X-Gm-Message-State: AG10YOQkjajWV1dXHjssl7zQ2SNDHMNJm/TJFPmyio2d+fYTZdZ1oh1O5Nsolim8fjIuSBrYy3lB2t4dF1SwwQ== MIME-Version: 1.0 X-Received: by 10.107.138.203 with SMTP id c72mr35321609ioj.107.1455054064930; Tue, 09 Feb 2016 13:41:04 -0800 (PST) Received: by 10.107.160.203 with HTTP; Tue, 9 Feb 2016 13:41:04 -0800 (PST) In-Reply-To: <56BA38FC.9020306@gmail.com> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com> Date: Tue, 9 Feb 2016 22:41:04 +0100 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:41:06 -0000 On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter wrote: > Ole, > > On 09/02/2016 21:20, otroan@employees.org wrote: >>> ... >>>> what's the ratio of flow label = 0 to set flow labels in your network? >>>> anyone studied this over time? >>> >>> We're planning for the long term here. While I agree that this is a very >>> interesting question, we shouldn't base future practice on it. >> >> I'm not sure what you imply by that. >> if the flow label is set, then router implementations / deployments can be changed to use the 3-tuple for ECMP instead of the 5-tuple. > > Because of the chicken/egg problem, we need operators to require ECMP/LAG and server > load balancing products that support the flow label, in order to create an incentive > for users to run host stacks that set the flow label by default. Actually I think > the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back > to 3-tuple if the transport header isn't the first Next Header. > >> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change. > > Windows, Linux, OS X, iOS and Android would be a good start. AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some time now. Support was added in Linux to send non-zero flow labels by default, Android will pick those up the next time they rebase (I still don't know what the status is in Windows). In reality, setting the flow label on the host is near zero cost and as long as network devices are choking on them (we don't have any evidence of that) there's no reason why we can't get to widespread usage in a relatively short period of time. Tom > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Feb 9 16:22:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059AA1B32EE for ; Tue, 9 Feb 2016 16:21:55 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQrDCfyZbbWA for ; Tue, 9 Feb 2016 16:21:51 -0800 (PST) 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 43A401B32D8 for ; Tue, 9 Feb 2016 16:21:51 -0800 (PST) Received: from [192.168.1.66] (unknown [186.56.150.10]) (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 EF0D0206B65; Wed, 10 Feb 2016 01:21:46 +0100 (CET) To: Tom Herbert , Saku Ytti References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@foobar.org> <56B93BE5.7010902@isi.edu> <56B9D820.1010003@foobar.org> <56BA16A6.50602@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56BA8269.2060705@si6networks.com> Date: Tue, 9 Feb 2016 21:20:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:21:55 -0000 On 02/09/2016 06:33 PM, Tom Herbert wrote: >> When google tested QUIC, I believe they tried to use new IP protocol >> number, as well as riding on top of UDP, and reach of new IP protocol >> number was just not sufficient for practical deployment. This really >> bothers me, it means that even developing new L4 protocol on the >> Internet is going to be huge challenge if possible at all. >> > I think you can take this as once data point that end users are > "demanding" that networks and the Internet can support alternative > transport protocols. The current work being done on extension headers, > such as segment routing, can be taken as evidence extensibility of IP > is required also. If that's the case, then, our no action on is really bad. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 9 17:50:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7F1B34F4 for ; Tue, 9 Feb 2016 17:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QsAYFp5GPxa for ; Tue, 9 Feb 2016 17:50:36 -0800 (PST) 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 4415B1B34F3 for ; Tue, 9 Feb 2016 17:50:36 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id e6so3707215vkh.2 for ; Tue, 09 Feb 2016 17:50:36 -0800 (PST) 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-type; bh=ZWuZre7stdHSST2laEBlcvt7iZji5EoeF3mVZ5DrOGw=; b=f/huUMksT5bsDkdqnVxGQI17qasBI6eMx4/jWZ6MrhszBrcZvtau07F8BTiY1R7pEh RrJli92RRpitD1MnNJJv90cXkmPefiU+nDJXp6DjTRgOqF4QH7PfGKPwcBiWGfrT9Y0G eaTNzZ+Y6kp9IapNOpIen0HCDbj5VfxHCU8N+2xbQng6WFbAqmd39/rXhNdxgZhWd18w N+ZcZ+dFqPXTjny0RvvUg5KdsjCdq4qrwklQuGhRmJyT0KDVz1WPdpTyyDukKf0GzUGN ivX/JzNDqUv67cmT1WCOVUqsLowWWJY/SLWQ9TTlu5DlwChMnci2O6R9XqkTUSn7gCPN +/Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZWuZre7stdHSST2laEBlcvt7iZji5EoeF3mVZ5DrOGw=; b=CVYOeNFKdbzdtDs+nyu2xKZzTc07S2GCOwdb7oX+Wg6SZoBvRfjWebAb0/k3CrxC5q 1UmzhaO0qlpTsfTz8OMbgeygg0FWkT6RlJVr6jJb0XOj7vDB49VGKScIF/veYIBHN7vP EldHihoWy7vVyfaounRe2fteVbA2Q24j1K8qqE8PqvDXvQqQlaZvtqLIYyYiAKQU5lQt XilpFgubTc0yF7eVSMYy/iMDTJ9pHOFs+fNPyHdz6ehiJzz/nyZi1jVQ/KiU+7Wqdjif fb++BGBSqZP6GTQ+U1d4u/uvSSdnt7Sf8M1JUvXhodAuiRuq7wdfwrlwTQ4fZEM9cWc7 t4Pw== X-Gm-Message-State: AG10YOQQVTGneIYFrYO6gCig7qOYc7R+38eYZEWh6jUqXlq1fvIEEsnEPBypzqCIvSFgQcE/tIqQrQ//Tef2tA== X-Received: by 10.31.169.67 with SMTP id s64mr28518820vke.72.1455069035324; Tue, 09 Feb 2016 17:50:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Tue, 9 Feb 2016 17:50:05 -0800 (PST) In-Reply-To: <56B9EEBC.7030007@globis.net> References: <56B9EEBC.7030007@globis.net> From: Mark Smith Date: Wed, 10 Feb 2016 12:50:05 +1100 Message-ID: To: "Ray Hunter (v6ops)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 01:50:37 -0000 Hi Ray, On 10 February 2016 at 00:50, Ray Hunter (v6ops) wrote: > > > Mark Smith wrote: > > > I have read this draft. > Thanks very much for having a read. > At first glance it looks like a smart idea, because a defending router only > has to track perhaps a thousand entries of state versus potentially having > to store state for billions of "incomplete" queries. > > A couple of questions. > > 1) How often/when is the MLD cache updated/ timed out? > MLD operation is not changed, so what ever the MLD protocol timers are. > My concern here is that you now have two caches interacting (mulitcast group > membership and ND cache), and the timing of adding and deleting entries > could cause race conditions. Some discussion of how the caches interact (or > not) could be useful IMHO. > Other than using the MLD membership list to determine if to ND NS for a unknown address, there isn't any interaction between the ND and MLD caches/memberships lists. Was there a section which seemed to imply they were interacting more than the ND process using the information in the MLD membership list? I'm happy to add a statement that they aren't interacting, just wondering if there is a specific section/paragraph where you think it might be best placed? > 2) Why would a router track multicast membership when potentially it could > also just track DAD queries directly when nodes join a link? > The limitation of DAD is that DAD is only performed for unicast addresses, not anycast addresses. I think anycasts are usually going to be configured to provide a highly available service or host, not detecting them somehow and therefore dropping ND NSes for them would be quite a failure! DAD is certainly something that could be used to detect normal unicast addresses, and I think there was a ID about using them for that a few years ago. You're right, there is also the issue of how at router starting detects existing nodes/address that have already completed DAD. I can't remember if I read that ID, however I thought that not detecting anycast addresses was a fairly significant limitation of that method. > Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and > Fiber access architectures. Based on the DAD signaling, the first-hop > router stores in a Binding Table all known IPv6 addresses used on a > point-to-multipoint domain (e.g., VLAN)." > > Couldn't such a cache also be used as a mechanism for defending against > off-link NS exhaustion attacks? > > Obviously if the router joins the link after some nodes are already on link, > then there's a potential for nodes to have already completed DAD before the > router boots, so maybe a poll mechanism triggered by monitoring on-link ND > requests might be appropriate. But then again, if the nodes send any > off-link traffic via this router at all, they'll trigger ND to the router > directly, so it's only a problem for normally silent nodes that receive > inbound sessions. That could be mitigated by scheduling a simple 'ping' on > end nodes acting as servers when they add a new router to their default > router list (with appropriate delays/back off etc.). > Thanks very much, Mark. > -- > regards, > RayH From nobody Tue Feb 9 21:27:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBD11B3734 for ; Tue, 9 Feb 2016 21:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13UOwljK4Q1F for ; Tue, 9 Feb 2016 21:27:52 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 3FD651B3731 for ; Tue, 9 Feb 2016 21:27:51 -0800 (PST) Received: (qmail 89199 invoked from network); 10 Feb 2016 05:27:49 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Feb 2016 05:27:49 -0000 Date: Wed, 10 Feb 2016 06:27:49 +0100 (CET) Message-Id: <20160210.062749.74665060.sthaug@nethelp.no> To: markzzzsmith@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <56B9EEBC.7030007@globis.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@globis.net, v6ops@ietf.org Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 05:27:54 -0000 > > 2) Why would a router track multicast membership when potentially it could > > also just track DAD queries directly when nodes join a link? > > > > The limitation of DAD is that DAD is only performed for unicast > addresses, not anycast addresses. I think anycasts are usually going > to be configured to provide a highly available service or host, not > detecting them somehow and therefore dropping ND NSes for them would > be quite a failure! We use BGP-based "announce the same prefix from different sites" for both IPv6 and IPv4 recursive DNS. But this is not the same as "real" IPv6 anycast (which we don't use). Is there any evidence that "real" IPv6 anycast is used at all? A sample size of one is obviously not conclusive - I'm genuinely curious here. Steinar Haug, AS2116 From nobody Tue Feb 9 22:51:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ED01B37B2 for ; Tue, 9 Feb 2016 22:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHIwSnuoY25k for ; Tue, 9 Feb 2016 22:51:20 -0800 (PST) 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 47B761B37B3 for ; Tue, 9 Feb 2016 22:51:20 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id e6so7007599vkh.2 for ; Tue, 09 Feb 2016 22:51:20 -0800 (PST) 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-type; bh=7k592HqIGelgVC1YSvkxh9NRKa0m9wOqqY6JA6zvR/s=; b=EG3SfJke+6hxvfcdFPIcxCY3kB76x8B2HE/511glDzIB/t8fj/rYiUCSpYuo8jH/pH 2yUoVuhOeCb5TMlX1zBDjiydMVFzAXvpGd2EjoPtyIHOrrJ+g/+gsz9p22jrNZQsjOGk iRLWiiYJyzQv53yAjknzg0KsaTv3M91NTYCV8YXui+609GHbtWoJP5cdWlCReGBA3NdZ XUHsPJIW8eMndu7JEV1nYlm/upE4aBVj8ds/Cw93BaWaIZNjsQHzHLw3m41UvUFuBjoP NIw6FDE9DRojbZVOOlS9J5tgW7lL7f897bWSpKZnqVAHGmYzHhiwPKOFju2VNULFXP9/ HWOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7k592HqIGelgVC1YSvkxh9NRKa0m9wOqqY6JA6zvR/s=; b=ZE3vGc1zD5/g/1Se1jtczboL9sjFu5ErHuJxz9ODuOpcytpWEj5nnL7DAtxJeNx4Q7 INXK31x9QTg2aMKTh/6k2bHz/+ZApfrKKscOK/D2Drhl4bKuxD6d41JGiZe/dM3UMukU wfr7cZqjvs5/vvTLcnlGgOOUSjDOn1cW0C0Yn5ZLgeOLMqG7uXBubmK+Yly3drrmwG2/ C/i9CBq4XKURQ08mR1Z5cSCXyjekdsCi9Utb6I5VlQIcM4sV/hYYkhe792yEm93/Vx8+ LcjYr3yVbF/PGDPDcCQDyo9a4b9YKax9Eyp9MyMoiUNrBrGgLxjDRsBfMA/z8WilUUBG It7w== X-Gm-Message-State: AG10YOSK0GoKH1M2zKt/4k6lLm/UxLGQ/TLK6UQN3hcAGgQIGrEUTAGgYIZs/WCBkcCGChqspdLAZBcYMp7New== X-Received: by 10.31.167.195 with SMTP id q186mr28337391vke.113.1455087079435; Tue, 09 Feb 2016 22:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.103 with HTTP; Tue, 9 Feb 2016 22:50:50 -0800 (PST) In-Reply-To: <20160210.062749.74665060.sthaug@nethelp.no> References: <56B9EEBC.7030007@globis.net> <20160210.062749.74665060.sthaug@nethelp.no> From: Mark Smith Date: Wed, 10 Feb 2016 17:50:50 +1100 Message-ID: To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Ray Hunter \(v6ops\)" , v6ops list Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 06:51:21 -0000 On 10 February 2016 at 16:27, wrote: >> > 2) Why would a router track multicast membership when potentially it could >> > also just track DAD queries directly when nodes join a link? >> > >> >> The limitation of DAD is that DAD is only performed for unicast >> addresses, not anycast addresses. I think anycasts are usually going >> to be configured to provide a highly available service or host, not >> detecting them somehow and therefore dropping ND NSes for them would >> be quite a failure! > > We use BGP-based "announce the same prefix from different sites" for > both IPv6 and IPv4 recursive DNS. But this is not the same as "real" > IPv6 anycast (which we don't use). > > Is there any evidence that "real" IPv6 anycast is used at all? A sample > size of one is obviously not conclusive - I'm genuinely curious here. > It don't have any data, however I think it probably isn't used much because most people are probably thinking of IPv6 as the functional equivalent of IPv4, and therefore aren't all that aware of its new capabilities or haven't thought much about how to use them. (One of the reasons I put quite a bit of explanation in that draft about the use of Solicited-Node groups in ND is because I think there is a possibility not many people are all that aware of how they're used in ND.) The key thing that "real" IPv6 anycast gives you is the ability to provide anycast services to other nodes attached to the same link as the anycast servers/services. I've thought DNS and NTP could be examples of use - e.g., in a branch office with a single LAN, where you want to have local redundant DNS and NTP servers available on the same LAN segment, with them all active at the same time. Regards, Mark. From nobody Wed Feb 10 00:55:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAEF1A0252 for ; Wed, 10 Feb 2016 00:55:40 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzkbPzl0QdOy for ; Wed, 10 Feb 2016 00:55:36 -0800 (PST) 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 25B1A1A024C for ; Wed, 10 Feb 2016 00:55:36 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 2CACB206AC6; Wed, 10 Feb 2016 09:55:32 +0100 (CET) To: otroan@employees.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56BAF73D.9040707@si6networks.com> Date: Wed, 10 Feb 2016 05:39:25 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 08:55:40 -0000 Hi, Ole, On 02/09/2016 09:56 AM, otroan@employees.org wrote: > > my point was that it was absurd to try to design network protocols in > a way that they would accommodate any possible policy decision made > in the network or by end-hosts. it isn't the IETFs job to try to > bypass whatever policy a network choses to implement. My take here is that some design decisions make it hard for networks to enforce the policies they choos to enforce. e.g., I recall you quoting S. Deering suggesting that the EH structure was meant to make the life of middleboxes painful. I regard that as a rather bad design decision (put another way: would you have EH chains the way we have them n IPv6 if you were to redesign IPv6?). > if we accept that e.g. a transit network needs to look into L4 or > deeper, then we also accept we can never make any innovations at this > layer. (and we've essentially accepted that the Internet is going to > be just an underlay for whatever comes next). Not necessarily. There are essentially two issues here: 1) The Next-Header space is not self describing. It should be possible to skip past unknown EHs. I presented a proposal (draft-gont-6man-rfc6564bis-01), but we did nothing about it. (there could be other alternatives, such as prohibiting the specification of new EHs... but we did nothing about it). 2) EH chains can be very long. Me, I'd prefer that we get to some compromise (e.g., "everyone must support EH chains of at least 256 bytes to be able to claim they are IPv6-ready"), rather than what we have now: we pretend that nodes support the currently unlimited EH chain lengths, but in practice it gets hard to pass a 10B chain through. > I can't think of many examples where a transit network would require > to parse the extension chain. We have examples in draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt (supplied by folks running such networks). > in the case of ECMP, we are better off > with IPv6 than IPv4, although we have to do something to get > flow-label based ECMP deployed / implemented. Agreed. > but even today you can do reasonably well without parsing EHs: > > if (flow_label > 0) { flow_hash = f4(sa,da,protocol, flow) } else { > if (nh == UDP|TCP) { flow_hash = f5(sa,da,protocol,sport,dport) } // > Do something with GRE keys } else { flow_hash f3(sa,da,protocol) } > adj_index = flow_hash & (nadj - 1) Probably the ECMP case is easier to solve in the near term. OTOH, the ability to do packet filtering doesn't look easy to solve if we keep the (rather onerous nowadays) requirement of supporting arbitrarily-long EH chains. FWIW, this is just me trying to make things work, and trying to find a middle-ground between the theoretical requirements we expect implementations to comply with, and the "I will drop all the EH-enabled packets" that seems to be rather widespread. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 10 01:19:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8321A038E for ; Wed, 10 Feb 2016 01:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvYD22gEPubz for ; Wed, 10 Feb 2016 01:19:55 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42861A038F for ; Wed, 10 Feb 2016 01:19:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 109D13C4D; Wed, 10 Feb 2016 10:19:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1455095991; bh=P3mfTpXQQjJoMLKFhGW0o0LeIWpI iPdMp7LaN4GaGsI=; b=d+tHon5kxg/R07iozXOL6v4yNxUqYdwhtt9n9RqxsDl6 SM2vRyomu+pf275g3W1QVzWPgIr5B2WIlYxAv7UV8SSrMiuem/K6rt1qPaNaV29I s/u0dq/6DLFSWbWpo03nhn3Bm86AOTJ+8g6hKFzW+OyMwapTQDagWIulmVedsWg= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bJBfHlvhazsS; Wed, 10 Feb 2016 10:19:51 +0100 (CET) Received: from [10.240.231.235] (unknown [212.72.40.187]) by mail.sintact.nl (Postfix) with ESMTPSA id B5D273C4C; Wed, 10 Feb 2016 10:19:50 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DE4D0409-9DBA-4E30-8A85-AED9F89FC581"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <56B92BEE.2020800@foobar.org> Date: Wed, 10 Feb 2016 10:19:53 +0100 Message-Id: <45A7BA5F-8C97-409E-A562-9689976A792E@steffann.nl> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90202.9070603@foobar.org> <56B90A6F.7010803@isi.edu> <56B90B56.5010507@foobar.org> <56B90D1D.7010105@isi.edu> <56B90F2E.6050204@foobar.org> <56B91218.6060402@isi.edu> <56B92BEE.2020800@fo obar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:19:57 -0000 --Apple-Mail=_DE4D0409-9DBA-4E30-8A85-AED9F89FC581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > It's not useful to deny the existence of practical limitations of any > particular design. It's a lot more more useful to acknowledge that > trade-offs occur and to create a set of reasonable implementation > expectations. For example, that ipv6 implementations should process = up > to N bytes of EHs, or that EHs should only be attached to the first > packet and not on subsequent fragments. If this isn't done, then > vendors will make their own decisions about what's practical for them, > and the results may not be what you want. +1 In theory, there is no difference between theory and practice. But, in = practice, there is. Agreed-upon and expected limitations are much much better than every = vendor doing something not well defined. Cheers, Sander --Apple-Mail=_DE4D0409-9DBA-4E30-8A85-AED9F89FC581 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 iQEcBAEBCgAGBQJWuwC5AAoJEB7hi8LTyHy2E1kH/jQcl8quMSwpeGL4QTuqOACu ijupI1ua6QCCS2QOrjpDfDj3kvumBsWb2MlUgM/TN6xKxVhpvpf5KpAbNjJLKOFc GNdYeZ+N0WWvNPLwVg94EV/PK1eq4eWbP5ZXPLMyN2PsXgkN4tManBwUVerf23T+ khw4MRECR5WvgybFKdEWjox3G4J4Qi+gbvUVtCPu3P+uCkC+ZUvd2Ke8ReeIGb3x xZ6nRo5cXAxoPGcdUS5MO1eQCFfGcUC6Ew7awi4AJTKs5HhCeVRg0ZvfVfBEFQ7S m0JdIwhWyas5mX96NVqLpBL3f7SXfOq+aU5OYtWp22uQoc3d2xO6Hl65N0voi1M= =E0ic -----END PGP SIGNATURE----- --Apple-Mail=_DE4D0409-9DBA-4E30-8A85-AED9F89FC581-- From nobody Wed Feb 10 01:52:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B421A0A6A for ; Wed, 10 Feb 2016 01:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39zoBfGfjSOp for ; Wed, 10 Feb 2016 01:52:45 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2801A064C for ; Wed, 10 Feb 2016 01:52:44 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 661FBD7888; Wed, 10 Feb 2016 01:52:43 -0800 (PST) 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=2TN4dKpdUk0PuGALBH9iTWCMvD4=; b= rmAiYOqn51oT8cPG9x3KgUhl4NncwOrtFHYaikFUgjcN2albK1E1XWRLu6n7+IFG IJHDxvh+fZABp0NngCQjWrVWkYDWviv8CDqqXTm7ebqr+MlP5vB6zLHwT7dlpbiA xbEqWUGLZ5kf43FC8CUeIaePU2Q0Loewk00agLgQMFI= 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=JN9fGVcxHezZ9lEkvFCcZDO9Aj k2hpFkD9YVieY/XkTzSkGhydx89V3uuKlbEdVdsJNGcVDJHBod3I1IpNYw7pUCx9 wHQzXOML7c6WGxvsPHvbS9vaXPVX3KYhAVWAeB0XAHbFVAnSIiOLwky6lEjjtgGA 4Ere0wRb2SZsVJ1rA= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 F1DF3D7881; Wed, 10 Feb 2016 01:52:42 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C115210B1FBD; Wed, 10 Feb 2016 10:52:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0960C2AB-E19C-40C0-AFB7-2D516E6E8AA4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56BAF73D.9040707@si6networks.com> Date: Wed, 10 Feb 2016 10:52:38 +0100 Message-Id: <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:52:47 -0000 --Apple-Mail=_0960C2AB-E19C-40C0-AFB7-2D516E6E8AA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fernando, >> my point was that it was absurd to try to design network protocols in >> a way that they would accommodate any possible policy decision made >> in the network or by end-hosts. it isn't the IETFs job to try to >> bypass whatever policy a network choses to implement. >=20 > My take here is that some design decisions make it hard for networks = to > enforce the policies they choos to enforce. >=20 > e.g., I recall you quoting S. Deering suggesting that the EH structure > was meant to make the life of middleboxes painful. I regard that as a > rather bad design decision (put another way: would you have EH chains > the way we have them n IPv6 if you were to redesign IPv6?). >=20 >=20 >=20 >> if we accept that e.g. a transit network needs to look into L4 or >> deeper, then we also accept we can never make any innovations at this >> layer. (and we've essentially accepted that the Internet is going to >> be just an underlay for whatever comes next). >=20 > Not necessarily. There are essentially two issues here: >=20 > 1) The Next-Header space is not self describing. It should be possible > to skip past unknown EHs. I presented a proposal > (draft-gont-6man-rfc6564bis-01), but we did nothing about it. (there > could be other alternatives, such as prohibiting the specification of > new EHs... but we did nothing about it). right, it isn't clear that is solving the problem. if walking the chain is done by a middlebox for the purpose of = "security", then it would be highly unlikely that it would allow an = unknown extension header. for a router doing ECMP we should instead make the flow label usable. what we have done, is to make it very unlikely that new extension = headers will be defined. given that we have the three extensible = containers, RH, DestOpt and HBH. and we might be making parsing the HBH = optional. > 2) EH chains can be very long. Me, I'd prefer that we get to some > compromise (e.g., "everyone must support EH chains of at least 256 = bytes > to be able to claim they are IPv6-ready"), rather than what we have = now: > we pretend that nodes support the currently unlimited EH chain = lengths, > but in practice it gets hard to pass a 10B chain through. right, but within the constraints of RFC7112. for routers that number is and always have been 40. :) for middleboxes it is dependent on policy, and since that could = typically be to parse the whole packet... >> I can't think of many examples where a transit network would require >> to parse the extension chain. >=20 > We have examples in draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt > (supplied by folks running such networks). sorry, I don't see any examples there where a transit network would = require to look deeper than 40 bytes. in the case of DDOS that would be filters that would match a signature, = and I'd imagine that include extension headers right. >> in the case of ECMP, we are better off >> with IPv6 than IPv4, although we have to do something to get >> flow-label based ECMP deployed / implemented. >=20 > Agreed. >=20 >=20 >=20 >> but even today you can do reasonably well without parsing EHs: >>=20 >> if (flow_label > 0) { flow_hash =3D f4(sa,da,protocol, flow) } else { >> if (nh =3D=3D UDP|TCP) { flow_hash =3D f5(sa,da,protocol,sport,dport) = } // >> Do something with GRE keys } else { flow_hash f3(sa,da,protocol) } >> adj_index =3D flow_hash & (nadj - 1) >=20 > Probably the ECMP case is easier to solve in the near term. OTOH, the > ability to do packet filtering doesn't look easy to solve if we keep = the > (rather onerous nowadays) requirement of supporting arbitrarily-long = EH > chains. >=20 > FWIW, this is just me trying to make things work, and trying to find a > middle-ground between the theoretical requirements we expect > implementations to comply with, and the "I will drop all the = EH-enabled > packets" that seems to be rather widespread. right, this is simply a result of the tussle between the different = actors on the network. if anything IETF should try to be neutral in that tussle. cheers, Ole --Apple-Mail=_0960C2AB-E19C-40C0-AFB7-2D516E6E8AA4 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 iQIcBAEBCgAGBQJWuwhnAAoJEL7aWKiYQt92lFkP/0qsXE195vJoHOiW5k5MPUjy S72rMd+3xQcVrcNAdXmYru/b+cXBkkX7vfeeLKnrIsDnFxwynKDdyDRtuC5tX0b5 do1Jcd4aDcn8ETh6iwgbwgNXqXRDzYPjZvQQ0TaVJ5qs0/MrutkMG8uh2AyRUHGw z0ZzjwScv2asvEq61St4t+wWvMXCBSBNGAoDs4pMxNwfbKIu0h8mbYKglG2/uLY+ ve0njksJyH+9YhZWpdvS9Z3YOL0MGnJG4YfJw3Om6XNp2YUuF/j0RYtXPmWNoU81 HConW4XZ9XKZdEGS09eGDFtGYbDacEieIrqnA7BmA8m7eLWdYKvK/YWvDt+Oj0WQ 2ujmH0+ROZuq4ZX/A1H/8rxaODTfJoyCWQDVO86shkMPh+pAHeM0ZLUB4k3JuxcZ 6oUM/ZP5e98m0AVN1EDng5Hv40kMrUXeQjN3D1gTaUge2Ip7yYdMExeRU+X5HRPJ C+JqKIFDT6SJDC5kcm+lACB/0GaLdfA4SjyaLIscDwSzL0vqqF5vGmX62wfKGGFG 0NBqNIZmM/HdhRt8nYBR9BZhpy929QGEKkc/sfvnSEqv17guA/q7CS/7Rjas/l8V Ht7YcqJUyd21J3wZa6Wqu0tEGnlOjawthJf0lFCYXTi5JzinznJJfD1WgoiAfNEP v5ciuUqObeF7pxIFwilJ =VJA4 -----END PGP SIGNATURE----- --Apple-Mail=_0960C2AB-E19C-40C0-AFB7-2D516E6E8AA4-- From nobody Wed Feb 10 02:25:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D51A1A5A for ; Wed, 10 Feb 2016 02:25:26 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJJ03cWJfdwL for ; Wed, 10 Feb 2016 02:25:23 -0800 (PST) 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 3956C1A1A55 for ; Wed, 10 Feb 2016 02:25:23 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 AD993206B76; Wed, 10 Feb 2016 11:25:19 +0100 (CET) To: otroan@employees.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56BB0F47.6000804@si6networks.com> Date: Wed, 10 Feb 2016 07:21:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 10:25:26 -0000 On 02/10/2016 06:52 AM, otroan@employees.org wrote: >> >>> if we accept that e.g. a transit network needs to look into L4 >>> or deeper, then we also accept we can never make any innovations >>> at this layer. (and we've essentially accepted that the Internet >>> is going to be just an underlay for whatever comes next). >> >> Not necessarily. There are essentially two issues here: >> >> 1) The Next-Header space is not self describing. It should be >> possible to skip past unknown EHs. I presented a proposal >> (draft-gont-6man-rfc6564bis-01), but we did nothing about it. >> (there could be other alternatives, such as prohibiting the >> specification of new EHs... but we did nothing about it). > > right, it isn't clear that is solving the problem. if walking the > chain is done by a middlebox for the purpose of "security", then it > would be highly unlikely that it would allow an unknown extension > header. That's the point: you cannot tell if what's inside is an EH or an upper-layer protocol. If the device is whitelisting stuff, I'd agree with you on the end-result. OTOH, if the devices means to blacklist stuff, then this may lead to unnecessarily packet drops. And, in any case, a bug is a bug. We're pretending that RFC6564 can be employed to skip past unknown EHs, when it really can't. > for a router doing ECMP we should instead make the flow label > usable. > > what we have done, is to make it very unlikely that new extension > headers will be defined. given that we have the three extensible > containers, RH, DestOpt and HBH. and we might be making parsing the > HBH optional. Then let's say that. Right know, given an unknown Next Header, it's impossible to tel whether it's an EH or an ULP. I don't care if we go forward with what we propose in our rfc6564bis I-D, or we just ban the definition of new EHs. Anything is better than leaving the bug in. >> 2) EH chains can be very long. Me, I'd prefer that we get to some >> compromise (e.g., "everyone must support EH chains of at least 256 >> bytes to be able to claim they are IPv6-ready"), rather than what >> we have now: we pretend that nodes support the currently unlimited >> EH chain lengths, but in practice it gets hard to pass a 10B chain >> through. > > right, but within the constraints of RFC7112. for routers that number > is and always have been 40. :) 40B? If it's an implementation limit, it'd be great that we all agree that 40B is the least common denominator. Besides, whatever the number, there can be as many instances of HBH as desired.. so even for routers, you still have to support at least up-to-MTU long EH chains. > for middleboxes it is dependent on > policy, and since that could typically be to parse the whole > packet... > >>> I can't think of many examples where a transit network would >>> require to parse the extension chain. >> >> We have examples in draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt >> (supplied by folks running such networks). > > sorry, I don't see any examples there where a transit network would > require to look deeper than 40 bytes. in the case of DDOS that would > be filters that would match a signature, and I'd imagine that include > extension headers right. The examples basically boil down to happing to enforce some sort of filters that require layer-4 info. >> Probably the ECMP case is easier to solve in the near term. OTOH, >> the ability to do packet filtering doesn't look easy to solve if we >> keep the (rather onerous nowadays) requirement of supporting >> arbitrarily-long EH chains. >> >> FWIW, this is just me trying to make things work, and trying to >> find a middle-ground between the theoretical requirements we >> expect implementations to comply with, and the "I will drop all the >> EH-enabled packets" that seems to be rather widespread. > > right, this is simply a result of the tussle between the different > actors on the network. if anything IETF should try to be neutral in > that tussle. But when we don't try to be pragmatic and agree on what is supported, the result is not good: I'd prefer to be "limited" in the EH chains that I can use, but to know that I can rely on e.g. up to 64B or 256B EH-chains. Right know, since our requirement to support arbitrarily-long EHs is generally seen as too onerous, the end result is that folks don't care to support EHs, and hence you wouldn't even hope to have your 10B EH chains go through the network. I'm not even arguing about an actual modification to the spec (i.e., and enforced upper limit), but e.g. and enforced lower limit that everyone has to support (which could be increased overtime). -- if we really won't EHs to be deployable. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 10 03:30:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7FC1A1B6D for ; Wed, 10 Feb 2016 03:29:59 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2dKuttdNw8A for ; Wed, 10 Feb 2016 03:29:57 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C23561A1B69 for ; Wed, 10 Feb 2016 03:29:56 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aTSxz-0000CUC; Wed, 10 Feb 2016 12:29:51 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> In-reply-to: Your message of "Wed, 10 Feb 2016 07:21:59 -0300 ." <56BB0F47.6000804@si6networks.com> Date: Wed, 10 Feb 2016 12:29:43 +0100 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 11:29:59 -0000 In your letter dated Wed, 10 Feb 2016 07:21:59 -0300 you wrote: >That's the point: you cannot tell if what's inside is an EH or an >upper-layer protocol. > >If the device is whitelisting stuff, I'd agree with you on the >end-result. OTOH, if the devices means to blacklist stuff, then this may >lead to unnecessarily packet drops. > >And, in any case, a bug is a bug. Call me paranoid, but I'm quite happy if a security device drops stuff it doesn't understand. It shouldn't be that hard to support a white list of unknown extension headers that can be set by the operator. >But when we don't try to be pragmatic and agree on what is supported, >the result is not good: I'd prefer to be "limited" in the EH chains that >I can use, but to know that I can rely on e.g. up to 64B or 256B EH-chains. > >Right know, since our requirement to support arbitrarily-long EHs is >generally seen as too onerous, the end result is that folks don't care >to support EHs, and hence you wouldn't even hope to have your 10B EH >chains go through the network. It is always possible to find an excuse for not doing something. There is a very common pattern of a fragmentation header in front of a UDP header, which just needs to be supported on todays internet. Beyond that, I haven't seen a strong desire for extension headers expressed outside IETF mailing lists. So there the use cases seem quite remote compared to all other new features that need to be supported. From nobody Wed Feb 10 03:47:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD51B1A1BD7 for ; Wed, 10 Feb 2016 03:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h70u-LXy8yD for ; Wed, 10 Feb 2016 03:47:32 -0800 (PST) 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 0E81C1A1BED for ; Wed, 10 Feb 2016 03:47:32 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 7BEE4206B73; Wed, 10 Feb 2016 12:47:26 +0100 (CET) To: Philip Homburg , v6ops@ietf.org References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56BB2341.4030002@si6networks.com> Date: Wed, 10 Feb 2016 08:47:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 11:47:34 -0000 On 02/10/2016 08:29 AM, Philip Homburg wrote: > In your letter dated Wed, 10 Feb 2016 07:21:59 -0300 you wrote: >> That's the point: you cannot tell if what's inside is an EH or an >> upper-layer protocol. >> >> If the device is whitelisting stuff, I'd agree with you on the >> end-result. OTOH, if the devices means to blacklist stuff, then this may >> lead to unnecessarily packet drops. >> >> And, in any case, a bug is a bug. > > Call me paranoid, but I'm quite happy if a security device drops stuff it > doesn't understand. Agreed. What I'm saying is that in scenarios in which you just want to drop stuff that is known to be evil, but otherwise pass everything else, you'd need to be able to jump past unknown EHs, and you currently cannot do that. And I think you should be able to. (Do I think this is an issue *now*? -- Obviously not... even the standard EHs don't get to survive the Internet in over 20% of cases). That aside, we currently assume that it is possible to jump past unknown EHs when it's not really possible. That's a current bug in our specs. > It shouldn't be that hard to support a white list of unknown extension > headers that can be set by the operator. How do you skip past an unknown EH? >> But when we don't try to be pragmatic and agree on what is supported, >> the result is not good: I'd prefer to be "limited" in the EH chains that >> I can use, but to know that I can rely on e.g. up to 64B or 256B EH-chains. >> >> Right know, since our requirement to support arbitrarily-long EHs is >> generally seen as too onerous, the end result is that folks don't care >> to support EHs, and hence you wouldn't even hope to have your 10B EH >> chains go through the network. > > It is always possible to find an excuse for not doing something. > > There is a very common pattern of a fragmentation header in front of a UDP > header, which just needs to be supported on todays internet. > > Beyond that, I haven't seen a strong desire for extension headers expressed > outside IETF mailing lists. So there the use cases seem quite remote > compared to all other new features that need to be supported. What concerns me is that we pretend that there is stuff (EHs) that is deployable, when it currently isn't. So we better try to do something to get some subset of that deployable (and it becomes clear that you can only rely on such subset to work) and we declare some sort of humble victory :-), or we forget about it and assume defeat. What worries me is when there is a disconnect between the specs and the real world: a folk that reads the spec assumes that something will work, but he misses the unwritten wisdom that says that part of what we read actually fails badly. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 10 04:18:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7B1A219C for ; Wed, 10 Feb 2016 04:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goMKX93r_tUf for ; Wed, 10 Feb 2016 04:18:25 -0800 (PST) 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 AFC131A1AD9 for ; Wed, 10 Feb 2016 04:18:24 -0800 (PST) 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 u1ACIMkd009480 for ; Wed, 10 Feb 2016 13:18:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5E2CE205A68 for ; Wed, 10 Feb 2016 13:26:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53C89205886 for ; Wed, 10 Feb 2016 13:26:39 +0100 (CET) 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 u1ACIM3a030656 for ; Wed, 10 Feb 2016 13:18:22 +0100 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <56BB2A8E.3040004@gmail.com> Date: Wed, 10 Feb 2016 13:18:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080504050001070501010106" Archived-At: Subject: [v6ops] distributed gaming on IPv6 - any platform? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 12:18:26 -0000 This is a multi-part message in MIME format. --------------080504050001070501010106 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Is there any distributed gaming platform that runs on IPv6 too? A colleague informs me that the opensource GamingAnywhere does not support IPv6. But IP is very important between the gamepad and the box. The use of IPv4/USB between a pad and a box (rather than USB) allows several enhancements like energy efficiency, smartphone-as-gamepad, etc. If IPv6 is considered between the pad and the box, it can become a significant use-case for technologies like 64share, DHCPv6-PD, and in general the need for multiple IPv6 addresses per device. Is there any distributed gaming platform that runs on IPv6 too? Alex --------------080504050001070501010106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

Is there any distributed gaming platform that runs on IPv6 too?

A colleague informs me that the opensource GamingAnywhere does not support IPv6.

But IP is very important between the gamepad and the box.  The use of IPv4/USB between a pad and a box (rather than USB) allows several enhancements like energy efficiency, smartphone-as-gamepad, etc.

If IPv6 is considered between the pad and the box, it can become a significant use-case for technologies like 64share, DHCPv6-PD, and in general the need for multiple IPv6 addresses per device.

Is there any distributed gaming platform that runs on IPv6 too?

Alex

 --------------080504050001070501010106-- From nobody Wed Feb 10 04:18:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A822F1A21A2 for ; Wed, 10 Feb 2016 04:18:33 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIBgzJXec_iZ for ; Wed, 10 Feb 2016 04:18:32 -0800 (PST) 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 B7BE11A21A0 for ; Wed, 10 Feb 2016 04:18:31 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aTTiw-0000CVC; Wed, 10 Feb 2016 13:18:22 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <56BB2341.4030002@s i6networks.com> In-reply-to: Your message of "Wed, 10 Feb 2016 08:47:13 -0300 ." <56BB2341.4030002@si6networks.com> Date: Wed, 10 Feb 2016 13:18:16 +0100 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 12:18:33 -0000 In your letter dated Wed, 10 Feb 2016 08:47:13 -0300 you wrote: >Agreed. What I'm saying is that in scenarios in which you just want to >drop stuff that is known to be evil, but otherwise pass everything else, >you'd need to be able to jump past unknown EHs, and you currently cannot >do that. And I think you should be able to. > >That aside, we currently assume that it is possible to jump past unknown >EHs when it's not really possible. That's a current bug in our specs. I think it would be perfectly fine if a vendor supports unknown extension headers only if they conform to RFC 6564, which is standards track. So the only thing is that operators would have to explictly mark protocol values as RFC-6564 compatible extension headers that are safe to ignore. The 'safe to ignore' part has to be manual anyhow. >What concerns me is that we pretend that there is stuff (EHs) that is >deployable, when it currently isn't. > >So we better try to do something to get some subset of that deployable >(and it becomes clear that you can only rely on such subset to work) and >we declare some sort of humble victory :-), or we forget about it and >assume defeat. > >What worries me is when there is a disconnect between the specs and the >real world: a folk that reads the spec assumes that something will work, >but he misses the unwritten wisdom that says that part of what we read >actually fails badly. What I'm missing is strong demand for extension headers (other than fragmentation) outside the IETF. I.e., if I would design an IPv6 firewall today, I would make sure fragmentation works, but put all other extension headers as nice to have. In the end, demand has to come from operators and users. From nobody Wed Feb 10 04:21:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5F1A21A1 for ; Wed, 10 Feb 2016 04:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jIq0wrw4kpR for ; Wed, 10 Feb 2016 04:21:45 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF561A21A4 for ; Wed, 10 Feb 2016 04:21:45 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 80744D7883; Wed, 10 Feb 2016 04:21:44 -0800 (PST) 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=O96sVb67jk1cVXe5weyZSlcCxHA=; b= Jhuxajxr+8gcpLcG11a1qjsKPK06mF2vkqoSolnZrwDcEk68wzAKzSiehg9zSupi gmw85VpDJ/cwaoE599nHz+ySt2PCoTQ9UfQlmgFJTE8lMAlIlpbz9Pqf4EMfTRkM KUbsTAtHJmS12AyvBXdM9HrnKH7F7NR0CaZobZL43EE= 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=XG7CN6AWHWniSWx+xbZkznf7xV s8kLlDinbg2D2nPi+vHK7SDOpD6r08qS+QuNAg1WSvT/67lWT0NqSutnukWkmjd0 95mhFD7KQCr6thMInD4uQ4TJeqLWyx1ZxLcxiNdMk1SfXXaS0i/c97NqHNMDL9Cu Ljq/2VEAIqJDl94Lo= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 19F85D7888; Wed, 10 Feb 2016 04:21:44 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5985810B6C89; Wed, 10 Feb 2016 13:21:41 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9E6CC5E9-BAF0-4FF1-81FC-B899D8C4BADE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <56BB0F47.6000804@si6networks.com> Date: Wed, 10 Feb 2016 13:21:39 +0100 Message-Id: <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 12:21:47 -0000 --Apple-Mail=_9E6CC5E9-BAF0-4FF1-81FC-B899D8C4BADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fernando, >>> Not necessarily. There are essentially two issues here: >>>=20 >>> 1) The Next-Header space is not self describing. It should be >>> possible to skip past unknown EHs. I presented a proposal >>> (draft-gont-6man-rfc6564bis-01), but we did nothing about it. >>> (there could be other alternatives, such as prohibiting the >>> specification of new EHs... but we did nothing about it). >>=20 >> right, it isn't clear that is solving the problem. if walking the >> chain is done by a middlebox for the purpose of "security", then it >> would be highly unlikely that it would allow an unknown extension >> header. >=20 > That's the point: you cannot tell if what's inside is an EH or an > upper-layer protocol. >=20 > If the device is whitelisting stuff, I'd agree with you on the > end-result. OTOH, if the devices means to blacklist stuff, then this = may > lead to unnecessarily packet drops. >=20 > And, in any case, a bug is a bug. >=20 > We're pretending that RFC6564 can be employed to skip past unknown = EHs, > when it really can't. no, we're not. we're saying that skipping past unknown headers is not = useful/possible in the general case. >> for a router doing ECMP we should instead make the flow label >> usable. >>=20 >> what we have done, is to make it very unlikely that new extension >> headers will be defined. given that we have the three extensible >> containers, RH, DestOpt and HBH. and we might be making parsing the >> HBH optional. >=20 > Then let's say that. Right know, given an unknown Next Header, it's > impossible to tel whether it's an EH or an ULP. >=20 > I don't care if we go forward with what we propose in our rfc6564bis > I-D, or we just ban the definition of new EHs. Anything is better than > leaving the bug in. https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-03#section-4.8 >>> 2) EH chains can be very long. Me, I'd prefer that we get to some >>> compromise (e.g., "everyone must support EH chains of at least 256 >>> bytes to be able to claim they are IPv6-ready"), rather than what >>> we have now: we pretend that nodes support the currently unlimited >>> EH chain lengths, but in practice it gets hard to pass a 10B chain >>> through. >>=20 >> right, but within the constraints of RFC7112. for routers that number >> is and always have been 40. :) >=20 > 40B? >=20 > If it's an implementation limit, it'd be great that we all agree that > 40B is the least common denominator. IPv6 has had that limit for 20 years. > Besides, whatever the number, there can be as many instances of HBH as > desired.. so even for routers, you still have to support at least > up-to-MTU long EH chains. we're changing that: https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00 [...] cheers, Ole --Apple-Mail=_9E6CC5E9-BAF0-4FF1-81FC-B899D8C4BADE 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 iQIcBAEBCgAGBQJWuytVAAoJEL7aWKiYQt92CzoQAKIed/7xDRylCdHwbN2iypor GBlNkO2XcR1LOriw+/sH2zKgwUzlfzuswX28533nXK5219j9dXCQlRRRvALiAstb Xl8z6NvlSHS8wEkSY+bgt37dVn0sjGKSNCF2pdBGPBsSaHKAu/DVuvggTXfASTOz /BMqARWFVtUc/K5JmMZwPItWWEB6GB9XnRz6kLHc75vj7kikUAYNqOYDtap5zx3s VqZqsmE8Pag8GHhdlDhR4/JeKW1EScA1X2QQZkggw7njoQF+1jtNTgqbs/5lOk/5 kpmU5+Tlx2SnIf8imhMt5JtM02H3ENz7cT+hRoHlrP1sigzc/j+hfT45yjOnLIOh 3dcQGNFl/K0Cdqal+pwOxeQpCc1IWRnWXXx2IFtIaCvpBbmo24ly1R3woyVUJHf5 z1bEyamg4PnwyQURR120/ibTT55JAZzMvV7iBw/PmKKQubsIj4HjQZObl4AwyTTa 4HbZ+3bLPc8QFbIK0K/So1J7dFXELfd/s6CTYxO8ABpHf1hvfle5L+PEKQRw1Igm mJzJcK6Ff67x+CewPR8nQK2/XIUwp1Nj57NRti0NwCgK8BWy8fq1IrkX4kKiOpDa 4skdlKPovKKD/GbAmxAfDigJ41x3xWwolptCiyk7rLDzlNJKyE1fAaa/WQ+at46Z byVPctsOA/RiVsHzWc+8 =EsEz -----END PGP SIGNATURE----- --Apple-Mail=_9E6CC5E9-BAF0-4FF1-81FC-B899D8C4BADE-- From nobody Wed Feb 10 04:28:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006871A21BB for ; Wed, 10 Feb 2016 04:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ6SaMb0ScP5 for ; Wed, 10 Feb 2016 04:28:11 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0E21A21B1 for ; Wed, 10 Feb 2016 04:28:11 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F1089D7884; Wed, 10 Feb 2016 04:28:10 -0800 (PST) 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=D1ow4oAOXRdHfgAUCG6qTb8i9ck=; b= UDldeKyxcnrxr8cVU8ILXFIYOoslP32kyFPAF28p6j9/Ojqk9Gs2wOrWpBX4pSSt YJZGF7rVaGqJo3/ha58oiz3/qanCAOTO355GkOuZbHCekSVZTQMGev7cOhhD/mif 8pX0whUmKSp4PIpQD825KMJZWePW41BRy1DQN8yLZyo= 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=aeyYR+2UH9PrgXfRUxm3Yi8iAx YR8SotcuijggLVEKK39j5lxy+J968Vu43i09O9iUX5VE3r0pG6eleN4gi/SBiJpC Pp6t0oylAD7Zdo0pA/Jg+eLB39j2DvFZgr+hdgScw2BT2nbDexSfarW/kboTiY5B 2Nq+w5yNBkQG65MIE= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 451F6D7883; Wed, 10 Feb 2016 04:28:10 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2F04810B6F91; Wed, 10 Feb 2016 13:27:57 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E0E95FDC-38C9-4CAC-A467-B0920ACD41ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Wed, 10 Feb 2016 13:27:56 +0100 Message-Id: References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org> <56B668C3.8090009@foobar.org> <56B67671.3010409@foobar.org> <56B742AC.7010307@foobar.org> <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com> <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <56BB2341.4030002@s i6networks.com> To: Philip Homburg X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 12:28:13 -0000 --Apple-Mail=_E0E95FDC-38C9-4CAC-A467-B0920ACD41ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I.e., if I would design an IPv6 firewall today, I would make sure = fragmentation > works, but put all other extension headers as nice to have. if I would design an IPv6 firewall today I'd drop most fragments. they = are nothing but a DOS vector (for middleboxes). (and I've formed that opinion after actually implementing an RFC7597 = BR.) Best regards, Ole --Apple-Mail=_E0E95FDC-38C9-4CAC-A467-B0920ACD41ED 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 iQIcBAEBCgAGBQJWuyzMAAoJEL7aWKiYQt92ujEQAKVa6bCy7A+tbPeyy6xpxY1r D95u8E5sUNZLFNXmd0GrWo6ca75JjYTLKEjN241oNigBr0ARliSSLvhdyzGiUTEr nunQGHFG0wb0GclxbyEVAiFjt/tVCk8L6GAgm2wXnlQolyoj66UBlJs4HOnsw1BX ZfPfrPUAunzIUm3Nro5/kAGq8ZGwv48akPpFYZxqjGvfGAepr6YFaSzHGV8rFmul iTaeCCGP+TlIKTtBItyeKPSCdMEafjOcWARHB8XkA/msUJyx5Pb0DcrRLoJ0Utsp w8001k14mkYDw+EkUkHLIn8Jaq6iB47rU1P6Ey6f0az2jHTMEYPw3643hJ54GmXN n6dz/Wfly4dNfEW2H6y77kIlhXK4V5SuuQiUaXwR+FujQeu7/1+aLe0rKAXJNRQR 89pvIbiI6P90PU5hIH7mpWaLjYWMCBhM9h9WYH3esspfcUbqDRcqNBxzzf7RKFJM o5aQtGcDHv0Vj5oRsM77CSw6SLiGEmfad9s8rEqigpRvPqI9u8tDk6kDwGBs4VsG /Si6945uMaBjMtG6qXYooRayyvsOu4q29OsQE856AxFHGs0X+kDNmMGYfaPVU5rQ UY4Ts2ove261RdBYqnUroiyB9pam0k50EbByc9BOEuQPWVJfov66zEBtV6CJpqCh MClb+rBIqICHwrotJ4WO =dHZ/ -----END PGP SIGNATURE----- --Apple-Mail=_E0E95FDC-38C9-4CAC-A467-B0920ACD41ED-- From nobody Wed Feb 10 04:29:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE61A21BB for ; Wed, 10 Feb 2016 04:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M74TZUOIDel2 for ; Wed, 10 Feb 2016 04:29:55 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 275091A21BF for ; Wed, 10 Feb 2016 04:29:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3A9FB62AE0 for ; Wed, 10 Feb 2016 13:29:31 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8C3C760352 for ; Wed, 10 Feb 2016 13:29:29 +0100 (CET) Received: (qmail 93697 invoked by uid 1007); 10 Feb 2016 13:29:29 +0100 Date: Wed, 10 Feb 2016 13:29:29 +0100 From: Gert Doering To: otroan@employees.org Message-ID: <20160210122929.GM58491@Space.Net> References: <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com> <56BB2341.4030002@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m8KeBi+cMtGki44r" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 12:29:57 -0000 --m8KeBi+cMtGki44r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 10, 2016 at 01:27:56PM +0100, otroan@employees.org wrote: > if I would design an IPv6 firewall today I'd drop most fragments. they ar= e nothing but a DOS vector (for middleboxes). > (and I've formed that opinion after actually implementing an RFC7597 BR.) What about DNS and DNSSEC? Or are those the exception to "drop *most*=20 fragments"? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --m8KeBi+cMtGki44r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVrstKd9WwGXkzn/FAQIpOBAAr4PlIpNDIJqZd6mutITAZnthV+khzXGj 6+UlVEUBY/k8cmKmeMhCwwgUKX+B65nyB/jKLgYd6EE+Z4ryjk8wseAPHBxovcba mdE0jfN0xQ/NQqPzVJlJVFPOX5XcN6tQDMLK53FWik7LrKCOwJoJtfs6X47BB2bK BxE+7jA4/lUKslE9qnnIsq8t+3+NPn+NjLT/i8GILDlOOvYkTdu/lJiVJ2NT6Guy T84B4GlL8PSNjtUYyDcBRNy6Qw2zyGSun9X795O66fTkVDq8JkAW5yX5Z+PjQYXZ dOOy0438d21vV1Qy+VTioaC+r2IdeYeYuSrqAz2ZB7dyO5AmH93thYnn4qTJagqa hEfTS1H/ddQPsAqBfd0FYVjVgFCKi63Tav0WQYwmNd4DbfVeWqOka0SidgQt5Iki OMV3h5uMBecaQzDeaKGgLNzFzrs9Shyw0cstAp1O7WaSfgZpmzQK7UDepmIvPIWo HDvxpmDvrkhzWCvcxT6VKbz6W333FH8W+bWOQK+B9vx3bz2y1RIT9kt4M0MFMwod DcneiXMDC3lrsbl3eisDl9+kuefiQvWdJpuwVEmEEzaNu5hKpHTiZkAc0cuNMWJ5 YbqOatcNC+98GuBz/Dkn4vi1Ye0vP3lAFPdG+Bin4rNo0hW5v0ENUT/WwZ6A430x Uj0azgh5yZc= =T9Sd -----END PGP SIGNATURE----- --m8KeBi+cMtGki44r-- From nobody Wed Feb 10 05:01:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638591ACEB8 for ; Wed, 10 Feb 2016 05:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avLuM-X3HSp3 for ; Wed, 10 Feb 2016 05:01:18 -0800 (PST) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8B1ACEBF for ; Wed, 10 Feb 2016 05:01:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 68D3040010; Wed, 10 Feb 2016 14:01:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dNFePVHoB-A; Wed, 10 Feb 2016 14:01:13 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E79434000F; Wed, 10 Feb 2016 14:01:12 +0100 (CET) Message-ID: <56BB3498.6000108@globis.net> Date: Wed, 10 Feb 2016 14:01:12 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith References: <56B9EEBC.7030007@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010906010307020803040209" Archived-At: Cc: v6ops list Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:01:21 -0000 This is a multi-part message in MIME format. --------------010906010307020803040209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Mark Smith > 10 Feb 2016 02:50 > Hi Ray, > > On 10 February 2016 at 00:50, Ray Hunter (v6ops) wrote: >> Mark Smith wrote: >> > > > >> I have read this draft. >> > > Thanks very much for having a read. > >> At first glance it looks like a smart idea, because a defending router only >> has to track perhaps a thousand entries of state versus potentially having >> to store state for billions of "incomplete" queries. >> >> A couple of questions. >> >> 1) How often/when is the MLD cache updated/ timed out? >> > > > MLD operation is not changed, so what ever the MLD protocol timers are. ACK. >> My concern here is that you now have two caches interacting (mulitcast group >> membership and ND cache), and the timing of adding and deleting entries >> could cause race conditions. Some discussion of how the caches interact (or >> not) could be useful IMHO. >> > > Other than using the MLD membership list to determine if to ND NS for > a unknown address, there isn't any interaction between the ND and MLD > caches/memberships lists. > Was there a section which seemed to imply they were interacting more > than the ND process using the information in the MLD membership list? > I'm happy to add a statement that they aren't interacting, just > wondering if there is a specific section/paragraph where you think it > might be best placed? It's more about potential race conditions. If you're using the contents of a cache that refreshes on one timer (and which is potentially unreliable) to perform filtering of actions in another cache that updates on another set of timers, there has to be some sort of interaction. As an example: router boots up. MLD cache is totally empty. The node on the LAN may have already discovered this router as its default router, and routing protocols may have already converged. The filter on inbound connections based on MLD cache should probably not be applied until the MLD cache is populated, and possibly a couple of update cycles completed. Another potential example: Node boots up. MLD is between refreshes and the router does not see a join request. Inbound connection attempt arrives. Router filters the connection attempt. Probably nothing to do here except wait for another connection attempt. Another potential example: Nodes are stressed due to an attack. Or the MLD polling router is stressed. MLD queries or MLD responses either are not sent, or go astray. MLD cache entry Source Timer times out. Node is cut off from external traffic by router filter. Traffic potentially subsides. Cycle repeats. Probably a one-liner could cover the concern. "Care should be taken to check the validity of the MLD cache before applying filtering, to avoid using unreliable MLD cache data, or race conditions." >> 2) Why would a router track multicast membership when potentially it could >> also just track DAD queries directly when nodes join a link? >> > > The limitation of DAD is that DAD is only performed for unicast > addresses, not anycast addresses. I think anycasts are usually going > to be configured to provide a highly available service or host, not > detecting them somehow and therefore dropping ND NSes for them would > be quite a failure! > > DAD is certainly something that could be used to detect normal unicast > addresses, and I think there was a ID about using them for that a few > years ago. You're right, there is also the issue of how at router > starting detects existing nodes/address that have already completed > DAD. I can't remember if I read that ID, however I thought that not > detecting anycast addresses was a fairly significant limitation of > that method. > >> Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and >> Fiber access architectures. Based on the DAD signaling, the first-hop >> router stores in a Binding Table all known IPv6 addresses used on a >> point-to-multipoint domain (e.g., VLAN)." >> >> Couldn't such a cache also be used as a mechanism for defending against >> off-link NS exhaustion attacks? >> >> Obviously if the router joins the link after some nodes are already on link, >> then there's a potential for nodes to have already completed DAD before the >> router boots, so maybe a poll mechanism triggered by monitoring on-link ND >> requests might be appropriate. But then again, if the nodes send any >> off-link traffic via this router at all, they'll trigger ND to the router >> directly, so it's only a problem for normally silent nodes that receive >> inbound sessions. That could be mitigated by scheduling a simple 'ping' on >> end nodes acting as servers when they add a new router to their default >> router list (with appropriate delays/back off etc.). >> > > Thanks very much, > Mark. > >> -- >> regards, >> RayH > Ray Hunter (v6ops) > 9 Feb 2016 14:50 > > > Mark Smith wrote: > I have read this draft. > > At first glance it looks like a smart idea, because a defending router > only has to track perhaps a thousand entries of state versus > potentially having to store state for billions of "incomplete" queries. > > A couple of questions. > > 1) How often/when is the MLD cache updated/ timed out? > > My concern here is that you now have two caches interacting (mulitcast > group membership and ND cache), and the timing of adding and deleting > entries could cause race conditions. Some discussion of how the caches > interact (or not) could be useful IMHO. > > 2) Why would a router track multicast membership when potentially it > could also just track DAD queries directly when nodes join a link? > > Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line > (DSL) and Fiber access architectures. Based on the DAD signaling, the > first-hop router stores in a Binding Table all known IPv6 addresses > used on a point-to-multipoint domain (e.g., VLAN)." > > Couldn't such a cache also be used as a mechanism for defending > against off-link NS exhaustion attacks? -- regards, RayH --------------010906010307020803040209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

10 Feb 2016 02:50
Hi Ray,

On 10 February 2016 at 00:50, Ray Hunter (v6ops) <v6ops@globis.net> wrote:

Mark Smith wrote:



<snip>


I have read this draft.



Thanks very much for having a read.


At first glance it looks like a smart idea, because a defending router only
has to track perhaps a thousand entries of state versus potentially having
to store state for billions of "incomplete" queries.

A couple of questions.

1) How often/when is the MLD cache updated/ timed out?




MLD operation is not changed, so what ever the MLD protocol timers are.
ACK.


My concern here is that you now have two caches interacting (mulitcast group
membership and ND cache), and the timing of adding and deleting entries
could cause race conditions. Some discussion of how the caches interact (or
not) could be useful IMHO.



Other than using the MLD membership list to determine if to ND NS for
a unknown address, there isn't any interaction between the ND and MLD
caches/memberships lists.






  

    
Was there a section which seemed to imply they were interacting more
than the ND process using the information in the MLD membership list?
I'm happy to add a statement that they aren't interacting, just
wondering if there is a specific section/paragraph where you think it
might be best placed?


  



It's more about potential race conditions.



If you're using the contents of a cache that refreshes on one timer (and
 which is potentially unreliable) to 
perform filtering of actions in another cache that updates on another 
set of timers, there has to be some sort of interaction.





As an example: router boots up. MLD cache is totally empty. The node on 
the LAN may
 have already discovered this router as its default router, and routing 
protocols may have already converged. The filter on
 inbound connections based on MLD cache should probably not be applied 
until the MLD cache 
is populated, and possibly a couple of update cycles completed.





Another potential example: Node boots up. MLD is between refreshes and 
the router does not see a join request. Inbound 
connection attempt arrives. Router filters the connection attempt. 
Probably nothing to do here except wait for another connection attempt.



Another potential example: Nodes are stressed due to an attack. Or the 
MLD polling router is stressed. MLD queries or MLD responses either are 
not sent, or go astray. MLD cache entry Source Timer times out. Node is 
cut off from external traffic by router filter. Traffic potentially 
subsides. Cycle repeats.



 Probably a one-liner could cover the concern.



"Care should be taken to check the validity of the MLD cache before 
applying filtering, to avoid  using unreliable MLD cache data, or race 
conditions."





  

    


2) Why would a router track multicast membership when potentially it could
also just track DAD queries directly when nodes join a link?



The limitation of DAD is that DAD is only performed for unicast
addresses, not anycast addresses. I think anycasts are usually going
to be configured to provide a highly available service or host, not
detecting them somehow and therefore dropping ND NSes for them would
be quite a failure!

DAD is certainly something that could be used to detect normal unicast
addresses, and I think there was a ID about using them for that a few
years ago. You're right, there is also the issue of how at router
starting detects existing nodes/address that have already completed
DAD. I can't remember if I read that ID, however I thought that not
detecting anycast addresses was a fairly significant limitation of
that method.


Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and
Fiber access architectures.  Based on the DAD signaling, the first-hop
router stores in a Binding Table all known IPv6 addresses used on a
point-to-multipoint domain (e.g., VLAN)."

Couldn't such a cache also be used as a mechanism for defending against
off-link NS exhaustion attacks?

Obviously if the router joins the link after some nodes are already on link,
then there's a potential for nodes to have already completed DAD before the
router boots, so maybe a poll mechanism triggered by monitoring on-link ND
requests might be appropriate. But then again, if the nodes send any
off-link traffic via this router at all, they'll trigger ND to the router
directly, so it's only a problem for normally silent nodes that receive
inbound sessions. That could be mitigated by scheduling a simple 'ping' on
end nodes acting as servers when they add a new router to their default
router list (with appropriate delays/back off etc.).



Thanks very much,
Mark.


--
regards,
RayH


  
      
     9 Feb
 2016 14:50
    

  






Mark Smith wrote:


I have read this draft.



At first glance it looks like a smart idea, because a defending router 
only has to track perhaps a thousand entries of state versus potentially
 having to store state for billions of "incomplete" queries.



A couple of questions.



1) How often/when is the MLD cache updated/ timed out?



My concern here is that you now have two caches interacting (mulitcast 
group membership and ND cache), and the timing of adding and deleting 
entries could cause race conditions. Some discussion of how the caches 
interact (or not) could be useful IMHO.



2) Why would a router track multicast membership when potentially it 
could also just track DAD queries directly when nodes join a link?



Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) 
and Fiber access architectures.  Based on the DAD signaling, the 
first-hop router stores in a Binding Table all known IPv6 addresses used
 on a point-to-multipoint domain (e.g., VLAN)."  



Couldn't such a cache also be used as a mechanism for defending against 
off-link NS exhaustion attacks?


  






-- 


regards,

RayH

  





--------------010906010307020803040209--


From nobody Wed Feb 10 05:13:14 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14D1ACEF2 for ; Wed, 10 Feb 2016 05:13:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2rv1QrFSrl3 for ; Wed, 10 Feb 2016 05:13:10 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1451AD05B for ; Wed, 10 Feb 2016 05:13:10 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3F3CED7883; Wed, 10 Feb 2016 05:13:10 -0800 (PST)
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=NbtoPAhvrxwhr/xK8bfSJxlcod8=; b= iTHSDGzA2guVX2wxclz0W1Z/BNZsF/2nx8EvX+OxY5uCk2JMIWEIfckhpdSyxbNx tNFdCZKC7OswlbrFQ8b7AoAG7Y8EzxkEUTE5oHtMXzfw7+AEfEJ9LVmLjBXkRQ+u te3PMcjpPrtT8zFpg0/l5/iZ753SpWyY8lc1Iuek5jo=
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=SdxC8k4GPDo2xzkt6Ps0rWyxC2 NI/TUn5Us5buanVY5jFwi2aeeGNsqZ/48coi3OGkLPUhYoKWfNhiGu06qmDclFoa AdqGP4GaL9Fn+FFXLnCeUOByQ2kzyqlAKLrxLreL1hBsovfYjCU/+v7+L5Lb92KV nKCLE5IRvA2hgmIFA=
Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 047A3D7881; Wed, 10 Feb 2016 05:13:10 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D368210B90D3; Wed, 10 Feb 2016 14:13:07 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D41883B1-1677-4E28-AECC-C1E4ECA4D25B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <20160210122929.GM58491@Space.Net>
Date: Wed, 10 Feb 2016 14:13:06 +0100
Message-Id: <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: Fernando Gont , v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 13:13:12 -0000

--Apple-Mail=_D41883B1-1677-4E28-AECC-C1E4ECA4D25B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> if I would design an IPv6 firewall today I'd drop most fragments. =
they are nothing but a DOS vector (for middleboxes).
>> (and I've formed that opinion after actually implementing an RFC7597 =
BR.)
>=20
> What about DNS and DNSSEC?  Or are those the exception to "drop *most*
> fragments"?

those would have to fallback to TCP. the exception would be more like =
in-sequence, back to back fragments with a maximum fragment chain of 2.

this is quickly turning into the "deprecate fragmentation at the network =
layer thread".
to alleviate all fears, I'm _not_ designing an IPv6 firewall. ;-)

Cheers,
Ole

--Apple-Mail=_D41883B1-1677-4E28-AECC-C1E4ECA4D25B
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

iQIcBAEBCgAGBQJWuzdjAAoJEL7aWKiYQt92RiIQAIAVKwI4fughuUBuUWnnjfLb
38eZTtn8cJd4/uYQlBaaIjRMU61hTXiKev6LEAn+nu1oYwEFw/XADX4lbue+9Jsx
y9CXuAoGkTUn8h0+NxgvLAmHocqOtgFvmLFt+WGU9uDrN9lJgc91i3lrcOQjCp4w
OHghCv9dEhA+MM69hem253o/QtOr1iWcWplUxELMz2WIe4yeUFvEC81lbY9uKDY/
mIrfa9wdB4gtqHBRHB6FIQjkT+he4l0MQpfxKJ42YKK83RiOHejQfStQmvRWeTDP
o2kwzdHJVEsWmMD6IdZrtlcLgxghwsYobuXLGOeyeWhE/yMF+0DEefGd4+2k0N4P
kzD2C21KLLJo4nVEwOLpJdOArcHP2zNv6yJxfokWvX1sKICThoQRV+79L+m6fihU
jOJMYPWatDY82BNL1aep/wJb7vLHMUpg8p7mEqEAqPABuks//ftuZ1UTPjxnA2Z+
nk3zxHU21FLTrH2czVUhnWzW+R1aoV6ZEOZ/y+dsBeHCw65nOXoeLom3KrJs1lgb
iIthK+WFhT1DyeVUffqn8zqb3Iwp+n3EcQtyMXbBbcDrkHBRNaHzjgxIyog0mnQz
v8Bv3YhBrAf18HX2P57E7SdplDygZoW5xRRhBH7kRtPyM9eLSxzocMwYFBtjWvIL
D9UYqA+h5SKol9pBW/eQ
=RFbf
-----END PGP SIGNATURE-----

--Apple-Mail=_D41883B1-1677-4E28-AECC-C1E4ECA4D25B--


From nobody Wed Feb 10 05:16:34 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8F11B29F2 for ; Wed, 10 Feb 2016 05:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKCpNxJqlTMp for ; Wed, 10 Feb 2016 05:16:31 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 B6E801AD09B for ; Wed, 10 Feb 2016 05:16:31 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 17D5162B08 for ; Wed, 10 Feb 2016 14:16:30 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C3C24600D4 for ; Wed, 10 Feb 2016 14:16:29 +0100 (CET)
Received: (qmail 97465 invoked by uid 1007); 10 Feb 2016 14:16:29 +0100
Date: Wed, 10 Feb 2016 14:16:29 +0100
From: Gert Doering 
To: otroan@employees.org
Message-ID: <20160210131629.GQ58491@Space.Net>
References: <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gahtajm2T5oVBJmh"
Content-Disposition: inline
In-Reply-To: <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: Fernando Gont , v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 13:16:33 -0000

--gahtajm2T5oVBJmh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Feb 10, 2016 at 02:13:06PM +0100, otroan@employees.org wrote:
> >> if I would design an IPv6 firewall today I'd drop most fragments. they=
 are nothing but a DOS vector (for middleboxes).
> >> (and I've formed that opinion after actually implementing an RFC7597 B=
R.)
> >=20
> > What about DNS and DNSSEC?  Or are those the exception to "drop *most*
> > fragments"?
>=20
> those would have to fallback to TCP. the exception would be more like in-=
sequence, back to back fragments with a maximum fragment chain of 2.

I see.  Which would be fine for the generic DNS+DNSSEC case...

> this is quickly turning into the "deprecate fragmentation at the network =
layer thread".
> to alleviate all fears, I'm _not_ designing an IPv6 firewall. ;-)

I didn't want to turn it into the generic all-encompassing fragmentation
thread :-) - just understand what the exception would be.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--gahtajm2T5oVBJmh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVrs4Ld9WwGXkzn/FAQKSNhAArcFumzykCbtyK1FlkDUjcDAfOAu+ha/O
cD7lml+mkOVHfuSMGGnIuZa4m9y52WI5GJ90NN5we/T/DsfOmnzFovJCMzuvVoL4
h65liJgHjGdnk9muM0dMbkkBs9oKp/VzHxQNcXsCdghV86y8Q9/r7RsjjXVS1SVA
8I3+v+i5/fBUF9g1eQHeJCDXj80fPYGXKzZcuqqFVM/NDq5KLirOGhy9NbiFNI0v
QmHSBlebfDIxpxXoaHp/ZIAqESQnd60dy9UF936b2tEAwTjD3btKnZFhTcbKay/c
fKwIOxBqJbU8xgSrL9wdABegz9CaVz0Jb4ULILKo60ro0d531Cwia/KOt2f0InQu
p7SoowlyL+/hQNCg0+nXvlk195Ex7Jb2zpZRWpPuVFxqc2lsKS+Vx1x+RQSyjREB
FWYX+LplE2QyIKgjh8kkAJyRwHHxxECCXm6v4bATz0Tk6Q3jgstWGGnOTmVS8sjs
cP48o0QTKlKPtu2SZdQraw5tNgv8dBQDzfx3ekKME05Hl9qIPRaOOjEDAKNmzZ97
HdZkMN1XWJQOfZc9snvMkdMwL8DbWlkUxfi2XFtPMNcE0DHCrRbDmWsSdXvRtuf5
6YNPUlnwXT/acD5hM2oO0Oam4Hrl1M95glp2v9ZAg8MXTSUD+LZhkwCM0FdjgNoL
RbIAA2Cvnns=
=syYu
-----END PGP SIGNATURE-----

--gahtajm2T5oVBJmh--


From nobody Wed Feb 10 05:50:08 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135EF1A8A9B for ; Wed, 10 Feb 2016 05:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC_fddLQ9UHN for ; Wed, 10 Feb 2016 05:50:05 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 6B36E1A886F for ; Wed, 10 Feb 2016 05:50:05 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id g62so27543272wme.0 for ; Wed, 10 Feb 2016 05:50:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ki1MG6NaFX/WEbpJs1L0k5K0W3IFfWi/npy8c1Yc0Y=; b=P6Y2cDUw6PpBEBK4ZmYEYSTt7JsNRkXzitKJbq32Qn1cIG9B/KqC1GAw0defUmfFpg eyLl9l5OLZTuufU5LrYnTj64pez1D7P0RwZLpAj5MXXZ4uc6Pdh+253yQGizP9PtlvzG bnPs6++Gzhu47mSQmue4h0pdC6PczhHJr02I6Kz53W1WjhZWuk13UJjQpDNQJBpDCTuM qqB+cDi0gxO7WxeMN04VzuNS9jdUVsNofPATpSCUyp0bRrPzQemC5TVaiiZStuVFoN3j FznzwW0dPabtyx/7zPusaT/YW8Tp9nOZUPff14LQLukCgD0xXFo6Pj5KuKpspHPk2o/K locQ==
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-type; bh=7ki1MG6NaFX/WEbpJs1L0k5K0W3IFfWi/npy8c1Yc0Y=; b=kJGMrwI2gwC3faC6mMLwO0LfB2WSP+pxSPiGec4kb4rU5/1g4BfHX8pBvUCA8oEEY5 GWNpovQYA+2DjYY/x0gmrW4gYqXBPKGZ18lkE3UP9Z92ld5TAyBbINghIS9F1uyOK5B2 bpIi2L674mnAWcYu5t4xEAxXbNMG7fkCCXVM5Upmen1O+tkemOeyEVYaraXW3RsAW8pB Qx7QUvT5dTHZ0zQ+FVcZ0vxtvlQ/cTXo1a4N8nPOwAS1Cp/qWj4CDBO5ynQJqqLEPHcl Lzt/ec49SubU77ByUs0NkcuKXa6N6Q2TYnIZZCT/x/cJPPGhERic8lPdsAGAwTG3bB0u jQOg==
X-Gm-Message-State: AG10YORTttEGWxEe4GVjUuUc7XoNp6G2ff8d0M1/HayIC4y5FqWBqiWhrWQVrNXtaxE51wQoLbkoWFUU9ZvocA==
MIME-Version: 1.0
X-Received: by 10.28.87.21 with SMTP id l21mr10831015wmb.8.1455112203854; Wed, 10 Feb 2016 05:50:03 -0800 (PST)
Received: by 10.27.179.7 with HTTP; Wed, 10 Feb 2016 05:50:03 -0800 (PST)
In-Reply-To: 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com> 
Date: Wed, 10 Feb 2016 15:50:03 +0200
Message-ID: 
From: Saku Ytti 
To: Philip Homburg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Fernando Gont , v6ops list 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 13:50:08 -0000

On 10 February 2016 at 13:29, Philip Homburg  wrote:

Hey,

> There is a very common pattern of a fragmentation header in front of a UDP
> header, which just needs to be supported on todays internet.

I did quick test in NLNOG Ring trying to ping6 with 1501B, meaning src
host will fragment it. Interestingly I also saw:

A=>B NOT_OK
A=>C OK
C=>B OK

Implying sometimes packets with fragment headers are not dropped near the edge?

I had some 130k ping results, based on this sample, about 11% failure
rate with 1501B pings.

This further enforces my belief that fragments will gradually stop
working. Vey common 'high touch' service provider router from Vendor1
handles IPv4 fragments already in linecard CPU, while Vendor2 invested
in silicon and does it very fast in HW. However Vendor2 is not winning
the market, so I can't imagine them supporting IPv4 fragments in HW in
next-gen, why bother? Market does not want it.

-- 
  ++ytti


From nobody Wed Feb 10 06:09:37 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039291B2B0E for ; Wed, 10 Feb 2016 06:09:36 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3Vb7jIlvWnX for ; Wed, 10 Feb 2016 06:09:32 -0800 (PST)
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 1FA2D1B2B13 for ; Wed, 10 Feb 2016 06:09:32 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 81B85206AD1; Wed, 10 Feb 2016 15:09:27 +0100 (CET)
To: otroan@employees.org
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56BB35A8.10909@si6networks.com>
Date: Wed, 10 Feb 2016 10:05:44 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 14:09:36 -0000

On 02/10/2016 09:21 AM, otroan@employees.org wrote:
>>>
>>> right, it isn't clear that is solving the problem. if walking the
>>> chain is done by a middlebox for the purpose of "security", then it
>>> would be highly unlikely that it would allow an unknown extension
>>> header.
>>
>> That's the point: you cannot tell if what's inside is an EH or an
>> upper-layer protocol.
>>
>> If the device is whitelisting stuff, I'd agree with you on the
>> end-result. OTOH, if the devices means to blacklist stuff, then this may
>> lead to unnecessarily packet drops.
>>
>> And, in any case, a bug is a bug.
>>
>> We're pretending that RFC6564 can be employed to skip past unknown EHs,
>> when it really can't.
> 
> no, we're not. we're saying that skipping past unknown headers is not useful/possible in the general case.

mmm.. can you explain what RFC6564 buys?



>>> for a router doing ECMP we should instead make the flow label
>>> usable.
>>>
>>> what we have done, is to make it very unlikely that new extension
>>> headers will be defined. given that we have the three extensible
>>> containers, RH, DestOpt and HBH. and we might be making parsing the
>>> HBH optional.
>>
>> Then let's say that. Right know, given an unknown Next Header, it's
>> impossible to tel whether it's an EH or an ULP.
>>
>> I don't care if we go forward with what we propose in our rfc6564bis
>> I-D, or we just ban the definition of new EHs. Anything is better than
>> leaving the bug in.
> 
> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-03#section-4.8

This still allows the definition of new EHs.

Either ban new EHs, or do something like rfc6564bis. Otherwise we have a
bug in the spec. (what's the point of requiring the format in Section
4.8 of rfc2460bis?)



>>>> 2) EH chains can be very long. Me, I'd prefer that we get to some
>>>> compromise (e.g., "everyone must support EH chains of at least 256
>>>> bytes to be able to claim they are IPv6-ready"), rather than what
>>>> we have now: we pretend that nodes support the currently unlimited
>>>> EH chain lengths, but in practice it gets hard to pass a 10B chain
>>>> through.
>>>
>>> right, but within the constraints of RFC7112. for routers that number
>>> is and always have been 40. :)
>>
>> 40B?
>>
>> If it's an implementation limit, it'd be great that we all agree that
>> 40B is the least common denominator.
> 
> IPv6 has had that limit for 20 years.

Sorry, I missed your point. So essentially you're agreeing that Ehs do
not work. IN which scenarios should one implement something as an EH,
since we cannot rely on them?


>> Besides, whatever the number, there can be as many instances of HBH as
>> desired.. so even for routers, you still have to support at least
>> up-to-MTU long EH chains.
> 
> we're changing that:
> https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00
> [...]

That's good.

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





From nobody Wed Feb 10 06:09:50 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D91B2B1B for ; Wed, 10 Feb 2016 06:09:43 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easogGU2zFZt for ; Wed, 10 Feb 2016 06:09:39 -0800 (PST)
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 08BC91B2B19 for ; Wed, 10 Feb 2016 06:09:39 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 E2BEE206AD1; Wed, 10 Feb 2016 15:09:35 +0100 (CET)
To: otroan@employees.org, Gert Doering 
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56BB3DD9.2050600@si6networks.com>
Date: Wed, 10 Feb 2016 10:40:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 14:09:43 -0000

On 02/10/2016 10:13 AM, otroan@employees.org wrote:
>>> if I would design an IPv6 firewall today I'd drop most fragments. they are nothing but a DOS vector (for middleboxes).
>>> (and I've formed that opinion after actually implementing an RFC7597 BR.)
>>
>> What about DNS and DNSSEC?  Or are those the exception to "drop *most*
>> fragments"?
> 
> those would have to fallback to TCP.

This will be interesting. General DNS serves actually *relying* on TCP
could be an interesting can of worms DoS-wise.


> the exception would be more like in-sequence, back to back fragments with a maximum fragment chain of 2.
> 
> this is quickly turning into the "deprecate fragmentation at the network layer thread".
> to alleviate all fears, I'm _not_ designing an IPv6 firewall. ;-)

I'll ping Ron Bonica to revive his "deprecate IPv6 fragmentation" I-D
and claim you'll support it. :-)

(just kiddin')

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





From nobody Wed Feb 10 07:20:13 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C251B2BBA for ; Wed, 10 Feb 2016 07:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.101
X-Spam-Level: 
X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiZWgh6BxwYA for ; Wed, 10 Feb 2016 07:20:10 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id C94B01B2BC1 for ; Wed, 10 Feb 2016 07:20:08 -0800 (PST)
Received: from [10.10.3.20] (h2.180.128.40.static.ip.windstream.net [40.128.180.2]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u1AFJ6oX021251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2016 07:19:06 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F5D821C-3570-403F-8D72-05D3EBCA1171"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong 
In-Reply-To: <56BB2A8E.3040004@gmail.com>
Date: Wed, 10 Feb 2016 07:19:08 -0800
Message-Id: <12460C8D-D52C-4241-9697-651A5967FA62@delong.com>
References: <56BB2A8E.3040004@gmail.com>
To: Alexandre Petrescu 
X-Mailer: Apple Mail (2.2104)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 10 Feb 2016 07:19:07 -0800 (PST)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] distributed gaming on IPv6 - any platform?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 15:20:11 -0000

--Apple-Mail=_4F5D821C-3570-403F-8D72-05D3EBCA1171
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Feb 10, 2016, at 4:18 AM, Alexandre Petrescu =
 wrote:
>=20
> Hello,
>=20
> Is there any distributed gaming platform that runs on IPv6 too?

World of Warcraft from Blizzard Entertainment runs on IPv6.

Owen


--Apple-Mail=_4F5D821C-3570-403F-8D72-05D3EBCA1171
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On Feb 10, 2016, at 4:18 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


  

    
  
  

    Hello,

      

      Is there any distributed gaming platform that runs on IPv6 too?

World of Warcraft from Blizzard Entertainment runs on IPv6.

Owen


--Apple-Mail=_4F5D821C-3570-403F-8D72-05D3EBCA1171--


From nobody Wed Feb 10 08:02:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CEE1A9131 for ; Wed, 10 Feb 2016 08:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W9nS3xM_N3u for ; Wed, 10 Feb 2016 08:02:06 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16B21B2C2E for ; Wed, 10 Feb 2016 08:02:01 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 95661D7890; Wed, 10 Feb 2016 08:02:00 -0800 (PST)
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=btWCOE2EjuDusIV5MvMoRuKsQck=; b= JQXFNxD4iwE3KH3i/clXCm8nsU4BWquqMPfguj8OYciyKFPiG4/eavX75xl3F2EN ic5rI0yNf/dI8AmBRBn78d7nwYuzlyljE7VKoXFLkhxDdeb/PEnIGb2R+8kSpAPV mHBoaIoayEUVb37DvylE2TOca9PvGDtxK2v7dfzPg2Y=
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=IJmJM8Vk1KhuKfJZH35FpW8X3+ CW4gF3k6t7M+J/SAPIINbEzbfWT2XIG+jFEVaWIA9m3FljoSBEJFBXG6V7vUAbw7 5YsfjDZUsJqsVncc0gdty4CSalcLzS84bF8qOoEJU0FQ/5SP9hsrW8DhGj9WTE4d 6XUqztl2AjTFSxoIM=
Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (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 6795FD7888; Wed, 10 Feb 2016 08:02:00 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A18FB10BAEFE; Wed, 10 Feb 2016 17:01:59 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_8CC18897-0902-49BC-A11C-FAE7061F1AAD"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56BB35A8.10909@si6networks.com>
Date: Wed, 10 Feb 2016 17:01:58 +0100
Message-Id: 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BB 35A8.10909@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 16:02:07 -0000

--Apple-Mail=_8CC18897-0902-49BC-A11C-FAE7061F1AAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Fernando,

>>> If it's an implementation limit, it'd be great that we all agree =
that
>>> 40B is the least common denominator.
>>=20
>> IPv6 has had that limit for 20 years.
>=20
> Sorry, I missed your point. So essentially you're agreeing that Ehs do
> not work. IN which scenarios should one implement something as an EH,
> since we cannot rely on them?

how did you manage to reach that conclusion?
I'm saying there are very few use cases (ECMP and DDOS) requiring =
parsing further than the IPv6 header in transit networks.
with the caveats mentioned previously I believe EHs work as well as they =
can be made to work.

apart from:
 - encourage the deployment of flow-label
 - "fixing" the HBH header
 - strongly discourage new EHs

I think the IETF has done (more than) enough on this topic for a while.

cheers,
Ole

--Apple-Mail=_8CC18897-0902-49BC-A11C-FAE7061F1AAD
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

iQIcBAEBCgAGBQJWu173AAoJEL7aWKiYQt92B9MQAJz6CDJLz3zypQNOIZihzg5y
7egts701kMcd2iGKfEpTn9wTIoTB3FBSe/ZMTvA/NCk1tXh79oJVsZBCYYlQPIuJ
czvaFC53bZ0lv71tHIzsbZGj/Ia+8aq1n+qFV0Co5BYnO5pMHGh3CCijreOPl5RI
UqApuYoJfcOzkicVxlnEKtPLCPnPSag7FJkaiMby7z5Cy2HTCUI7TS343gdLs58C
tvN0kMmphZOU91RcWjrnKAkWsRqY+Gbib43+Eo7wlhPsQIl8cjwR6iybgrsfrBMp
k/d7wYJovBiwcCbwvNq7O72aJ89nf9hx8Dv8Ci3RZ/s1E/qNl0ozJEEIy6pTti2h
DueORDDe/i0B24IE2nelVFX12b3DQgTwH8+07Ro/ipjMILC6NvjPX1SFp3e78Wgz
OG1JyYOQkOJMG+UgrTyokQhAOn1aCp7I3nf/GzhcPCiDMUBDpiM7ZPvbWxC3+aOU
Ka4Arx83/8i2PEcx2oiQDEbKkfFNVsPpgWhH1Hjyx4nBZDhVvOGA3bhMJdHL+/QU
mPjdOXA+bXLAO3wnLExrYPt3RxpFdnXIbvP9ZVz2a4yD8mUtES23kTaUiYdsgnBt
1N03h2A6U4GbjFMhaoHV0pcoxlI9GYxGMIGgDqoqb5VVENl9NSP1TG+P6XU2kmgL
HU430nJ32aU8O0jR3ukK
=lsvR
-----END PGP SIGNATURE-----

--Apple-Mail=_8CC18897-0902-49BC-A11C-FAE7061F1AAD--


From nobody Wed Feb 10 08:30:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686301B2C6F for ; Wed, 10 Feb 2016 08:30:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSUXnxK6R7-r for ; Wed, 10 Feb 2016 08:30:10 -0800 (PST)
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 7E7E91B2C75 for ; Wed, 10 Feb 2016 08:30:08 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 A5B11206AD1; Wed, 10 Feb 2016 17:30:04 +0100 (CET)
To: draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56BB639E.5010505@si6networks.com>
Date: Wed, 10 Feb 2016 13:21:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 16:30:13 -0000

Folks,

I did a fresh review of the aforementioned I-D. I didn't follow previous
discussions of this topic, so my apologies if I raise something that has
already been discussed to death, etc.


** Technical **

* Meta: Both section 4 and section 6 contain use cases. This is rather
confusing. e.g., not sure what's the criteria to ut some of the use
cases in Section 4, while others in Section 6. Unless I'm missing
something, this should be fixed.


* Section 3.2: Do folks really generate the prefixes as "required"?
Me, I confess I've used things like fc00:1::/64 because they are simpler
that some random string of bits.

* Section 3.4, page 4:
> Externally-destined data can be sent to the Internet or
> telecommunication network by a separate function, through an
> appropriate gateway/firewall.

Please remove "firewall". A firewall wouldn't really help with that.


* Section 4.1, page 4:
> IP is used ubiquitously.  Some networks like industrial control bus 
> (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces 
> like [MIL-STD-1397] have begun to use IP.  In these kinds of 
> networks, the system may lack the ability to communicate with the 
> public networks.

Not sure what you mean by "may lack the ability...".


* Section 4.1, page 5:
> o  Prefix generation: randomly generated according to the algorithms 
> defined in [RFC4193] or manually assigned.  Normally, automatic 
> generation of the prefixes is recommended, following [RFC4193]. If
> there are some specific reasons that call for manual assignment,
> administrators have to plan the prefixes carefully to avoid
> collision.

mm.. what do you mean exactly by "automatic generation"? -- In all those
systems I have employed, the ULA prefixes are not generated
automagically. -- you need to un the algorithm yourself, which means
that the prefix is alwas manually configured (in the routers sending the
RAs).


* Section 4.1, page 5:
> o  Prefix announcement: in some cases, networks might need to 
> announce prefixes to each other.  For example, in vehicle networks 
> with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) 
> communication, prior knowledge of the respective prefixes is 
> unlikely.  Hence, a prefix announcement mechanism is needed to enable
> inter-vehicle communications based on IP.  As one possibility, such
> announcements could rely on extensions to the Router Advertisement
> message of the Neighbor Discovery Protocol (e.g.,
> [I-D.petrescu-autoconf-ra-based-routing] and [I-D.jhlee-mext-mnpp]).

This is not specific to ULAs -- hence I'd remove this para.



* Section 4.2.1, page 7:

> -  If the firewall is located inside the NPTv6 translator, the 
> filtering is then based on the ULA prefixes, and the rules need to be
> updated correspondingly.  There is no need to update when the NPTv6
> GUA prefixes are renumbered.

not sure what you mean by "need to be updated"... the whole point of
ULAs is that you'd not renumber them...


* Section 4.2.2, page 7:
>  Note:
>       ULAs provide more benefit for multiple-segment home networks; for
>       home networks containing only one segment, link-local addresses
>       are better alternatives.

You need to expand and back these claims...


* Section 4.2.2, page 8:
>    o  Default Routing: connectivity may be broken if ULAs are used as
>       default route.  When using RIO (Route Information Option) in
>       [RFC4191], specific routes can be added without a default route,
>       thus avoiding bad user experience due to timeouts on ICMPv6
>       redirects.  This behavior was well documented in [RFC7084] as rule
>       ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
>       router with a Router Lifetime greater than zero whenever all of
>       its configured and delegated prefixes are ULA prefixes." and along
>       with rule L-3 "An IPv6 CE router MUST advertise itself as a router
[...]

If you have a multi-subnet home network, and the CP doesn't advertise
itself as a default router (and nodes don't support RFC4191), how do you
get multi-subnet ULA network to work?


* Section 4.2.2, page 9:
> 
>    o  DNS relevant: if administrators choose not to do reverse DNS
>       delegation inside of their local control of ULA prefixes, a
>       significant amount of information about the ULA population may
>       leak to the outside world.  Because reverse queries will be made
>       and naturally routed to the global reverse tree, so external
>       parties will be exposed to the existence of a population of ULA
>       addresses.  [ULA-IN-WILD] provides more detailed situations on
>       this issue.  Administrators may need a split DNS to separate the
>       queries from internal and external for ULA entries and GUA
>       entries.

This text seems to imply that someone will do reverse mappings for ULAs.
Could you please elaboate a bit on the scenario that you envision?


* Section 6.3.2, pages 11-12:
>    But there is an issue needs to be noted.  The NAT64 standard
>    [RFC6146] specifies that the PREF64 should align with [RFC6052], in
>    which the IPv4-Embedded IPv6 Address format was specified.  If we
>    pick a /48 for NAT64, it happens to be a standard 48/ part of ULA
>    (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID).  Then the
>    40bit of ULA is not violated by being filled with part of the 32bit
>    IPv4 address.  This is important, because the 40bit assures the
>    uniqueness of ULA.  If the prefix is shorter than /48, the 40bit
>    would be violated, and this could cause conformance issues.  But it
>    is considered that the most common use case will be a /96 PREF64, or
>    even /64 will be used.  So it seems this issue is not common in
>    current practice.

(Disclaimer: I haven't read RFC6052 any time lately) The text above is
confusing to me... maybe you could expand and elaborate a bit more?


* Section 6.3.3, page 12:
>    ULAs could be self-generated and easily grabbed from the standard
>    IPv6 stack.  And ULAs don't need to be changed as the GUA prefixes
>    do.  So they are very suitable to be used as identifiers by the up
>    layer applications.  And since ULA is not intended to be globally
>    routed, it is not harmful to the routing system.

Using IP addresses as identifiers in upper layers is a really bad idea.




** Editorial **

* Abstract:

> Based on an analysis of different ULA usage scenarios, this document
> identifies use cases where ULA addresses are helpful as well as
> potential problems caused by using them,

Replace the trailing comma with a dot.

* Page 2, intro:
> Unique Local Addresses (ULA) is defined in [RFC4193], and it is an 
> alternative to site-local address (deprecated in [RFC3879]).

"..are defined in... and they are...."

* Section 1, Page 3:
> Thus, the administrators could choose to use ULAs in a certain way
> that considered benificial for them.

"..that is considered..."


* Section 4.2.1, page 6:
> The comunity has strong controversies of ULA-only deployment in 
> connected networks.

s/controversies/concerns/



* Section 4.2.1, page 6:
> For those who are strongly against this usage, the main reason is to
> avoid breaking the end-to-end transparence.  Because people have
> suffered from the NAT/Proxy middle boxes so much in the IPv4 ear

s/ear/era/


Thanks!

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





From nobody Wed Feb 10 08:49:04 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED891B2CA2 for ; Wed, 10 Feb 2016 08:49:03 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zcc_dU425Kxx for ; Wed, 10 Feb 2016 08:49:01 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746801B2CA5 for ; Wed, 10 Feb 2016 08:49:01 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u1AGms2a079733 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2016 16:48:55 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local
Message-ID: <56BB69F5.4060901@foobar.org>
Date: Wed, 10 Feb 2016 16:48:53 +0000
From: Nick Hilliard 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: otroan@employees.org
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BB 35A8.10909@si6networks.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Fernando Gont , v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 16:49:03 -0000

otroan@employees.org wrote:
> I'm saying there are very few use cases (ECMP and DDOS) requiring 
> parsing further than the IPv6 header in transit networks. with the 
> caveats mentioned previously I believe EHs work as well as they can 
> be made to work.

transit networks need to be able to provide anti-ddos protection.  At
the moment this is normally handled on the provider side using
customer-signaled RTBH, but in future this will need to be either
provider- or customer-signalled using flowspec. Also, all routers need
control plane protection / RE firewalling.

> I think the IETF has done (more than) enough on this topic for a 
> while.

draft-gont-v6ops-ipv6-ehs-in-real-world shows that EHs are fundamentally
unusable on the wider Internet today.  Declaring that the IETF has done
more than enough is giving up completely, and that will effectively
write off EHs as a viable technology in the long term.  I don't think
the IETF should give up, at least not at this stage.  If it does, it
should have good reasons for doing so.

Nick


From nobody Wed Feb 10 10:22:57 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE391B2E91 for ; Wed, 10 Feb 2016 10:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLlW49ZaVYZK for ; Wed, 10 Feb 2016 10:22:50 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4293C1B2E9C for ; Wed, 10 Feb 2016 10:22:49 -0800 (PST)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u1AILmrg020146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2016 10:21:49 -0800 (PST)
To: Fernando Gont , otroan@employees.org, Gert Doering 
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org> <56BB3DD9.2050600@si6networks.com>
From: Joe Touch 
Message-ID: <56BB7FBC.4010908@isi.edu>
Date: Wed, 10 Feb 2016 10:21:48 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BB3DD9.2050600@si6networks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 18:22:54 -0000

On 2/10/2016 5:40 AM, Fernando Gont wrote:
>>> >> What about DNS and DNSSEC?  Or are those the exception to "drop *most*
>>> >> fragments"?
>> > 
>> > those would have to fallback to TCP.
> This will be interesting. General DNS serves actually *relying* on TCP
> could be an interesting can of worms DoS-wise.

https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01


From nobody Wed Feb 10 11:24:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAD1B2EF5 for ; Wed, 10 Feb 2016 11:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpy3aVex1lx7 for ; Wed, 10 Feb 2016 11:24:09 -0800 (PST)
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 3E22B1B2EF4 for ; Wed, 10 Feb 2016 11:24:09 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id f81so31989695iof.0 for ; Wed, 10 Feb 2016 11:24:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=P/Bt3gByj34BAU+J6nH+SbMbkspjy/EyfGzOFVLvnCo=; b=x9Xz8fdF+tZ+TgUR68vVMqzDPcnYO2+WQMHkv7M64a1NONm944RML444pNvR35qDtk YrH46gv8oHSnLASXhM2WQLh+EYzGblfjakVDG6+aw8G1Rn7oIIcK0ilHl920nd6gyTJK R697P9Puc1R3zIa4kscSCzAh/ZtLEjkUsyF2U+i2C+13npcUZIS8k6XsyUxmeFFkGp+Q JFltikOZTEQ2U3VZGh9Vxtvhy37b1CEWKynbIoRvCEgJL7BZqCneQlp76kgsoPie+RIA Ju6NZRH5+y7AHg56dlEGchxQfi6EpAz7Co3+WaoHaPbGiDgSmT+ONzLIpUMHS4HELA80 uFhA==
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:content-type; bh=P/Bt3gByj34BAU+J6nH+SbMbkspjy/EyfGzOFVLvnCo=; b=UazimIY3l29GUvbiIHxDFtsGVccP+PtkS+ap5k/ATW1jtso5g4qW1QtHYlLmUCOK6G gf4IRuzTMPc7+9og0U9/MBOiWviE2PBc4nIAHQ8AqNcB6YPUqJACfZWPhwA+Pn7z5IZX x1MkFJ0UU+3vy5nHxb4TODT/tzeXv2YI/0+WlppE6ffxZp3mudTRhzKF4LAK2cFW1PH6 Xa1+JFokMi+OfkusRqviXjQfuY/7KaS55PDAASZz11v7IvWasxO4jlC0DUkz3L2HcRWc oO9oo4JVp14VsNyDXRnjRnITWH+6QnXHAdaYtl3wL7LEA7DSG/zDNfBcauaqu70Dg8R+ X9/w==
X-Gm-Message-State: AG10YOT0Slom7wmPFEitZILV77oqKZubuZgCYEx8re7gvuVwkBe8ADXtF66SyP/YkHBZlJkdb3ayjxmgJFFayw==
MIME-Version: 1.0
X-Received: by 10.107.184.135 with SMTP id i129mr36434492iof.4.1455132248650;  Wed, 10 Feb 2016 11:24:08 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Wed, 10 Feb 2016 11:24:08 -0800 (PST)
In-Reply-To: <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>
Date: Wed, 10 Feb 2016 11:24:08 -0800
X-Google-Sender-Auth: Tg7mbAkdP-_5CCdqCNHKezcaOkg
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Ole Troan 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Fernando Gont , "v6ops@ietf.org" 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 19:24:10 -0000

At Wed, 10 Feb 2016 14:13:06 +0100,
otroan@employees.org wrote:

> >> if I would design an IPv6 firewall today I'd drop most fragments. they are nothing but a DOS vector (for middleboxes).
> >> (and I've formed that opinion after actually implementing an RFC7597 BR.)
> >
> > What about DNS and DNSSEC?  Or are those the exception to "drop *most*
> > fragments"?
>
> those would have to fallback to TCP.

I may misunderstand it, but DNS clients (resolvers) are not supposed
to fall back to UDP simply because its UDP query times out (because
the fragmented response is dropped in this scenario).

> the exception would be more
> like in-sequence, back to back fragments with a maximum fragment
> chain of 2.

One common practice of the DNS server is to fragment UDP responses at
the minimum MTU, and a large response with DNSSEC signatures could be
larger than several thousands of bytes, a max chain of 2 is probably
not enough (although 3 or 4 is probably okay in practice).  If you
meant the server should just truncate responses larger than that to
trigger immediate fall back to TCP by "would have to fallback to TCP"
above, then I see that.

--
JINMEI, Tatuya


From nobody Wed Feb 10 12:34:19 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74471B2F93 for ; Wed, 10 Feb 2016 12:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53Wi0CRow3rn for ; Wed, 10 Feb 2016 12:34:16 -0800 (PST)
Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123211B2F94 for ; Wed, 10 Feb 2016 12:34:16 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0O2C00F00M1TAF00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 10 Feb 2016 14:34:14 -0600 (CST)
X-Spam-PmxInfo: Server=avs-3, Version=6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.10.202416, SenderIP=0.0.0.0
Received: from DOIT-2NW1MRFY-X.doit.wisc.edu (brie.doit.wisc.edu [144.92.67.198]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0O2C00EHDMGZMT00@smtpauth3.wiscmail.wisc.edu>; Wed, 10 Feb 2016 14:34:13 -0600 (CST)
Date: Wed, 10 Feb 2016 14:34:11 -0600
From: "Dale W. Carder" 
To: Fernando Gont 
Message-id: <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu>
References: <56BB639E.5010505@si6networks.com>
In-reply-to: <56BB639E.5010505@si6networks.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: IPv6 Operations , draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 20:34:17 -0000

Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
> 
> * Section 3.2: Do folks really generate the prefixes as "required"?
> Me, I confess I've used things like fc00:1::/64 because they are simpler
> that some random string of bits.

I absolutely do not believe it can be expected that sites will generate 
random prefixes.   This will result in more NAT and all of the horror
stories from rfc1918 getting copied over.  For a while someone (SixXS?)
was running a ULA registry, but I am not sure what came of it.

In 5.1, the last paragraph states "Another important difference is the 
ability to merge two ULA networks without renumbering (because of the 
uniqueness), which is a big advantage over [RFC1918]."  So, should 
section 5.1 emphasize the importance of this uniqueness, or could 
this fit better somewhere else?

> * Section 4.2.2, page 9:
> > 
> >    o  DNS relevant: if administrators choose not to do reverse DNS
> >       delegation inside of their local control of ULA prefixes, a
> >       significant amount of information about the ULA population may
> >       leak to the outside world.  Because reverse queries will be made
> >       and naturally routed to the global reverse tree, so external
> >       parties will be exposed to the existence of a population of ULA
> >       addresses.  [ULA-IN-WILD] provides more detailed situations on
> >       this issue.  Administrators may need a split DNS to separate the
> >       queries from internal and external for ULA entries and GUA
> >       entries.
> 
> This text seems to imply that someone will do reverse mappings for ULAs.
> Could you please elaboate a bit on the scenario that you envision?

I thought rfc4193 section 4.4 covered DNS adequately, but I think the
claim here is that the recommendations won't be followed (notice a
theme?).  If a site doesn't (or can't) follow them, the recommendation
is to at least run with split dns views to mitigate.

Dale


From nobody Wed Feb 10 13:09:03 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCC1B2FF6 for ; Wed, 10 Feb 2016 13:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level: 
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3F5qynRdQtw for ; Wed, 10 Feb 2016 13:08:58 -0800 (PST)
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 6805E1B2FF5 for ; Wed, 10 Feb 2016 13:08:58 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 B0F7F206B80; Wed, 10 Feb 2016 22:08:54 +0100 (CET)
From: Fernando Gont 
To: otroan@employees.org
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BB 35A8.10909@si6networks.com> 
Message-ID: <56BB6FE9.2030409@si6networks.com>
Date: Wed, 10 Feb 2016 14:14:17 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Feb 2016 21:08:59 -0000

On 02/10/2016 01:01 PM, otroan@employees.org wrote:
> Fernando,
> 
>>>> If it's an implementation limit, it'd be great that we all agree that
>>>> 40B is the least common denominator.
>>>
>>> IPv6 has had that limit for 20 years.
>>
>> Sorry, I missed your point. So essentially you're agreeing that Ehs do
>> not work. IN which scenarios should one implement something as an EH,
>> since we cannot rely on them?
> 
> how did you manage to reach that conclusion?

What I understood from your note is that you can only rely on 40B-header
packets. Anything longer than that is uncertain. Did I misinterpret you?

Clearly, there's widespread dropping of packets, and the longer the EH
chain, the worse.

If we cannot agree on at least some minimum EH length that is widely
supported, then it becomes "no EHs, or be prepared for packet drops".


> I'm saying there are very few use cases (ECMP and DDOS) requiring parsing further than the IPv6 header in transit networks.
> with the caveats mentioned previously I believe EHs work as well as they can be made to work.

Folks seem to be needing to filter packets, which means processing the
EH chain for reasons other than ECMP. Widespread support would fix the
drops related to ECMP, but not the ones related to the need to filter
based on layer-4 info.



> apart from:
>  - encourage the deployment of flow-label
>  - "fixing" the HBH header
>  - strongly discourage new EHs

If asked I'd also ban: multiple instances of the same EH, ban some
pathological cases such as tow back-to-back FHs, and also establish a
least common denominator of an EH-Chain length that is supposed to work
everywhere.


> I think the IETF has done (more than) enough on this topic for a while.

FWIW, my metric of "enough" is when you get stuff to work -- we're far
from there yet.

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 Feb 10 16:33:31 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CD1A8715 for ; Wed, 10 Feb 2016 16:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tDDyxtVlMWV for ; Wed, 10 Feb 2016 16:33:27 -0800 (PST)
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 5AB371A7012 for ; Wed, 10 Feb 2016 16:33:27 -0800 (PST)
Received: by mail-pa0-x229.google.com with SMTP id ho8so20022685pac.2 for ; Wed, 10 Feb 2016 16:33:27 -0800 (PST)
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-type :content-transfer-encoding; bh=+xA0dWsQdll4gDEt6nD1r2gZMesEKdoUkEd3xlhFEKI=; b=j0LMF0lf4YYGixnjiW1iDnlwITWCy6JN+O7705o+4qESjnqieS20CtHVL+FCKRBx22 pfLoaewCjTxVNpmr1BKczMmNSc4ebg5AhkEOcND+nZC7PbuG0dDQGodBkiZoUhFzy6WF spkvixP5BF5mjrw2+47Rg9Ww7u9KuZRpGGr5Aqwp7extMF0fL9lUIMFaBG6QjpFINvxo 2jBM8uDySqJz9vJzqoAwidtoMGEd8jVOswU9X3MK4vfjQEoSpK2AjVuk6qXGiF/AFQp2 g45t7ftVDvQM28om6uttnHCLa5T04kv4hz4QChUhJvcZ9/XUKlUfNjVzOEVgCjDuu7A9 QlSQ==
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-type :content-transfer-encoding; bh=+xA0dWsQdll4gDEt6nD1r2gZMesEKdoUkEd3xlhFEKI=; b=aVMTSfcHHKrxgg0NOD3SG1jsW9pXs1C6N+rpHI3K+f4EwxsKiBVumIvCR3gFLcgwup 6haVo9PEUPQlPFOKPaPn0Gtjtj7OdurpCqv/AGz8SzPYzpx32ENdjI0R4+63J9vB26bU SobC59Knyi8KRo/8HoDhpQbjAIn/nQlsYYDOs2/O0ZCRGC/GitOP5zWp4aYXoD7SxsPp IwsaOCDlgcUzzZgOYCGQ0T1xibw06O3TEcj6s33JwJ506ggwSKa/Y1LZ+cvlbTwNKOwe RuXS6qzZ55ywkibAVdaTTpcoKS42Dlx5eiTTYcoPUryXIE3zoNRYIKdxoh8R2culoRZE 7Krw==
X-Gm-Message-State: AG10YOQaWS7RVJCuzHKvHG8Mds+7T6e4UhDS5eJnS7N6E2upk9yfMVFA8NhtDrmHuiparg==
X-Received: by 10.66.100.228 with SMTP id fb4mr61879368pab.84.1455150807057; Wed, 10 Feb 2016 16:33:27 -0800 (PST)
Received: from ?IPv6:2406:e007:60f8:1:28cc:dc4c:9703:6781? ([2406:e007:60f8:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v29sm7742021pfa.31.2016.02.10.16.33.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 16:33:25 -0800 (PST)
To: "Dale W. Carder" 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BBD6DB.6020507@gmail.com>
Date: Thu, 11 Feb 2016 13:33:31 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 00:33:29 -0000

On 11/02/2016 09:34, Dale W. Carder wrote:
> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
>>
>> * Section 3.2: Do folks really generate the prefixes as "required"?
>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>> that some random string of bits.
> 
> I absolutely do not believe it can be expected that sites will generate 
> random prefixes.

Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
be messing around with these things.

> This will result in more NAT

No. ULA is for internal traffic only. You use your ISP-provided prefix for
the Internet.

> and all of the horror
> stories from rfc1918 getting copied over.  For a while someone (SixXS?)
> was running a ULA registry, but I am not sure what came of it.
> 

It's still there for people who believe it matters. I've never seen the
point, myself.
https://www.sixxs.net/tools/grh/ula/

   Brian


From nobody Wed Feb 10 17:21:53 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C191A87A3 for ; Wed, 10 Feb 2016 17:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAPvLeQGXES6 for ; Wed, 10 Feb 2016 17:21:49 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 574081A877A for ; Wed, 10 Feb 2016 17:21:49 -0800 (PST)
Received: by mail-pa0-x235.google.com with SMTP id ho8so20589391pac.2 for ; Wed, 10 Feb 2016 17:21:49 -0800 (PST)
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-type:content-transfer-encoding; bh=kxme2HlthgqmtV1Rg0hw45v/8ENjpHwduKv1PPr/Mcg=; b=xOBKUwPrwIruV8JwAdZFf1IpBg6ka/fjAQk506dUsuOh5Q4SWbjscm4Yoben6M4OjF k1wz8oeffFYi0NvSfWJL65c5fGffAwY7DR38Z6XyrXH7NPLagETsXdnEyhzXKVjPahRa 13amrh1RrKMunt9hCGfSRzKv7ybIomaHSikVJM7QGG099lPB64AT2gjPZwvGWhAfYJBA cFSjkfwl0oemXCzvbfxjUlESU95KDOf1iaUnyClAHsw6DnAqlsZsBX/zzCloKmYjd8gx hTcWXeUHkI9qLDZ5uFgw1ZYXwBfKFL9xljnXOVuc7B0RoPdJWGLzUF/xkRKqWpPqddFv sANw==
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-type :content-transfer-encoding; bh=kxme2HlthgqmtV1Rg0hw45v/8ENjpHwduKv1PPr/Mcg=; b=beSccN6b05OBYj92cKRARW92g2oK9VPBzdaMjlkayCF5m+qGn0ld/x2W8wsw1l+MPi MKp3gX5325GJIJhvuq6AQUi7ttdrRmUBZ37a/c7GjeunXaH6Jq8jhFtV3k5dFT1vyJaT o3iG/Sea8bwEpDWLRSSBUF17BGM/tGX7YvQHGEfCywF3vk5m9z4Hh+51DirXfSItqE0y qrKbZFq5w8F50RDQ6ykmoFo12roQEkAYrHE/uWSFtA8U+N/2wSPHnMI3d91RtL2/uhfQ 6/KMd5AozAaXGTVGv/eCD1SSJlkqsKDLNwSsAW+MSzZPj3NgrDlfVjW5Iajvn/pDYrWQ ISoQ==
X-Gm-Message-State: AG10YOSHdt5kU5flIt0TdFOIWvdp2Iem65dW6pyWAzUHoF8xMGq6L4RVhLWKEnXJaT9C0A==
X-Received: by 10.66.55.6 with SMTP id n6mr62535975pap.33.1455153709062; Wed, 10 Feb 2016 17:21:49 -0800 (PST)
Received: from ?IPv6:2406:e007:60f8:1:45ae:f971:31c3:8836? ([2406:e007:60f8:1:45ae:f971:31c3:8836]) by smtp.gmail.com with ESMTPSA id z5sm7849251pas.29.2016.02.10.17.21.46 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 17:21:47 -0800 (PST)
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org>
To: v6ops@ietf.org
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BBE231.9030706@gmail.com>
Date: Thu, 11 Feb 2016 14:21:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 01:21:51 -0000

Somebody said:

>> and we might be making parsing the HBH optional.

We already did that, in RFC 7045 section 2.2.

>> It shouldn't be that hard to support a white list of unknown extension
>> headers that can be set by the operator. 

We pretty much require that in RFC 7045 section 2.1:

  "...the discard policy for each standard type of extension
   header MUST be individually configurable.  The default configuration
   SHOULD allow all standard extension headers.

   Experimental IPv6 extension headers SHOULD be treated in the same way
   as standard extension headers, including an individually configurable
   discard policy.  However, the default configuration MAY drop
   experimental extension headers.

   Forwarding nodes MUST be configurable to allow packets containing
   unrecognised extension headers, but the default configuration MAY
   drop such packets."

>> Folks seem to be needing to filter packets, which means processing the
>> EH chain for reasons other than ECMP. Widespread support would fix the
>> drops related to ECMP, but not the ones related to the need to filter
>> based on layer-4 info.

Right. Boxes that insist on parsing the header chain but do not understand
all header types are doomed to fail. There is no solution to that except
scrapping those boxes. RFC 6564, 7045, 7112 and draft-ietf-6man-hbh-header-handling
are mitigations, but broken middleboxes are broken.

I tend to agree with Ole that on the standards front there isn't much
more we can do. Operators can require their suppliers to support the above
mitigations, hopefully.

    Brian




From nobody Wed Feb 10 18:38:30 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08FD1A88F7 for ; Wed, 10 Feb 2016 18:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNbmdAIo9znd for ; Wed, 10 Feb 2016 18:38:27 -0800 (PST)
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 1A2611A88EA for ; Wed, 10 Feb 2016 18:38:27 -0800 (PST)
Received: by mail-pa0-x22e.google.com with SMTP id q3so910647pag.1 for ; Wed, 10 Feb 2016 18:38:27 -0800 (PST)
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-type :content-transfer-encoding; bh=cm8AX04g5lo7LUtIybUomSR0wgPyJEirn3hzDwGSFX4=; b=gZ+2DCMYoMiykToeTjVkchkgGOfYw0aIc6EX1apUx+G2yXxUt4PB3fVzqvkrdbI610 93xCC+XhwqF99P3LYRVInTlMr7SBA+JvcFj3F3tYVDxa+8nyJ373c/KN73mRyr1u/nQe 0VF+dmG4JUvtO2bIXX1h+ekfMf3t7zEFhvqK3DdkT4kmY8cpKJBM0FJXJ0W33XhACQAv v/NwLOsdekVk2nZrJQSglUuUjjRWzGm/sXiQ5XefnfCtV+MqLpJrgxmv7AXNzFZ7CxCJ xxmam864lHxRTPWqpfma7BT1Ugxc2P4nukmXLam3uDfmJ9I4tUyLADF2zIE3KId5cviB nlFQ==
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-type :content-transfer-encoding; bh=cm8AX04g5lo7LUtIybUomSR0wgPyJEirn3hzDwGSFX4=; b=Sdr2qu13DIsvYqmBpIbhv9lKIDGWYkjL1+vazL6u7dFPBY0fMaCpAIa6CW7nR5Q5LJ YSQmf+sGVRB1RHeOQw3FqWXjuya1kQk6rRTXxboj6GO2OlYTF0bOvtxa/NOV3wpaDP1l NYCj541JI7zpOX+SJND8HT4kmUdphecM8MSw+iJpfiyRyO96u6z6u5qVA6CGAxKm84Up VRUYiCVI0l6eBlnmVi5lZBYN4l99KZ8ueL3einQrnZ1cIOVyIjl1GYAEAD3rabqYSuEq 9ueG9FqFs+T4r/GYOamHQQlKuEGnovBNF/TS1nD9LhTiKeyTDQ9+l+lhFDeZOLivoAYr tdUA==
X-Gm-Message-State: AG10YORbTf40O3vZ0Gg9V2yGJPKqPCjhQHSFK03p85mf1EwbzO7Frl6tw+zgLc9ii89POg==
X-Received: by 10.66.229.104 with SMTP id sp8mr63297780pac.53.1455158306716; Wed, 10 Feb 2016 18:38:26 -0800 (PST)
Received: from ?IPv6:2406:e007:60f8:1:45ae:f971:31c3:8836? ([2406:e007:60f8:1:45ae:f971:31c3:8836]) by smtp.gmail.com with ESMTPSA id z67sm8041834pfa.71.2016.02.10.18.38.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 18:38:25 -0800 (PST)
To: Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BBF425.5070107@gmail.com>
Date: Thu, 11 Feb 2016 15:38:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Fernando Gont , v6ops list 
Subject: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 02:38:28 -0000

On 10/02/2016 10:41, Tom Herbert wrote:
> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>  wrote:
>> Ole,
>>
>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>> ...
>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>> anyone studied this over time?
>>>>
>>>> We're planning for the long term here. While I agree that this is a very
>>>> interesting question, we shouldn't base future practice on it.
>>>
>>> I'm not sure what you imply by that.
>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>
>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>> load balancing products that support the flow label, in order to create an incentive
>> for users to run host stacks that set the flow label by default. Actually I think
>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>> to 3-tuple if the transport header isn't the first Next Header.
>>
>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>
>> Windows, Linux, OS X, iOS and Android would be a good start.
> 
> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
> time now. Support was added in Linux to send non-zero flow labels by
> default, Android will pick those up the next time they rebase (I still
> don't know what the status is in Windows). In reality, setting the
> flow label on the host is near zero cost and as long as network
> devices are choking on them (we don't have any evidence of that)
> there's no reason why we can't get to widespread usage in a relatively
> short period of time.

Windows 7 doesn't set any value by default, and I can't find a netshell
command to switch it on. (I assume a TCP app can set it through the socket
interface, but that's beside the point.)

    Brian


From nobody Thu Feb 11 01:57:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FBE1ACE25 for ; Thu, 11 Feb 2016 01:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz6QLC1lnLBE for ; Thu, 11 Feb 2016 01:57:32 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 848741ACE23 for ; Thu, 11 Feb 2016 01:57:32 -0800 (PST)
Received: by mail-ig0-x22f.google.com with SMTP id xg9so31737202igb.1 for ; Thu, 11 Feb 2016 01:57:32 -0800 (PST)
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-type; bh=FRRAMlIFoQWL8mNfbZpKB+lC4IJI2Q40q+rQ3L3zg1Y=; b=c2jjNuAPl00TBTPwmB/gvjtJDCODQT2e/Ly96sqdLf4dpeA9FDqsWv+EFjzu//pNmM /k4YkLd2yYbToaAK7vNQVCgDFiSgA5J/N6oJhNLvMWUwD0Ui6GKpk1cOwfbMZPVcpgms ui0FbZuPbUPK8x26wTINxGfI1vmXkmRtRK9RAt/gECqnt1EooRsHvAq6rQDR/ht5j21g AeJAtuhNIAkpb7HXvEjeDxMHemhYfuiZfzYpzwlAV2jQ6oSsPcfwH0EBL68IOVkgSGt/ IpdLNuscWBxJbIE8ogeo97z/o/rC6Zi0zinsmBm6T9vB02jSai5I2fgMsz8GCWIT1TAZ UizQ==
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-type; bh=FRRAMlIFoQWL8mNfbZpKB+lC4IJI2Q40q+rQ3L3zg1Y=; b=B29ywUsKfcSozTfIV/YFEs0tYCGXf8wwZ2dwA3jKaHK8tcMFyuu9MsdER4N3VaBnaf PTVUWC2dfDJ2OUbKa+Z36Y9hSlSUSwTpupE68iV/AJwBOruVJzsb1kTaFtvd/b1j0wqx u9FggRKvgZp5EqUsc4r8DaPvPpU7uA7EdF0uzXWIS+JRyg2oKjBuIen21BgWX/cAjR+/ Dd2H5ti2FCFTes8bKD3+hqZzepVxhFpA713+KbYJNbkA2QtlW3nLfFKGFVC6OFTXmnij jDzS5OCYWJ+cy7dpk8F/IT1B2to1XuEszbbC8HInh+c3gEmFgu4OA7rFUA4lOsmLFCFk mibA==
X-Gm-Message-State: AG10YORo+eyYg8/c3WfxDbycdllB13oQOzW03i5v+rHV0VI7SnNJfK+u11Cr0geAi8w+r1wkFvicTUy6HzP3Fg==
MIME-Version: 1.0
X-Received: by 10.50.87.7 with SMTP id t7mr15793051igz.65.1455184651623; Thu, 11 Feb 2016 01:57:31 -0800 (PST)
Received: by 10.107.160.203 with HTTP; Thu, 11 Feb 2016 01:57:31 -0800 (PST)
In-Reply-To: <56BBE231.9030706@gmail.com>
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BBE231.9030706@gmail.com>
Date: Thu, 11 Feb 2016 10:57:31 +0100
Message-ID: 
From: Tom Herbert 
To: Brian E Carpenter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 09:57:33 -0000

On Thu, Feb 11, 2016 at 2:21 AM, Brian E Carpenter
 wrote:
> Somebody said:
>
>>> and we might be making parsing the HBH optional.
>
> We already did that, in RFC 7045 section 2.2.
>
>>> It shouldn't be that hard to support a white list of unknown extension
>>> headers that can be set by the operator.
>
> We pretty much require that in RFC 7045 section 2.1:
>
>   "...the discard policy for each standard type of extension
>    header MUST be individually configurable.  The default configuration
>    SHOULD allow all standard extension headers.
>
>    Experimental IPv6 extension headers SHOULD be treated in the same way
>    as standard extension headers, including an individually configurable
>    discard policy.  However, the default configuration MAY drop
>    experimental extension headers.
>
>    Forwarding nodes MUST be configurable to allow packets containing
>    unrecognised extension headers, but the default configuration MAY
>    drop such packets."
>
>>> Folks seem to be needing to filter packets, which means processing the
>>> EH chain for reasons other than ECMP. Widespread support would fix the
>>> drops related to ECMP, but not the ones related to the need to filter
>>> based on layer-4 info.
>
> Right. Boxes that insist on parsing the header chain but do not understand
> all header types are doomed to fail. There is no solution to that except
> scrapping those boxes. RFC 6564, 7045, 7112 and draft-ietf-6man-hbh-header-handling
> are mitigations, but broken middleboxes are broken.
>
> I tend to agree with Ole that on the standards front there isn't much
> more we can do. Operators can require their suppliers to support the above
> mitigations, hopefully.
>
Suppose we define an "EH chain length" extension header. This would
include the length of the chain starting from the first byte of the EH
and also a next header value for the header that follow the chain.
This EH could follow HBP. Network nodes can use this to skip over a
long chain to parse the transport header. The receiver would need to
validate the length and protocol are correct in order to prevent
someone from spoofing transport headers.

Tom

>     Brian
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Feb 11 03:08:08 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F821AD0C5 for ; Thu, 11 Feb 2016 03:08:06 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -4.6
X-Spam-Level: 
X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pySRrvEmGlRC for ; Thu, 11 Feb 2016 03:08:04 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A241C1AD0BF for ; Thu, 11 Feb 2016 03:08:01 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aTp6L-0000CMC; Thu, 11 Feb 2016 12:07:57 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>  
In-reply-to: Your message of "Wed, 10 Feb 2016 11:24:08 -0800 ."  
Date: Thu, 11 Feb 2016 12:07:51 +0100
Archived-At: 
Cc: Fernando Gont , =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 11:08:06 -0000

In your letter dated Wed, 10 Feb 2016 11:24:08 -0800 you wrote:
>At Wed, 10 Feb 2016 14:13:06 +0100,
>otroan@employees.org wrote:
>
>> >> if I would design an IPv6 firewall today I'd drop most fragments. they are
> nothing but a DOS vector (for middleboxes).
>> >> (and I've formed that opinion after actually implementing an RFC7597 BR.)
>> >
>> > What about DNS and DNSSEC?  Or are those the exception to "drop *most*
>> > fragments"?
>>
>> those would have to fallback to TCP.
>
>I may misunderstand it, but DNS clients (resolvers) are not supposed
>to fall back to UDP simply because its UDP query times out (because
>the fragmented response is dropped in this scenario).
>
>> the exception would be more
>> like in-sequence, back to back fragments with a maximum fragment
>> chain of 2.
>
>One common practice of the DNS server is to fragment UDP responses at
>the minimum MTU, and a large response with DNSSEC signatures could be
>larger than several thousands of bytes, a max chain of 2 is probably
>not enough (although 3 or 4 is probably okay in practice).  If you
>meant the server should just truncate responses larger than that to
>trigger immediate fall back to TCP by "would have to fallback to TCP"
>above, then I see that.

Clients have some control over fragmentation using the EDNS0 UDP payload size
option.

For example setting the payload size to 1280 minus headers should avoid
fragmentation and will be fine for just about all DNSSEC except some key
rollover with RSA 2048 bit keys.

Unfortunately, there doesn't seem to be any DNS RFC that tells exactly what to
do.



From nobody Thu Feb 11 08:34:22 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5DA1B3452 for ; Thu, 11 Feb 2016 08:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level: 
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqG70w4uxU3d for ; Thu, 11 Feb 2016 08:34:18 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCE61B3454 for ; Thu, 11 Feb 2016 08:34:18 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1BGYEwg002699; Thu, 11 Feb 2016 16:34:14 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u1BGYEwg002699
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1455208455; bh=7wn1Leh37AstyajOn8FgvqCuf3k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=vHL84jT+nbwPyB+KSNXpU5YE4mGdmCysS1aEGZ8XvyYiFtH5V4v3YayaAuVfLuZ3l G/lXFwbhfI5cdtnW9YVXZvVMnXlD0MXLaYyU1Wme6nPAXQPjxPKmvCnarrTjEJHaRc VgpYFwzHrHfB8ExGokaIT24MkHS7foZeKUekq0uU=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id s1AGYE1012907208CX ret-id none; Thu, 11 Feb 2016 16:34:15 +0000
Received: from [192.168.0.10] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1BGYAJl029826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2016 16:34:10 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Tim Chown 
In-Reply-To: <56BBD6DB.6020507@gmail.com>
Date: Thu, 11 Feb 2016 16:34:10 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <55D51005-3098-43C6-9164-5903851133A1@ecs.soton.ac.uk>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3112)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=s1AGYE101290720800; tid=s1AGYE1012907208CX; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: u1BGYEwg002699
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 16:34:20 -0000

> On 11 Feb 2016, at 00:33, Brian E Carpenter =
 wrote:
>=20
> On 11/02/2016 09:34, Dale W. Carder wrote:
>> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 =
at 01:21:50PM -0300:
>>>=20
>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>> Me, I confess I've used things like fc00:1::/64 because they are =
simpler
>>> that some random string of bits.
>>=20
>> I absolutely do not believe it can be expected that sites will =
generate=20
>> random prefixes.
>=20
> Why not, if it's a built-in feature of the CPE? Obviously, humans =
shouldn't
> be messing around with these things.

Sure, for a home network maybe. But in a campus you=E2=80=99d probably =
form an address plan
for your global prefix and map that to ULA space, e.g. =
2001:db8:123:456::/64 would have
a corresponding ULA prefix of fc00::123:456::/64.

Not that I=E2=80=99m aware of any campuses yet using ULAs.=20

>> This will result in more NAT
>=20
> No. ULA is for internal traffic only. You use your ISP-provided prefix =
for
> the Internet.

Indeed. In theory.

>> and all of the horror
>> stories from rfc1918 getting copied over.  For a while someone =
(SixXS?)
>> was running a ULA registry, but I am not sure what came of it.
>>=20
>=20
> It's still there for people who believe it matters. I've never seen =
the
> point, myself.
> https://www.sixxs.net/tools/grh/ula/

Dates back to the old ULA-C proposal, that died a death.
I think that=E2=80=99s draft-hain-ipv6-ulac-02.

Tim

>=20
>   Brian
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Feb 11 09:27:28 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EFF1B36A2 for ; Thu, 11 Feb 2016 09:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UtTmb1pn7yA for ; Thu, 11 Feb 2016 09:27:25 -0800 (PST)
Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CA01B36AA for ; Thu, 11 Feb 2016 09:27:25 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0O2E005007VVZ800@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Thu, 11 Feb 2016 11:27:24 -0600 (CST)
X-Spam-PmxInfo: Server=avs-3, Version=6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.11.171817, SenderIP=0.0.0.0
Received: from DOIT-2NW1MRFY-X.doit.wisc.edu (brie.doit.wisc.edu [144.92.67.198]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0O2E00L0E8HLIV20@smtpauth3.wiscmail.wisc.edu>; Thu, 11 Feb 2016 11:27:22 -0600 (CST)
Date: Thu, 11 Feb 2016 11:27:21 -0600
From: "Dale W. Carder" 
To: Brian E Carpenter 
Message-id: <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com>
In-reply-to: <56BBD6DB.6020507@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 17:27:27 -0000

Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Thu, Feb 11, 2016 at 01:33:31PM +1300:
> On 11/02/2016 09:34, Dale W. Carder wrote:
> > Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
> >>
> >> * Section 3.2: Do folks really generate the prefixes as "required"?
> >> Me, I confess I've used things like fc00:1::/64 because they are simpler
> >> that some random string of bits.
> > 
> > I absolutely do not believe it can be expected that sites will generate 
> > random prefixes.
> 
> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
> be messing around with these things.

Oh, I should clarify my concerns are not at the CPE level, but at the 
enterprise scale where ULA may be used with human friendly / poorly chosen 
prefixes that inevitably overlap.

> > This will result in more NAT
...
> No. ULA is for internal traffic only. You use your ISP-provided prefix for
> the Internet.

To clarify, to mitigate the ULA prefix overlap internally after a merger of 
two internal networks, nothing related to off-site connectivity.  We
have had this issue at our site on ipv4 when our healthcare system and campus 
enterprise network ended up overlapping in 10/8 and needed NAT just to get 
between the two, completely unrelated to off-site connectivity.  Having 
first-hand experienced getting burned I hope we can emphasize the risk
to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 
networks.

I was going to make a similar comment that I initially withheld about
section "6.1. Used in Isolated Networks" to which I would claim
isolation, though often well-intended in my experience ends up being 
temporary when it is found that devices later need external software
updates, control, logging, or ancillary support systems for which
proxying is too hard.  

If it's not obvious I do not like ULA at all, and I know a lot of the
arguments have already been hashed out.  I am hoping that this
guidance can at least be clear about the corners that people will (in 
my mind) inevitably back themselves into so it can be avoided.  There's
a lot of value getting that out.

Dale


From nobody Thu Feb 11 11:12:57 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9B1B3967; Thu, 11 Feb 2016 11:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.903
X-Spam-Level: 
X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZTEF3-hxse7; Thu, 11 Feb 2016 11:12:41 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504061B3964; Thu, 11 Feb 2016 11:12:41 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 4120F180472; Thu, 11 Feb 2016 11:12:03 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160211191203.4120F180472@rfc-editor.org>
Date: Thu, 11 Feb 2016 11:12:03 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org
Subject: [v6ops] BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Feb 2016 19:12:46 -0000

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

        BCP 202        
        RFC 7772

        Title:      Reducing Energy Consumption of Router 
                    Advertisements 
        Author:     A. Yourtchenko,
                    L. Colitti
        Status:     Best Current Practice
        Stream:     IETF
        Date:       February 2016
        Mailbox:    ayourtch@cisco.com, 
                    lorenzo@google.com
        Pages:      6
        Characters: 12555
        See Also:   BCP 202

        I-D Tag:    draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt

        URL:        https://www.rfc-editor.org/info/rfc7772

        DOI:        http://dx.doi.org/10.17487/RFC7772

Frequent Router Advertisement messages can severely impact host power
consumption.  This document recommends operational practices to avoid
such impact.

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


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

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

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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


The RFC Editor Team
Association Management Solutions, LLC


From nobody Thu Feb 11 16:07:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA71B3CF7 for ; Thu, 11 Feb 2016 16:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bBlhJufxJim for ; Thu, 11 Feb 2016 16:07:37 -0800 (PST)
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 5115F1B3CF5 for ; Thu, 11 Feb 2016 16:07:37 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id q63so37542533pfb.0 for ; Thu, 11 Feb 2016 16:07:37 -0800 (PST)
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-type :content-transfer-encoding; bh=rrzSu0gPKgkVaT84HDLlDRPd18OEkevGR++E5X9vofA=; b=VGTVtI1eb3eMLYSTDzfIMAsY5O3rTgCgDox77siyqSZmpsX4ET0HJQGLzmRSnHZFEo M3wKLWurBsERPGDtHV/8y/mtFyZSLXNGOk/Ni7KW0f7gowyZRW9sNeunoLkrPriJerN/ vlqXg37ki1ujSL7fb0tU8jnsY6zHeLVyVEvfcQxtxpB2mXmcPinAzXVBj+50G+/GCdOZ kTg54bCRVia2RZoYDfzuqVsc3ysqZcvxL8bfgOZ9tnFMXfPdzAA1LCTAXNVSu0x2qugP Il9/43ZkZoIJ0nYhEdkLFzukl0vEVI7/j0J2cg4bRKB3y9GVJXwVMehyHNVLjUarR/av t2LA==
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-type :content-transfer-encoding; bh=rrzSu0gPKgkVaT84HDLlDRPd18OEkevGR++E5X9vofA=; b=Ovo1MxRsR9Gdn3rF+weZD9TeN/uC+B8ogVkV/EYa7UyiIh9hy7wXZ3KqY/YE4aFoOm q1hiDSUCXuoldp00ne8f/37LJhGzaW/vd+V6TPEcxJeb6J3soLoFJHDnKqX+700R24Z8 GmntRcQNFJhkjI0f4V6QK3MCg5/cPqHOzoQXP7HCBdJJNtlilJA7J0oGmpxvhTWkohaF vP+GpBKyeypqrDaiOulhSLJBgmQiKQb4ikln4uGNFugdX6Jk9/JcW/N1UsQLfNo9c5j6 bdfEiY5sO3zaSGxk4LGIVVD9uFg+x1dSQ0xNd3PEINEno/ZkuN4FEpIkL5iexmAfsMHt spfw==
X-Gm-Message-State: AG10YOTDcIrBUr5VR2NrY+HHmdV6GAu4sCs0b8alK8uk358o/obKJwNfjIBwD7sDsBqxCQ==
X-Received: by 10.98.80.206 with SMTP id g75mr47260746pfj.127.1455235657016; Thu, 11 Feb 2016 16:07:37 -0800 (PST)
Received: from ?IPv6:2406:e007:5496:1:28cc:dc4c:9703:6781? ([2406:e007:5496:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id to9sm14805920pab.3.2016.02.11.16.07.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 16:07:35 -0800 (PST)
To: Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BBE231.9030706@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BD224F.1050406@gmail.com>
Date: Fri, 12 Feb 2016 13:07:43 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 00:07:42 -0000

On 11/02/2016 22:57, Tom Herbert wrote:
...
> Suppose we define an "EH chain length" extension header. This would
> include the length of the chain starting from the first byte of the EH
> and also a next header value for the header that follow the chain.
> This EH could follow HBP. Network nodes can use this to skip over a
> long chain to parse the transport header. The receiver would need to
> validate the length and protocol are correct in order to prevent
> someone from spoofing transport headers.

https://tools.ietf.org/html/draft-zhang-6man-offset-option-01

But it doesn't help, because any middlebox that insists on trying
to parse all the headers will not make use of this feature.

   Brian


From nobody Thu Feb 11 16:15:31 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B461B3D01 for ; Thu, 11 Feb 2016 16:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnBfU30tI08K for ; Thu, 11 Feb 2016 16:15:24 -0800 (PST)
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 40EA91A6FB8 for ; Thu, 11 Feb 2016 16:15:24 -0800 (PST)
Received: by mail-pa0-x22f.google.com with SMTP id ho8so37075386pac.2 for ; Thu, 11 Feb 2016 16:15:24 -0800 (PST)
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-type :content-transfer-encoding; bh=Zzm0JxR6dxXgofbTa0fnn3t6xldtFbmrNzRHIJa5k1w=; b=YF028IOKTTwFv3Ms8hwwBnYq244QI5xOlmYRLN9gacmAr95HB4lrKv0msmZIzG6NzE MvtIxhS5EkkaJuP1gCyoUD7CrzpbwC2YuzJuzqbVvsXfiBM15qv+m/QXkn8b6TVPt3uA XRsg7bgi8kLNuudSJx0f7LPoOD4IQQJeqAOKnVBUX3dZySUD8csOQWLQ1DQH2dJ0Z2VG bd8LxRyjtgvIDlcHFiMbitLlXRsQ1Mc6tI18dDQwmh1ayKBfze6egi4Y2YKPgXwGwj6t HT6O83xRw8LXwCP9tcnOWBJhcvVmlXRNWAO9YFJJxEKDi/l8bZVMwfz45zOWcZZymDLU 9URw==
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-type :content-transfer-encoding; bh=Zzm0JxR6dxXgofbTa0fnn3t6xldtFbmrNzRHIJa5k1w=; b=UpcLzUPsfw0GgQNrNXg7sZTWZS+F7MtTUZ0ECNaO4/wkX6u7u2yNlW49IMBvZ21E6r dRXfXicTiMNkGhl7E0rdI4wxxb8bX+z4Lfr5VUJw7HsSMEeEmsW4lsQUrjMRcJOEcxKb Ztq0YlYu7BGE8nh3Aav3E48jam/5zFwx3YJa7hN8f3xtJclcs42yHxJ+zTxjQBAsAHqs lkJkBIuJ73i5ndSw+IbodnZsywr0AY1lPu5a2aV8acy8QE7AvKCqmwT/Kns9dhZsDw+K RVMM3T5o4uVfgXqGlXpiquV5dq9wsrVsIOhoSGUou1pWVspgxKxtoJZ3+LAVdOqa4tj8 evzA==
X-Gm-Message-State: AG10YOQgESH+J4Xn3qWVhRuw5IZ5qh3/sJtIlWTA8kbpTZYmvlUeryia26ZUHtkuPwdBDw==
X-Received: by 10.67.7.42 with SMTP id cz10mr56081290pad.158.1455236123944; Thu, 11 Feb 2016 16:15:23 -0800 (PST)
Received: from ?IPv6:2406:e007:5496:1:28cc:dc4c:9703:6781? ([2406:e007:5496:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y11sm14766169pfa.85.2016.02.11.16.15.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 16:15:23 -0800 (PST)
To: "Dale W. Carder" 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BD2422.4090501@gmail.com>
Date: Fri, 12 Feb 2016 13:15:30 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 00:15:29 -0000

On 12/02/2016 06:27, Dale W. Carder wrote:
> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Thu, Feb 11, 2016 at 01:33:31PM +1300:
>> On 11/02/2016 09:34, Dale W. Carder wrote:
>>> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
>>>>
>>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>>>> that some random string of bits.
>>>
>>> I absolutely do not believe it can be expected that sites will generate 
>>> random prefixes.
>>
>> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
>> be messing around with these things.
> 
> Oh, I should clarify my concerns are not at the CPE level, but at the 
> enterprise scale where ULA may be used with human friendly / poorly chosen 
> prefixes that inevitably overlap.

If ULAs are assigned other than as defined in the standard, sure. But that
is just as bad a blunder as stealing a routable prefix and I would have
little sympathy.

The chance of a clash when two networks merge is minute if you apply the standard.

>>> This will result in more NAT
> ...
>> No. ULA is for internal traffic only. You use your ISP-provided prefix for
>> the Internet.
> 
> To clarify, to mitigate the ULA prefix overlap internally after a merger of 
> two internal networks, nothing related to off-site connectivity.  We
> have had this issue at our site on ipv4 when our healthcare system and campus 
> enterprise network ended up overlapping in 10/8 and needed NAT just to get 
> between the two, completely unrelated to off-site connectivity.  Having 
> first-hand experienced getting burned I hope we can emphasize the risk
> to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 
> networks.

Well yes, even Duh!.

> I was going to make a similar comment that I initially withheld about
> section "6.1. Used in Isolated Networks" to which I would claim
> isolation, though often well-intended in my experience ends up being 
> temporary when it is found that devices later need external software
> updates, control, logging, or ancillary support systems for which
> proxying is too hard.  
> 
> If it's not obvious I do not like ULA at all, and I know a lot of the
> arguments have already been hashed out.  I am hoping that this
> guidance can at least be clear about the corners that people will (in 
> my mind) inevitably back themselves into so it can be avoided.  There's
> a lot of value getting that out.

Exactly. And we should include a very strong warning against manually
assigning a human-friendly prefix.

    Brian


From nobody Thu Feb 11 16:48:27 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191F1B3D2F for ; Thu, 11 Feb 2016 16:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.902
X-Spam-Level: 
X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8bpzKakHlyx for ; Thu, 11 Feb 2016 16:48:13 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9171B3D3D for ; Thu, 11 Feb 2016 16:47:54 -0800 (PST)
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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 6D9B434930F; Fri, 12 Feb 2016 00:47:50 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 60FA916004B; Fri, 12 Feb 2016 00:47:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 50A4F1600AF; Fri, 12 Feb 2016 00:47:50 +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 K6rDWpPq05We; Fri, 12 Feb 2016 00:47:50 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id D1F7A16004B; Fri, 12 Feb 2016 00:47:49 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DEF1F4201F9E; Fri, 12 Feb 2016 11:47:47 +1100 (EST)
To: Philip Homburg 
From: Mark Andrews 
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>  
In-reply-to: Your message of "Thu, 11 Feb 2016 12:07:51 +0100." 
Date: Fri, 12 Feb 2016 11:47:47 +1100
Message-Id: <20160212004747.DEF1F4201F9E@rock.dv.isc.org>
Archived-At: 
Cc: Fernando Gont , v6ops@ietf.org, =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 00:48:22 -0000

In message , Philip Homburg writes:
> In your letter dated Wed, 10 Feb 2016 11:24:08 -0800 you wrote:
> >At Wed, 10 Feb 2016 14:13:06 +0100,
> >otroan@employees.org wrote:
> >
> >> >> if I would design an IPv6 firewall today I'd drop most fragments. they are
> > nothing but a DOS vector (for middleboxes).
> >> >> (and I've formed that opinion after actually implementing an RFC7597 BR.)
> >> >
> >> > What about DNS and DNSSEC?  Or are those the exception to "drop *most*
> >> > fragments"?
> >>
> >> those would have to fallback to TCP.
> >
> >I may misunderstand it, but DNS clients (resolvers) are not supposed
> >to fall back to UDP simply because its UDP query times out (because
> >the fragmented response is dropped in this scenario).
> >
> >> the exception would be more
> >> like in-sequence, back to back fragments with a maximum fragment
> >> chain of 2.
> >
> >One common practice of the DNS server is to fragment UDP responses at
> >the minimum MTU, and a large response with DNSSEC signatures could be
> >larger than several thousands of bytes, a max chain of 2 is probably
> >not enough (although 3 or 4 is probably okay in practice).  If you
> >meant the server should just truncate responses larger than that to
> >trigger immediate fall back to TCP by "would have to fallback to TCP"
> >above, then I see that.
> 
> Clients have some control over fragmentation using the EDNS0 UDP payload size
> option.

Which is how recursive server work around stupid firewalls. A
firewall could open a slit to let through non-initial fragments
when it opens the pin hole to let through the initial fragment /
full packet.  It doesn't have to be all fragments.

> For example setting the payload size to 1280 minus headers should avoid
> fragmentation and will be fine for just about all DNSSEC except some key
> rollover with RSA 2048 bit keys.

Lots of answers from signed zones are > 1500 let alone 1280.
Reassembly attacks on the DNS are easy enough to address with
stronger checksums in a EDNS option or a well known TSIG secret
(this devolves to a crypto strength checksum).  We already have
EDNS COOKIES to address off path spoof of single / last fragment
responses.  The checksum/TSIG bind ties the last fragment to the
rest of the response.

We already see some TLD servers deploying EDNS COOKIES (the code
points are allocated) and in the Alexa top/bottom 1000.  .GOV zones
are the only sample w/o EDNS COOKIES deployment.
https://ednscomp.isc.org/compliance/summary.html

> Unfortunately, there doesn't seem to be any DNS RFC that tells exactly what to
> do.

Why should there be? Fragments are part of IPv6. Why shouldn't the
DNS depend on them.

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Thu Feb 11 22:59:20 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05641B4065 for ; Thu, 11 Feb 2016 22:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level: 
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRqPJswQkZ7l for ; Thu, 11 Feb 2016 22:59:15 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE471B3347 for ; Thu, 11 Feb 2016 22:59:14 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1C6xA4G028587; Fri, 12 Feb 2016 06:59:11 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u1C6xA4G028587
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1455260351; bh=dCFsfqiKf0sH+YJZoWBGHqreDhE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=sLM0AJggRu8HqetyFo77K+GzOywBwGL8ccsW68jU/wIRHjg3zfsYfqEbr6f3GGdp8 kLGBD2OMCJM87MZWelE01kfAQE6y5SYCeVzxeSU/LH8cdLfHPXR0e9Pi/8ua6vYeVd UI6TWP5YByrnFROB8zKvd8tAL3KaFH0vw5sUmwZQ=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id s1B6xA0141900474yM ret-id none; Fri, 12 Feb 2016 06:59:11 +0000
Received: from [IPv6:2001:a88:d510:1101:34b2:6932:11a5:940a] (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:34b2:6932:11a5:940a] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u1C6x1ri012635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2016 06:59:02 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Tim Chown 
X-Mailer: iPad Mail (13D15)
In-Reply-To: <56BD2422.4090501@gmail.com>
Date: Fri, 12 Feb 2016 06:59:01 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>
To: Brian E Carpenter 
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=s1B6xA014190047400; tid=s1B6xA0141900474yM; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: u1C6xA4G028587
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 06:59:17 -0000

On 12 Feb 2016, at 00:15, Brian E Carpenter  wr=
ote:
>=20
>> On 12/02/2016 06:27, Dale W. Carder wrote:
>> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Thu, Feb 11=
, 2016 at 01:33:31PM +1300:
>>>> On 11/02/2016 09:34, Dale W. Carder wrote:
>>>> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 a=
t 01:21:50PM -0300:
>>>>>=20
>>>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>>>> Me, I confess I've used things like fc00:1::/64 because they are simpl=
er
>>>>> that some random string of bits.
>>>>=20
>>>> I absolutely do not believe it can be expected that sites will generate=
=20
>>>> random prefixes.
>>>=20
>>> Why not, if it's a built-in feature of the CPE? Obviously, humans should=
n't
>>> be messing around with these things.
>>=20
>> Oh, I should clarify my concerns are not at the CPE level, but at the=20
>> enterprise scale where ULA may be used with human friendly / poorly chose=
n=20
>> prefixes that inevitably overlap.
>=20
> If ULAs are assigned other than as defined in the standard, sure. But that=

> is just as bad a blunder as stealing a routable prefix and I would have
> little sympathy.
>=20
> The chance of a clash when two networks merge is minute if you apply the s=
tandard.
>=20
>>>> This will result in more NAT
>> ...
>>> No. ULA is for internal traffic only. You use your ISP-provided prefix f=
or
>>> the Internet.
>>=20
>> To clarify, to mitigate the ULA prefix overlap internally after a merger o=
f=20
>> two internal networks, nothing related to off-site connectivity.  We
>> have had this issue at our site on ipv4 when our healthcare system and ca=
mpus=20
>> enterprise network ended up overlapping in 10/8 and needed NAT just to ge=
t=20
>> between the two, completely unrelated to off-site connectivity.  Having=20=

>> first-hand experienced getting burned I hope we can emphasize the risk
>> to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE)=
=20
>> networks.
>=20
> Well yes, even Duh!.
>=20
>> I was going to make a similar comment that I initially withheld about
>> section "6.1. Used in Isolated Networks" to which I would claim
>> isolation, though often well-intended in my experience ends up being=20
>> temporary when it is found that devices later need external software
>> updates, control, logging, or ancillary support systems for which
>> proxying is too hard. =20
>>=20
>> If it's not obvious I do not like ULA at all, and I know a lot of the
>> arguments have already been hashed out.  I am hoping that this
>> guidance can at least be clear about the corners that people will (in=20
>> my mind) inevitably back themselves into so it can be avoided.  There's
>> a lot of value getting that out.
>=20
> Exactly. And we should include a very strong warning against manually
> assigning a human-friendly prefix.

Definitely. Even if we know what's likely to happen in practice. And if you a=
re manually picking a ULA /48 at least don't do all zeros - even using some b=
its of your global /48 in the ULA prefix is better than that.

Tim

>=20
>    Brian
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Feb 12 00:02:11 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B71B4169 for ; Fri, 12 Feb 2016 00:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opIWur1sRuez for ; Fri, 12 Feb 2016 00:02:08 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 E92051B4168 for ; Fri, 12 Feb 2016 00:02:07 -0800 (PST)
Received: by mail-ig0-x22c.google.com with SMTP id 5so5348437igt.0 for ; Fri, 12 Feb 2016 00:02:07 -0800 (PST)
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-type; bh=fAnkLlz1ecdiFx81RadLgPe8EAcdFOTqOz6pyXhAHm4=; b=H4HAHjsQT5+cufIxbHu0bLlwvOjkNIYh0aFYiUEavgpgf8tgY/2ypkc5wSfBBho7px S9nqGMl3UDBJwTGI8G+B2BK+DxMzWTYXBIiblRrpzLaPJ8+S9mUtGdjYM4ZpXO0WpJeG UShgCj+8HXQIsDu4TJyFACT6C3ywQRKoG44OQB8s1WQ6MYb+ZnQU9Jy+JJ3lnGRHMeyj jc3i6/8y7MepzdqGZWjWJ1da9xrZs6nxnd7V1d94pGuXHbjr6jgEzQClNMj4JoVhjdtm O05YOwuXxud8ky+SP6LirSsUyeOLM2rlSmFi91EHoLbBCk4Xv2Qdc+yYbDE8psE9J35e 9X4A==
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-type; bh=fAnkLlz1ecdiFx81RadLgPe8EAcdFOTqOz6pyXhAHm4=; b=klcAOsbr7GFKHqn+8ndwD7KCIejr6JySgQj4xD78wGyGJkJ3xbT+tiPeoSKQ9d0hyD o8wHsPyolpgyWm2fGagEQjolIvu8qIwzZYWd/sc/jWrZFBSeK7EgTIAQTInv6mlRAul7 Nt6OgdOLWGlSSvm51+MqEOb5IWGWPtSk+Adz3qKsBaJ7YtNkp/MyT5STnK29IxlbRGsa UKNF2MPxB+3Pca4bROqiiuVbsvludPZTvPAFoo5m4DkW200Uv6X+A7kq3J1tzypmtzJG C+ws5fmoslNlIEgT1yv5UdKJ3Mlr+6nDkzqjJoa08YcB1zmsrh1Y2eLjiU77vqit0UUH YCjg==
X-Gm-Message-State: AG10YOSYkah9Fy/ePF6Iz4KUDFUsRH8o+RySDQtBCZ/GjqPs6f3FHxXc9a53MXrzH6KC6yCMLpoi4nCmtiZwZw==
MIME-Version: 1.0
X-Received: by 10.50.20.197 with SMTP id p5mr2610905ige.89.1455264127242; Fri, 12 Feb 2016 00:02:07 -0800 (PST)
Received: by 10.107.160.203 with HTTP; Fri, 12 Feb 2016 00:02:07 -0800 (PST)
In-Reply-To: <56BD224F.1050406@gmail.com>
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BBE231.9030706@gmail.com>  <56BD224F.1050406@gmail.com>
Date: Fri, 12 Feb 2016 09:02:07 +0100
Message-ID: 
From: Tom Herbert 
To: Brian E Carpenter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 08:02:09 -0000

On Fri, Feb 12, 2016 at 1:07 AM, Brian E Carpenter
 wrote:
> On 11/02/2016 22:57, Tom Herbert wrote:
> ...
>> Suppose we define an "EH chain length" extension header. This would
>> include the length of the chain starting from the first byte of the EH
>> and also a next header value for the header that follow the chain.
>> This EH could follow HBP. Network nodes can use this to skip over a
>> long chain to parse the transport header. The receiver would need to
>> validate the length and protocol are correct in order to prevent
>> someone from spoofing transport headers.
>
> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01
>
> But it doesn't help, because any middlebox that insists on trying
> to parse all the headers will not make use of this feature.
>
Right, but realistically if we want to send extension headers into the
Internet we can't wait an indefinite amount of time for every single
device to properly handle them. It seems that we'd want to apply a
happy eyeballs approach. If the offset option makes it more palatable
for some devices to forward packets with EH that could move things
forward by some amount. I also see a use case for this at the end
hosts, a ridiculously long chain could be a nice DOS attack and the
offset option might mitigate that. For instance, before processing the
chain we could verify if an encapsulated TCP packet refers to a valid
connection.

Tom

>    Brian


From nobody Fri Feb 12 03:27:07 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF771B43BC for ; Fri, 12 Feb 2016 03:27:05 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofTfCxXkWRH2 for ; Fri, 12 Feb 2016 03:27:03 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE7A1B43BB for ; Fri, 12 Feb 2016 03:27:02 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u1CBQm6N057535 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2016 11:26:49 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local
Message-ID: <56BDC177.9050508@foobar.org>
Date: Fri, 12 Feb 2016 11:26:47 +0000
From: Nick Hilliard 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Mark Andrews 
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org>
In-Reply-To: <20160212004747.DEF1F4201F9E@rock.dv.isc.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Fernando Gont , v6ops@ietf.org, =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 11:27:05 -0000

Mark Andrews wrote:
> Why should there be? Fragments are part of IPv6. Why shouldn't the
> DNS depend on them.

EHs are dropped in ~10% of cases according to Fernando's draft (ymmv,
etc).  This isn't justification for using or not using EHs, btw, just a
observation that if the DNS depends on them, operational problems are
likely to occur.

Nick


From nobody Fri Feb 12 03:30:48 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCA1B43C7 for ; Fri, 12 Feb 2016 03:30:47 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUZhhGdxFjY2 for ; Fri, 12 Feb 2016 03:30:44 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (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 4A0D11B43BA for ; Fri, 12 Feb 2016 03:30:44 -0800 (PST)
Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 92DD115EC4F for ; Fri, 12 Feb 2016 12:30:37 +0100 (CET)
Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 3EE4F426FC9 for ; Fri, 12 Feb 2016 12:30:42 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 3CB988733; Fri, 12 Feb 2016 12:30:42 +0100 (CET)
Date: Fri, 12 Feb 2016 12:30:42 +0100
From: Enno Rey 
To: v6ops@ietf.org
Message-ID: <20160212113042.GC37655@ernw.de>
References:  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56BDC177.9050508@foobar.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 11:30:47 -0000

Hi,

On Fri, Feb 12, 2016 at 11:26:47AM +0000, Nick Hilliard wrote:
> Mark Andrews wrote:
> > Why should there be? Fragments are part of IPv6. Why shouldn't the
> > DNS depend on them.
> 
> EHs are dropped in ~10% of cases according to Fernando's draft (ymmv,
> etc).  This isn't justification for using or not using EHs, btw, just a
> observation that if the DNS depends on them, operational problems are
> likely to occur.

DNS has plenty of ways to work around those, see https://www.insinuator.net/2015/11/some-notes-on-the-drop-ipv6-fragments-vs-this-will-break-dnssec-debate/.

best

Enno






> 
> Nick
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


From nobody Fri Feb 12 04:36:11 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840B31B44CA for ; Fri, 12 Feb 2016 04:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_fY4t2_3oZL for ; Fri, 12 Feb 2016 04:36:08 -0800 (PST)
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 E39121B44D0 for ; Fri, 12 Feb 2016 04:36:07 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aUCxC-0000IOC; Fri, 12 Feb 2016 13:36:06 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <56B9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF73D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47.6000804@si6networks.com>  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> 
In-reply-to: Your message of "Fri, 12 Feb 2016 11:47:47 +1100 ." <20160212004747.DEF1F4201F9E@rock.dv.isc.org> 
Date: Fri, 12 Feb 2016 13:36:04 +0100
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 12:36:10 -0000

In your letter dated Fri, 12 Feb 2016 11:47:47 +1100 you wrote:
>> For example setting the payload size to 1280 minus headers should avoid
>> fragmentation and will be fine for just about all DNSSEC except some key
>> rollover with RSA 2048 bit keys.
>
>Lots of answers from signed zones are > 1500 let alone 1280.

As far as I can tell, it is quite possible to run DNSSEC with 2048 bit RSA
keys and have everything fit in 1280, except during some key rollovers.

The interesting thing is that for .org, a DNSKEY answer is larger than 1280,
but is not fragemented.

It seems that part of the DNS community will fragment at 1280 (to avoid PMTU
problems). Andother part fragments at 1500 or something, has PMTU problems
but avoids more problems with firewalls dropping fragmented packets.

>Why should there be? Fragments are part of IPv6. Why shouldn't the
>DNS depend on them.

Because when it comes to fragmentation, IPv6 is in practice worse than IPv4.
It was a nice idea at the time to only let hosts do fragmentation. But if
you look at DNS then IPv6 is clearly worse than IPv4.

Note, it is easy to tell people to just fix their firewalls to let fragments
go through, but they may just ignore you and point out that DNS works fine
on IPv4.



From nobody Fri Feb 12 04:51:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7174E1B44F5 for ; Fri, 12 Feb 2016 04:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjsTLCZrtj2G for ; Fri, 12 Feb 2016 04:51:07 -0800 (PST)
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 3A59D1B44C4 for ; Fri, 12 Feb 2016 04:51:07 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aUDAW-0000F7C; Fri, 12 Feb 2016 13:49:52 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <56BB2341.4030002@si6networks.com>   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org> <20160212113042.GC37655@ernw.de> 
In-reply-to: Your message of "Fri, 12 Feb 2016 12:30:42 +0100 ." <20160212113042.GC37655@ernw.de> 
Date: Fri, 12 Feb 2016 13:49:51 +0100
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 12:51:09 -0000

In your letter dated Fri, 12 Feb 2016 12:30:42 +0100 you wrote:
>DNS has plenty of ways to work around those, see https://www.insinuator.net/201
>5/11/some-notes-on-the-drop-ipv6-fragments-vs-this-will-break-dnssec-debate/.

This analysis is very much incomplete.

For IPv6 you have case 4.5, response is smaller than the local MTU, but bigger
than PMTU.

DNS servers generally cannot do PMTU discovery. So these packets get dropped.

Unless the server fragments at 1280. In which case it has to set TC for
a lot of requests (in some deployment scenarios). Which results in a lot of
retries over TCP, which may be beyond what the current setup can handle.



From nobody Fri Feb 12 05:05:19 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089601A0024 for ; Fri, 12 Feb 2016 05:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jccd-F6fW3n1 for ; Fri, 12 Feb 2016 05:05:16 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (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 DF4141A0018 for ; Fri, 12 Feb 2016 05:05:15 -0800 (PST)
Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 045DC15EC4F for ; Fri, 12 Feb 2016 14:05:08 +0100 (CET)
Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 9CDF14268C5 for ; Fri, 12 Feb 2016 14:05:12 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 817F287A7; Fri, 12 Feb 2016 14:05:12 +0100 (CET)
Date: Fri, 12 Feb 2016 14:05:12 +0100
From: Enno Rey 
To: v6ops@ietf.org
Message-ID: <20160212130512.GO37655@ernw.de>
References:   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org> <20160212113042.GC37655@ernw.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 13:05:18 -0000

Hi,

On Fri, Feb 12, 2016 at 01:49:51PM +0100, Philip Homburg wrote:
> In your letter dated Fri, 12 Feb 2016 12:30:42 +0100 you wrote:
> >DNS has plenty of ways to work around those, see https://www.insinuator.net/201
> >5/11/some-notes-on-the-drop-ipv6-fragments-vs-this-will-break-dnssec-debate/.
> 
> This analysis is very much incomplete.
> 
> For IPv6 you have case 4.5, response is smaller than the local MTU, but bigger
> than PMTU.

good point actually, I missed that one. question remains though: how often does that one occur in real-life?
read: is it worth to accept v6 fragments into your own network just to avoid this specific case? [note I'm talking from an enterprise/edge network perspective here, not from a transit network perspective]


> 
> DNS servers generally cannot do PMTU discovery. So these packets get dropped.
> 
> Unless the server fragments at 1280. In which case it has to set TC for
> a lot of requests (in some deployment scenarios). Which results in a lot of
> retries over TCP, which may be beyond what the current setup can handle.

I hear you. no offense, but I've yet to see those servers not being able to handle an increased amount of TCP based DNS requests coming in. 

Enno




> 
> 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


From nobody Fri Feb 12 05:34:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A701A00CE for ; Fri, 12 Feb 2016 05:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MANGLED_BIGGER=2.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxqOAoXCgAoU for ; Fri, 12 Feb 2016 05:34:50 -0800 (PST)
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 B604B1A00CA for ; Fri, 12 Feb 2016 05:34:49 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aUDri-0000HIC; Fri, 12 Feb 2016 14:34:30 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org> <20160212113042.GC37655@ernw.de>  <20160212130512.GO37655@ernw.de> 
In-reply-to: Your message of "Fri, 12 Feb 2016 14:05:12 +0100 ." <20160212130512.GO37655@ernw.de> 
Date: Fri, 12 Feb 2016 14:34:29 +0100
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 13:34:51 -0000

In your letter dated Fri, 12 Feb 2016 14:05:12 +0100 you wrote:
>> This analysis is very much incomplete.
>> 
>> For IPv6 you have case 4.5, response is smaller than the local MTU, but bigge
>r
>> than PMTU.
>
>good point actually, I missed that one. question remains though: how often does
> that one occur in real-life?
>read: is it worth to accept v6 fragments into your own network just to avoid th
>is specific case? [note I'm talking from an enterprise/edge network perspective
> here, not from a transit network perspective]

Lets take the current situation at .org. A DNSKEY query for .org results in
a 1342 octet reply.

Currently this is sent as a single IPv6 packet. Depending on whether PMTU
works or not, a system with a 1280 PMTU receives nothing or receives a
fragmented response. And if you drop fragments, then such a system will not
receive any response whether PMTU works or not.

>I hear you. no offense, but I've yet to see those servers not being able to han
>dle an increased amount of TCP based DNS requests coming in. 

I have yet so see any system that consistently sets TC for all responses
bigger than 1280.

However, the DNSKEY query rate for k-root seems to be less than 80 q/s. So that
is quite doable over TCP.


From nobody Fri Feb 12 05:57:19 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14841A0126 for ; Fri, 12 Feb 2016 05:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.602
X-Spam-Level: 
X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MANGLED_BIGGER=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOmi6k2ENSVF for ; Fri, 12 Feb 2016 05:57:15 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956621A011D for ; Fri, 12 Feb 2016 05:57:15 -0800 (PST)
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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 55B763493BB; Fri, 12 Feb 2016 13:57:12 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4D0DC160070; Fri, 12 Feb 2016 13:57:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3D911160071; Fri, 12 Feb 2016 13:57:12 +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 4UDvYdrff2Dn; Fri, 12 Feb 2016 13:57:12 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 81AA1160070; Fri, 12 Feb 2016 13:57:11 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E1F9D421A29D; Sat, 13 Feb 2016 00:57:05 +1100 (EST)
To: Philip Homburg 
From: Mark Andrews 
References:   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org> <20160212113042.GC37655@ernw.de>  <20160212130512.GO37655@ernw.de> 
In-reply-to: Your message of "Fri, 12 Feb 2016 14:34:29 +0100." 
Date: Sat, 13 Feb 2016 00:57:05 +1100
Message-Id: <20160212135705.E1F9D421A29D@rock.dv.isc.org>
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 13:57:18 -0000

In message , Philip Homburg writes:
> In your letter dated Fri, 12 Feb 2016 14:05:12 +0100 you wrote:
> >> This analysis is very much incomplete.
> >> 
> >> For IPv6 you have case 4.5, response is smaller than the local MTU, but bigge
> >r
> >> than PMTU.
> >
> >good point actually, I missed that one. question remains though: how often does
> > that one occur in real-life?
> >read: is it worth to accept v6 fragments into your own network just to avoid th
> >is specific case? [note I'm talking from an enterprise/edge network perspective
> > here, not from a transit network perspective]
> 
> Lets take the current situation at .org. A DNSKEY query for .org results in
> a 1342 octet reply.
> 
> Currently this is sent as a single IPv6 packet. Depending on whether PMTU
> works or not, a system with a 1280 PMTU receives nothing or receives a
> fragmented response. And if you drop fragments, then such a system will not
> receive any response whether PMTU works or not.
> 
> >I hear you. no offense, but I've yet to see those servers not being able to han
> >dle an increased amount of TCP based DNS requests coming in. 
> 
> I have yet so see any system that consistently sets TC for all responses
> bigger than 1280.
> 
> However, the DNSKEY query rate for k-root seems to be less than 80 q/s. So that
> is quite doable over TCP.

Infrastructure servers don't generate big DNSSEC responses. Non
delegation, positive answers get big responses.  DNSKEY and DS
responses in named atleast turns on miminal responses.  Prior to
this change DNSKEY and DS responses were much larger.

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Fri Feb 12 05:57:32 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2121A011D for ; Fri, 12 Feb 2016 05:57:30 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY2UFVbFaZvW for ; Fri, 12 Feb 2016 05:57:25 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494101A0143 for ; Fri, 12 Feb 2016 05:57:24 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u1CDvL1x061450 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2016 13:57:22 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local
Message-ID: <56BDE4C0.5070707@foobar.org>
Date: Fri, 12 Feb 2016 13:57:20 +0000
From: Nick Hilliard 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Philip Homburg 
References:   <20160210122929.GM58491@Space.Net> <2E7E7FF8-D15D-4541-9BD0-4DC8E97FAA42@employees.org>   <20160212004747.DEF1F4201F9E@rock.dv.isc.org> <56BDC177.9050508@foobar.org> <20160212113042.GC37655@ernw.de>  <20160212130512.GO37655@ernw.de> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 13:57:30 -0000

Philip Homburg wrote:
> However, the DNSKEY query rate for k-root seems to be less than 80 q/s. So that
> is quite doable over TCP.

this is o/t for v6ops, but how does failover to +vc and then subsequent
tcp query affect query latency?

Nick


From nobody Fri Feb 12 09:19:12 2016
Return-Path: 
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9011F1A7017; Fri, 12 Feb 2016 09:19:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160212171911.30069.45855.idtracker@ietfa.amsl.com>
Date: Fri, 12 Feb 2016 09:19:11 -0800
Archived-At: 
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 17:19:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Host address availability recommendations
        Authors         : Lorenzo Colitti
                          Vint Cerf
                          Stuart Cheshire
                          David Schinazi
	Filename        : draft-ietf-v6ops-host-addr-availability-05.txt
	Pages           : 14
	Date            : 2016-02-12

Abstract:
   This document recommends that networks provide general-purpose end
   hosts with multiple global IPv6 addresses when they attach, and
   describes the benefits of and the options for doing so.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-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 Fri Feb 12 09:25:44 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB151A854C for ; Fri, 12 Feb 2016 09:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSZBzjnsEURS for ; Fri, 12 Feb 2016 09:25:40 -0800 (PST)
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 2E01C1A8034 for ; Fri, 12 Feb 2016 09:25:40 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id q190so69850620ywd.3 for ; Fri, 12 Feb 2016 09:25:40 -0800 (PST)
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 :content-type; bh=iVSMdB3W8CthQ3TS6Rmu/RENSMKDYm33BuT8JOZR0c0=; b=HwBveprUzHUJcUPm2Mk2yukeu8c/WKEOwR1zW2O22IAc+tuHbCSvL6BtwB1dlSUNgV N4WgEEF+9aqqKABbGUVe28KCdQjRj3xubbvSQSU7WN/qnqCyyqHmhrX7XNmvBlFOeD14 kQcVrwXRKirhRrKN+DJvy+hRrBc9/qs02+i/junPJj+Gqm4sQ8ZUU7iJnQGiGzcMRMUU sJkjI3ncTOaQZJasZVI2bqHvHxi7rnXHoz6b36LdaI/2Qxdon9/iUUsUtP8U61fHyzH3 a8l3rQj06UFmBWDxbLNkbbkR/bcC/KdJ4a/Bwssav7YJv69kbxMUL2ISNzcohnposM5V pZaA==
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:content-type; bh=iVSMdB3W8CthQ3TS6Rmu/RENSMKDYm33BuT8JOZR0c0=; b=iYBaFpJa41migSYMNJSxHMmJf/nQcNaJOgg7us4axXVEdINEIKUFsJlt88Jw9EayNd kHgqRdqdk58gBKziOxEzOStz3Y8deVAXErNyGNZwOVhIFEq37F0AAGZHS6aT6a7DY5n/ ffeqC39uIWFKaKDJXy6oJGwczEVV4eJlmdrZ963oBpvqFNH1RC9wvgTD9QvOzZgrXAjY JjREUTPh0pGHA5M1YBtU3pDlZEuQZQqGUlq3tmumwTAKBFJZ12xwZHF7tvdg4LqG9lhn e4X/el9Z0q4KAGE8y/rpp3NHFEW/LtTDcpAm+s9Ud8lZ6J/YNHak0xZfK/zFQYDPtJId RRoQ==
X-Gm-Message-State: AG10YOReE3wcW1Tv+lUDEgtVYnkwIN6PW8d4likYN25N5uJGLz6IXEVAls97suHmAWkJOygLQJwzxPs3Q3GYkSMZ
X-Received: by 10.13.202.16 with SMTP id m16mr1667137ywd.160.1455297939320; Fri, 12 Feb 2016 09:25:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.13.204 with HTTP; Fri, 12 Feb 2016 09:25:19 -0800 (PST)
In-Reply-To: <20160212171911.30069.45855.idtracker@ietfa.amsl.com>
References: <20160212171911.30069.45855.idtracker@ietfa.amsl.com>
From: Lorenzo Colitti 
Date: Fri, 12 Feb 2016 18:25:19 +0100
Message-ID: 
To: "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary=001a114f00fab7a7ad052b95f4e5
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 17:25:41 -0000

--001a114f00fab7a7ad052b95f4e5
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 12, 2016 at 6:19 PM,  wrote:

>         Title           : Host address availability recommendations
>         Authors         : Lorenzo Colitti
>                           Vint Cerf
>                           Stuart Cheshire
>                           David Schinazi
>         Filename        : draft-ietf-v6ops-host-addr-availability-05.txt
>

New in this version:

   1. Placed much less emphasis on DHCPv6 PD. It was never the intention to
   recommend DHCPv6 PD only; the intention was to recommend address
   provisioning mechanisms that provide plenty of addresses (e.g., by
   providing a prefix). However, some WG participants believed that that was
   the intent. The draft now recommends either "methods that allow the host to
   obtain more addresses autonomously" or a dedicated /64 per host, where the
   dedicated /64 per host can be obtained in several ways.
   2. Mention SLAAC with a dedicated /64 for every host as a way of
   providing plenty of addresses via SLAAC with simpler tracking than shared
   SLAAC.
   3. Slightly reworded the section on address tracking.

Cheers,
Lorenzo

--001a114f00fab7a7ad052b95f4e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Feb 12, 2016 at 6:19 PM,  <internet-drafts@ietf.org> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ti=
tle=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Host address availability rec=
ommendations

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Lore=
nzo Colitti

=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 Vint Cerf

=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 Stuart Cheshire

=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 David Schinazi

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-v6ops-host-addr-availability-05.txt

N=
ew in this version:
  1. Placed much less emphasis on DHCPv6 P=
D. It was never the intention to recommend DHCPv6 PD only; the intention wa=
s to recommend address provisioning mechanisms that provide plenty of addre=
sses (e.g., by providing a prefix). However, some WG participants believed =
that that was the intent. The draft now recommends either "methods tha=
t allow the host to obtain more addresses autonomously" or a dedicated=
 /64 per host, where the dedicated /64 per host can be obtained in several =
ways.
  2. Mention SLAAC with a dedicated /64 for every host as a way of=
 providing plenty of addresses via SLAAC with simpler tracking than shared =
SLAAC.=C2=A0
  3. Slightly reworded the section on address tracking.
Cheers,
Lorenzo


--001a114f00fab7a7ad052b95f4e5--


From nobody Fri Feb 12 10:46:37 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A381D1A8874 for ; Fri, 12 Feb 2016 10:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk7r1YN3ubJN for ; Fri, 12 Feb 2016 10:46:34 -0800 (PST)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 205551A8871 for ; Fri, 12 Feb 2016 10:46:34 -0800 (PST)
Received: by mail-pa0-x22b.google.com with SMTP id yy13so50560309pab.3 for ; Fri, 12 Feb 2016 10:46:34 -0800 (PST)
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-type:content-transfer-encoding; bh=T2Trc59i8nbnapMJdYksKBx2TjqZRN+RKtR0z7oPtyI=; b=Y87COB8eztlaO9Tg+7BJkj4aHHlXPcCwTUwmXoqA5Sri36LjpQfPfNxSSc5bwWHTqX 3Iyc2PC0k3AMpRViFW/cl3VzDjF82Mbw3gSpNDPqU1OqDELcpRyCcreVrxz5+QDUESnx j/XrmAwp/AlynT9RMV1QSNyVB3s2NS8Oc9huFzqIVHhG7R7S8MzC3fcWu9Ui2GI/sqsy o7OG02BBbiD9EX0dFUiVEGiVqaC2HpYBxBo8LhbhQjQ28rmM+89AZd/9IkJ2Hn1x6xxr IXUGbXy9DeRfUmypD+D4vqvlw+w1+h1bdMKsKjho7wOccnm3zjQAC0LRTY/wVbjYT5qE hIBw==
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-type :content-transfer-encoding; bh=T2Trc59i8nbnapMJdYksKBx2TjqZRN+RKtR0z7oPtyI=; b=Yt6CSeeFkkQMg2N435XcNumTP1cfCLazcj2fRjXNmmbP6fuXeUOQL+N5JCyKw6FNMW twQ/JdlRs1cODFEfWYX267NX3DG2H56URq4SybYePa2aa8TvuQ4I8UiPPqAQhIKvfdQ/ V4P1HzV/8yjweWaCHBHjC6UZYEZpHh8Oyf3MmCjw4tk7tEXLEnh4aa1PnZKm4pkjexS6 3sFU5Hu432zjFU6BQiV+MjYlrgcwlmoBPBC8q9pH7/dzct0fnV8iLBF3Ywh7Yh5V149U doti8TPBZzCqW3VERUL7zsAtPD5ybNG89XF7pVxFoZqxYE/jvjSF1MeIOx7Rcb2OsGf0 YoJA==
X-Gm-Message-State: AG10YOTKbF/sHj+mxs5TDkE3X9iU/ZqRQJLv+rBzwGHrFfIImny8q2etGm27BS84Q0Potg==
X-Received: by 10.66.226.238 with SMTP id rv14mr4320062pac.41.1455302793294; Fri, 12 Feb 2016 10:46:33 -0800 (PST)
Received: from ?IPv6:2406:e007:7084:1:28cc:dc4c:9703:6781? ([2406:e007:7084:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id dg12sm21084588pac.47.2016.02.12.10.46.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 10:46:31 -0800 (PST)
To: Lorenzo Colitti , "v6ops@ietf.org WG" 
References: <20160212171911.30069.45855.idtracker@ietfa.amsl.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56BE2891.3030507@gmail.com>
Date: Sat, 13 Feb 2016 07:46:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 18:46:35 -0000

On 13/02/2016 06:25, Lorenzo Colitti wrote:
> On Fri, Feb 12, 2016 at 6:19 PM,  wrote:
> 
>>         Title           : Host address availability recommendations
>>         Authors         : Lorenzo Colitti
>>                           Vint Cerf
>>                           Stuart Cheshire
>>                           David Schinazi
>>         Filename        : draft-ietf-v6ops-host-addr-availability-05.txt
>>
> 
> New in this version:
> 
>    1. Placed much less emphasis on DHCPv6 PD. It was never the intention to
>    recommend DHCPv6 PD only; 

And don't overlook that draft-ietf-dhc-anonymity-profile is in IETF Last Call
for another 2 days, including a strong recommendation against using IA_PD.

   Brian

>    the intention was to recommend address
>    provisioning mechanisms that provide plenty of addresses (e.g., by
>    providing a prefix). However, some WG participants believed that that was
>    the intent. The draft now recommends either "methods that allow the host to
>    obtain more addresses autonomously" or a dedicated /64 per host, where the
>    dedicated /64 per host can be obtained in several ways.
>    2. Mention SLAAC with a dedicated /64 for every host as a way of
>    providing plenty of addresses via SLAAC with simpler tracking than shared
>    SLAAC.
>    3. Slightly reworded the section on address tracking.
> 
> Cheers,
> Lorenzo
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Fri Feb 12 10:55:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9311A88B2 for ; Fri, 12 Feb 2016 10:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeJT8TXyU34c for ; Fri, 12 Feb 2016 10:55:30 -0800 (PST)
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 9BA471A88B1 for ; Fri, 12 Feb 2016 10:55:30 -0800 (PST)
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 u1CItUhQ028989; Fri, 12 Feb 2016 11:55:30 -0700
Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1CItNZB028927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Feb 2016 11:55:24 -0700
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.70]) with mapi id 14.03.0235.001; Fri, 12 Feb 2016 10:55:22 -0800
From: "Templin, Fred L" 
To: Brian E Carpenter , Lorenzo Colitti , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
Thread-Index: AQHRZcW/1/5rsRiFUEynjmtludIw2Z8owQag
Date: Fri, 12 Feb 2016 18:55:22 +0000
Message-ID: <2134F8430051B64F815C691A62D9831833967743@XCH-BLV-105.nw.nos.boeing.com>
References: <20160212171911.30069.45855.idtracker@ietfa.amsl.com>  <56BE2891.3030507@gmail.com>
In-Reply-To: <56BE2891.3030507@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Feb 2016 18:55:32 -0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente=
r
> Sent: Friday, February 12, 2016 10:47 AM
> To: Lorenzo Colitti; v6ops@ietf.org WG
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-=
05.txt
>=20
> On 13/02/2016 06:25, Lorenzo Colitti wrote:
> > On Fri, Feb 12, 2016 at 6:19 PM,  wrote:
> >
> >>         Title           : Host address availability recommendations
> >>         Authors         : Lorenzo Colitti
> >>                           Vint Cerf
> >>                           Stuart Cheshire
> >>                           David Schinazi
> >>         Filename        : draft-ietf-v6ops-host-addr-availability-05.t=
xt
> >>
> >
> > New in this version:
> >
> >    1. Placed much less emphasis on DHCPv6 PD. It was never the intentio=
n to
> >    recommend DHCPv6 PD only;
>=20
> And don't overlook that draft-ietf-dhc-anonymity-profile is in IETF Last =
Call
> for another 2 days, including a strong recommendation against using IA_PD=
.

The abstract says:

   "Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  The anonymity profile is designed for clients
   that wish to remain anonymous to the visited network."

So, it appears to be only about clients that wish to remain anonymous.
But, in certain use cases (airplanes under air traffic control, enterprise
mobile device users, etc.) device tracking is very important. and IA_PD
is applicable.

Thanks - Fred
fred.l.templin@boeing.com

>    Brian
>=20
> >    the intention was to recommend address
> >    provisioning mechanisms that provide plenty of addresses (e.g., by
> >    providing a prefix). However, some WG participants believed that tha=
t was
> >    the intent. The draft now recommends either "methods that allow the =
host to
> >    obtain more addresses autonomously" or a dedicated /64 per host, whe=
re the
> >    dedicated /64 per host can be obtained in several ways.
> >    2. Mention SLAAC with a dedicated /64 for every host as a way of
> >    providing plenty of addresses via SLAAC with simpler tracking than s=
hared
> >    SLAAC.
> >    3. Slightly reworded the section on address tracking.
> >
> > Cheers,
> > Lorenzo
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



From nobody Fri Feb 12 21:22:23 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD061B2C89 for ; Fri, 12 Feb 2016 21:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPoldUD90rJt for ; Fri, 12 Feb 2016 21:22:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C051B2C7B for ; Fri, 12 Feb 2016 21:22:20 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIL43933; Sat, 13 Feb 2016 05:22:17 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 13 Feb 2016 05:22:16 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Sat, 13 Feb 2016 13:22:10 +0800
From: "Liubing (Leo)" 
To: "v6ops@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt
Thread-Index: AQHRYL6V88lt2jFsvUCH3UKatzluW58pexCw
Date: Sat, 13 Feb 2016 05:22:09 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D43689@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.46.194.190]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56BEBD8A.0046, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1706b8398ed15caed7621084e6b92adf
Archived-At: 
Subject: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Feb 2016 05:22:22 -0000

SGkgRGVhciBhbGwsDQoNClRoaXMgaXMgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIFdlIG1h
ZGUgbm90IGEgZmV3IHJldmlzaW9uIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5LCBidXQgdGhl
cmUncyBubyBlc3NlbnRpYWwgdGVjaG5pY2FsIGNoYW5nZS4NCkNvbW1lbnRzIGFyZSBhcHByZWNp
YXRlZC4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N
CuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNuW5tDLmnIg25pelIDE3OjEzDQrmlLbk
u7bkuro6IExpdWJpbmcgKExlbyk7IFNoZW5nIEppYW5nOyBYaWFuZ3lhbmcgR29uZzsgV2VuZG9u
ZyBXYW5nOyBFbm5vIFJleQ0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDYudHh0DQoNCg0KQSBuZXcgdmVy
c2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDYudHh0
DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQg
dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2
LXNsYWFjLXByb2JsZW0NClJldmlzaW9uOgkwNg0KVGl0bGU6CQlESENQdjYvU0xBQUMgSW50ZXJh
Y3Rpb24gUHJvYmxlbXMgb24gQWRkcmVzcyBhbmQgRE5TIENvbmZpZ3VyYXRpb24NCkRvY3VtZW50
IGRhdGU6CTIwMTYtMDItMDUNCkdyb3VwOgkJdjZvcHMNClBhZ2VzOgkJMjMNClVSTDogICAgICAg
ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi12Nm9w
cy1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wNi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9i
bGVtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTA2DQpEaWZmOiAgICAgICAgICAgaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFj
LXByb2JsZW0tMDYNCg0KQWJzdHJhY3Q6DQogICBUaGUgSVB2NiBOZWlnaGJvciBEaXNjb3Zlcnkg
KE5EKSBQcm90b2NvbCBpbmNsdWRlcyBhbiBJQ01QdjYgUm91dGVyDQogICBBZHZlcnRpc2VtZW50
IChSQSkgbWVzc2FnZS4gIFRoZSBSQSBtZXNzYWdlIGNvbnRhaW5zIHRocmVlIGZsYWdzLA0KICAg
aW5kaWNhdGluZyB0aGUgYXZhaWxhYmlsaXR5IG9mIGFkZHJlc3MgYXV0by1jb25maWd1cmF0aW9u
IG1lY2hhbmlzbXMNCiAgIGFuZCBvdGhlciBjb25maWd1cmF0aW9uIHN1Y2ggYXMgRE5TLXJlbGF0
ZWQgY29uZmlndXJhdGlvbi4gIFRoZXNlIGFyZQ0KICAgdGhlIE0sIE8sIGFuZCBBIGZsYWdzLCB3
aGljaCBieSBkZWZpbml0aW9uIGFyZSBhZHZpc29yeSwgbm90DQogICBwcmVzY3JpcHRpdmUuDQoN
CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGRpdmVyZ2VudCBob3N0IGJlaGF2aW9ycyBvYnNl
cnZlZCBpbiBwb3B1bGFyDQogICBvcGVyYXRpbmcgc3lzdGVtcy4gIEl0IGFsc28gZGlzY3Vzc2Vz
IG9wZXJhdGlvbmFsIHByb2JsZW1zIHRoYXQgdGhlDQogICBkaXZlcmdlbnQgYmVoYXZpb3JzIG1p
Z2h0IGNhdXNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg
dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi
bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl
IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Fri Feb 12 23:56:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC161B2E38 for ; Fri, 12 Feb 2016 23:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkhC0Iik7XP1 for ; Fri, 12 Feb 2016 23:56:23 -0800 (PST)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002: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 188DD1B2E37 for ; Fri, 12 Feb 2016 23:56:23 -0800 (PST)
Received: by mail-yk0-x230.google.com with SMTP id z13so43173771ykd.0 for ; Fri, 12 Feb 2016 23:56:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HDMPvuTFy9Do8nXkDMZaIb7w0eAi5EFsIRguP3pb+1U=; b=mIIbLB2veyBZfr8UxMuq5ZlS28rPR9ecBtiVl2+9HNUo5S6TLj0fWqfm9K/Li2nykm gWDB+4y61LSHsvhqxuRdox8QNBvlMYVh24TfC+YChItJs2r43jBd9TSFHgF0U1OpqBDN +yxnbxEKD+82MHgn8XDfFUJuUysc1epyydN3qB3QbbrfH2ziG5dL51icZ6i65hG4I1SQ V4hJIBOzGie3bjJ9rnfaTynFWMptdZ593v+o9mZb6FXXEmkL9AuoYyJoMfKcuxn1JFqp 6cpkng+RAo5va8jYeZM1qMRJHzb7ddKPEbVIOcMQdiCclDGu8L1yc7d5E8wCnJ1Y1gO5 czYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HDMPvuTFy9Do8nXkDMZaIb7w0eAi5EFsIRguP3pb+1U=; b=SE0YJHxFtGbGqttkRd/QeQ21+gYsW1tYJnST88e5x6KXBCboDmqydyJDyVe0DTC/cx MR+VoqdhZInNAE1mq2Gngr/jxLd9B0Ytnjs0YpXmgPj7HTGeJPPvqsAeQgen4HDehj2i d/ZUeJcUbVkotmSvk/y+Bt7egOGaKI4o/pknMVxJo1Vg4kQXQ4U8J+a3nsczJZOv5Jfo 5ZZkHhzWRK//r45kU0ZU3NBI6NyNvVw7GzYq7ZJV7Shi5Ax2HKGV9tMht4n1e05GScJW ePKJoIFtdbTYWlkjJ7IxSQFvcKZ+LrP8pZgjoZSbR7dg3/gXx+gup44OrnYwQ5VnjTf5 ou4g==
X-Gm-Message-State: AG10YOR4mSWymy8JBr5HS/q1CudUW1ECFHDJoln8EGtyrU+hChxJ9+0bsiVABLA9WojDe3cmnrmv0UpM5E6eGCUO
X-Received: by 10.37.44.69 with SMTP id s66mr3558293ybs.25.1455350182257; Fri, 12 Feb 2016 23:56:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.13.204 with HTTP; Fri, 12 Feb 2016 23:56:02 -0800 (PST)
In-Reply-To: <56BE2891.3030507@gmail.com>
References: <20160212171911.30069.45855.idtracker@ietfa.amsl.com>  <56BE2891.3030507@gmail.com>
From: Lorenzo Colitti 
Date: Sat, 13 Feb 2016 08:56:02 +0100
Message-ID: 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=001a11432108a3b404052ba21e4e
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Feb 2016 07:56:24 -0000

--001a11432108a3b404052ba21e4e
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 12, 2016 at 7:46 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> >    1. Placed much less emphasis on DHCPv6 PD. It was never the intention
> to
> >    recommend DHCPv6 PD only;
>
> And don't overlook that draft-ietf-dhc-anonymity-profile is in IETF Last
> Call
> for another 2 days, including a strong recommendation against using IA_PD.
>

Thanks for pointing that out (twice now). I commented on that thread. It
seems spurious to recommend against DHCPv6 PD since its anonymity
properties are basically the same as IA_NA.

--001a11432108a3b404052ba21e4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Feb 12, 2016 at 7:46 PM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
>=C2=
=A0 =C2=A0 1. Placed much less emphasis on DHCPv6 PD. It was never the inte=
ntion to

>=C2=A0 =C2=A0 recommend DHCPv6 PD only;



And don't overlook that draft-ietf-dhc-anonymity-profile is in IETF Las=
t Call

for another 2 days, including a strong recommendation against using IA_PD.<=
br>

Thanks for pointing that out (twice now=
). I commented on that thread. It seems spurious to recommend against DHCPv=
6 PD since its anonymity properties are basically the same as IA_NA.=C2=A0<=
/div>


--001a11432108a3b404052ba21e4e--


From nobody Sun Feb 14 11:00:11 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F011B2BF3 for ; Sun, 14 Feb 2016 11:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.807
X-Spam-Level: 
X-Spam-Status: No, score=-111.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9z7TtA0E9ZI for ; Sun, 14 Feb 2016 11:00:09 -0800 (PST)
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 F2F2B1B2BF0 for ; Sun, 14 Feb 2016 11:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1455476408; x=1456686008; h=date:from:message-id:to:subject; bh=Yz8NEECswLFDJryGVGwJNm7tqgNkkoloIHdlWsMOJjI=; b=hUhPy+eAWYeLrQpX12k3WsOIYL0VSWaz0Uwe8rSpIB+BCrbTO9UsjxxJ jaRqlWFJv3Y3t8wTWc2J9u2dbz5uUxLy09rGsP5wIA1uSfqihNbGcI62c zsw8L5YW+A9WsuSnyMxHsRVaJGQD0un+dKQLIOjzZxYRCkyZNiTKBv69i g=;
X-IronPort-AV: E=Sophos;i="5.22,446,1449532800"; d="scan'208";a="236887022"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2016 19:00:08 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1EJ07i1008902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2016 19:00:08 GMT
Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u1EJ07o3020466; Sun, 14 Feb 2016 11:00:07 -0800
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u1EJ076S020463; Sun, 14 Feb 2016 11:00:07 -0800
Date: Sun, 14 Feb 2016 11:00:07 -0800
From: fred@cisco.com
Message-Id: <201602141900.u1EJ076S020463@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] Focused Discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 14 Feb 2016 19:00:10 -0000

One more document to discuss in a focused way:
draft-ietf-v6ops-unique-ipv6-prefix-per-host.  Could we please read that
and comment to the list?


From nobody Mon Feb 15 16:21:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40C81A1A5A for ; Mon, 15 Feb 2016 16:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbdQxKUdAqDN for ; Mon, 15 Feb 2016 16:21:30 -0800 (PST)
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 6CE491A03F9 for ; Mon, 15 Feb 2016 16:21:30 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id q63so94599785pfb.0 for ; Mon, 15 Feb 2016 16:21:30 -0800 (PST)
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-type :content-transfer-encoding; bh=2R9fFpwf/e7/dcp/j7B+vNSVAepudgCKVPnTp+jzUYM=; b=jAICCN1buitAPKU5Kjv7gFKbYNw+PnKouv9K1rOlS4EJHEZjz7sxYjJQggkuZV3AbD BEXI20BEXgvgVtzQjpWUdI69ElUaFu3fhvZz5ybHBGE+jnMXM/ClXgUorO32pCGeBRj5 ZJ4q1ktKJS9hwhBen/xP03sXLG44Pv5D7s0mruKPbkCiM6PrVoUlEtyjLhHD/UAPx3Si fkJ0QFo0r2PewQ8J8OoqJQeP7oXtt0Kw+38VV0mtSQqV/o12iR08iTmzMcGoiY4bMLLz zgPxRc4hMD/PLFcNC6W6Q6fFCoPkFmf37OlOEKQrwaOzpynUAD5qI7E/PqXG7nKXe09x SZVw==
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-type :content-transfer-encoding; bh=2R9fFpwf/e7/dcp/j7B+vNSVAepudgCKVPnTp+jzUYM=; b=EYCf8JKQjPg6/11++pxYZk0AlVu08tZfqlrvFP3m9UM4zAU8QI6WkMzKGHQCji4Ck9 xQOx1Hp3OKq6MaWGB3ndbA5nmNl9cwZubBzE2eiW5vHZuUkXkgxcWEbkPM8p3EFxZB7Q 5SkTZ+alXA6uawG/yjR14H5qRy8UseFD4m7pE+dNG/LV2Ai4vi6rZgILfon/VU3+3sOg M52FAu8+wC8edSLeMYx3EdXOJto6lYnE1LHrDTmzIQakBCp33wrtWOLWs5NcI3+kpiLQ XCoQ6oaPYurhHP2dUruO/MIWCAiuJR4b2D2zZbluyFSOZDQdFOFfkVs7bYeDrKNK0fQK ND2A==
X-Gm-Message-State: AG10YORRoMP7kTjAqQC40ntfeyqP0KL9AFedT93B1DWOsJpNXsvvpBBXhjnWswLxjei9uA==
X-Received: by 10.98.89.215 with SMTP id k84mr27351030pfj.66.1455582090130; Mon, 15 Feb 2016 16:21:30 -0800 (PST)
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 27sm41005047pfh.48.2016.02.15.16.21.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 16:21:28 -0800 (PST)
To: Tim Chown 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C26B89.3020304@gmail.com>
Date: Tue, 16 Feb 2016 13:21:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 00:21:31 -0000

On 12/02/2016 19:59, Tim Chown wrote:
...
>> Exactly. And we should include a very strong warning against manually
>> assigning a human-friendly prefix.
> 
> Definitely. Even if we know what's likely to happen in practice. And if you are manually picking a ULA /48 at least don't do all zeros - even using some bits of your global /48 in the ULA prefix is better than that.

Specifically, I believe that the following paragraph of the draft,
in section 4.1, is dangerous:

o Prefix generation: randomly generated according to the algorithms
  defined in [RFC4193] or manually assigned.  Normally, automatic
  generation of the prefixes is recommended, following [RFC4193].
  If there are some specific reasons that call for manual
  assignment, administrators have to plan the prefixes carefully to
  avoid collision.

I believe we should not even suggest that it might be OK to allocate
manually. This draft isn't a BCP so we can use normal English, for
example:

o Prefix generation: prefixes must be randomly generated according
  to the algorithms defined in [RFC4193]. There are on-line tools
  available to do this interactively, if not performed automatically
  by the CPE. Manual assignment of easy-to-remember prefixes must
  never be done because of the high risk of collision, recreating
  the problems of [RFC1918].

   Brian


From nobody Mon Feb 15 16:37:27 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8082C1A888F for ; Mon, 15 Feb 2016 16:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zvuWBD8two3 for ; Mon, 15 Feb 2016 16:37:25 -0800 (PST)
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 67D951A888E for ; Mon, 15 Feb 2016 16:37:25 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id x65so94850633pfb.1 for ; Mon, 15 Feb 2016 16:37:25 -0800 (PST)
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-type:content-transfer-encoding; bh=FdO7kPNVveSrxehOG51Tg5gsw34Cm9ZeD5ogAUyxhVU=; b=X3nsQc75WDO5SzV6Xd+wLjDvDrwfQHV/YaXP9O1n3FfGQvg79gSKMzwiBbNsjBE6Dl KqusIIblxoa+nBA7oWSAMT5futE4DgL+fAj9AoGzDp1r/MEQvJF4QAOkNMs1LRpZvZLt o7ONX/IfWSkPjGkzfEygwJU5oqRh/ya1wyNy6MygfreHkilt2IsjTAhiHyfP/SvVJp5f kfQIo6zO0NJsjXGlmIL30NX4Y3MxM3pbNy2DPeIkotIWH0EajaQRUUsF1wnqaI+hFPCs dDYySwbYC4PbAkwj+EiCDTEt5b9KhI8QabuHXGr1CAcB68YANPJN117wSpEzQM96lTOg ndoQ==
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-type :content-transfer-encoding; bh=FdO7kPNVveSrxehOG51Tg5gsw34Cm9ZeD5ogAUyxhVU=; b=fUonqfzfXwrC4jhQulN6fLPSM7JIS5wizu28noE9/FicPrDO51YAfVVBEGOTFPVuUN VQIqUQzpCdUcyPUkPwQePeiKJSL25ll2GS82ccOyjqPVynWDYvohvkvM6WpHpNyWaUkx Hxog2UjA+mjhPh2H4qYo+efDuDqhd+uWCExyQgpj5R+4jxiCwbPweoi2OzALpQBVgRkM t8vOJtKTaK8a9KPvgb3iEOv0fveQJwB4W4F57BXDG2P+CMXx6W8dQHW7l6dkayHzD4WO utYjKk1M8E673yfWhdPGYa/Zc5d99+2ygZc8Kw2XcnZV2Mppm0qOp5UJ3is2kL3ajVAq 2DgQ==
X-Gm-Message-State: AG10YOTDBjRnbFcL9QDhG2YDvFCX1l2ixZf9B7cj8w3LuixGfVFL3EorAxLwa8QsCV1NSQ==
X-Received: by 10.98.69.1 with SMTP id s1mr5542546pfa.120.1455583045130; Mon, 15 Feb 2016 16:37:25 -0800 (PST)
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 lq10sm41122340pab.36.2016.02.15.16.37.23 for  (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 16:37:24 -0800 (PST)
To: v6ops@ietf.org
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C26F44.6000107@gmail.com>
Date: Tue, 16 Feb 2016 13:37:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 00:37:26 -0000

Hi,

I have some comments on section 4.2. "Connected Networks".

1) I think the sub-section "ULAs along with PA Addresses"
should come first because it is the preferred model.

2) The sub-section "ULA-Only Deployment" starts by implying
that this might be a good idea. I suggest rewriting the
first sentence to make it sound like a doubtful idea:

 Operators of a network might be tempted to assign ULAs but not
 Global Unicast Addresses (GUAs), although the nodes also need to
 communicate with the outside network. There are two ways this
 might work:

3) I think the following bullets are in the wrong order.
I suggest putting "Using Application-Layer Proxies" first
(because it may be a decent solution in some security models)
and "Using Network Prefix Translation (NPTv6)" second (because
it is controversial, as discussed in the third bullet).

Regards
   Brian


From nobody Mon Feb 15 17:09:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210C01B30DB for ; Mon, 15 Feb 2016 17:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnYTMwoqM5U8 for ; Mon, 15 Feb 2016 17:09:13 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 0926F1B30DA for ; Mon, 15 Feb 2016 17:09:13 -0800 (PST)
Received: by mail-yk0-x22e.google.com with SMTP id u9so67172504ykd.1 for ; Mon, 15 Feb 2016 17:09:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qZS9SaiJh+G78kGe4XGtIPfRCPbdvFvc7/ZvER91NbI=; b=l3k+mkKak+k3Ao/LP8AOlD5QrgcqOlwr8GEqVdye7rFGf5ERRGLsKtWlBQnJs6KU+m jtLOrCDCgpSxrhgtWFuc18XpMSJeiR0OOC/B/FiRjBIDFMQVhJjJPeCxBugWiMHzjnod Wh1hLKIFFAKtjDInw8zmH8N+aFCRyk/0EXqNIgWVDy6jQ1+OI5cgNT/lVNtExBwiqJTo tx4ZkXOIf+18rge4vETwrjqAsy6lA03wEpdEpluQDdWfm3oj/hlP42o+E6+rH7ZioEEO 6XVrtsiLeJ5GXVTsApuMbu7QDYBMGNRoGr7xyw2Gv5ftyMpwDUMCAqJaaExt5CgDJRkp QBzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qZS9SaiJh+G78kGe4XGtIPfRCPbdvFvc7/ZvER91NbI=; b=AD9phWyxIP3aNl0s45nszroxog4zzbO3gZSg9GHDZK+IuTpFVn8Z7yGMDpr6P+c+j4 y6f0LmsqGox7WeVYXCfR+5tAcpS2L6XYZHie0JxVrnyuhAXfmL7z6JL4cFUB7iFHggLf 74l7hcRwT9N+rBZZD/TedeaIT97o7VOGwD9kM7TPGIrMcOqiZsRPYzTlw5Zx0eJdhnFY SIw8WxoMlP7nVM6iQ9MRoAhg5ngVYDEynuKPz14sE5vIoT47W/sn16DqY4eah6j6QnLP YxiGUGQB5XeltNqi1fBoCXP+Gla/9R3Emf2xU58Bqstnkp2Ea8UbwzM9ofLKUqsynO4v u3Vw==
X-Gm-Message-State: AG10YOR4jgnLXhLJfidqYsGsEiuQNbkdfqmo3K0ZFQ5q9g7C2MD2AI/OZMy/WNInDDfzf9PUcXojy+Jx299L1c5z
X-Received: by 10.37.13.18 with SMTP id 18mr11048872ybn.49.1455584952161; Mon, 15 Feb 2016 17:09:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.55.80 with HTTP; Mon, 15 Feb 2016 17:08:52 -0800 (PST)
In-Reply-To: <56C26F44.6000107@gmail.com>
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26F44.6000107@gmail.com>
From: Lorenzo Colitti 
Date: Tue, 16 Feb 2016 10:08:52 +0900
Message-ID: 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=001a11c0126e04246b052bd8c833
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 01:09:14 -0000

--001a11c0126e04246b052bd8c833
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 9:37 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> 2) The sub-section "ULA-Only Deployment" starts by implying
> that this might be a good idea. I suggest rewriting the
> first sentence to make it sound like a doubtful idea:
>

Wow. How did we end up with this text?

At the microphone in Yokohama there was very strong opposition to ULA-only
deployments using NPTv6. We got comment after comment saying that NPTv6
should be explicitly not recommended. How can we have text in this document
that so explicitly goes against these opinions?

--001a11c0126e04246b052bd8c833
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 16, 2016 at 9:37 AM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
2) The sub-section &q=
uot;ULA-Only Deployment" starts by implying

that this might be a good idea. I suggest rewriting the

first sentence to make it sound like a doubtful idea:
=

Wow. How did we end up with this text?

<=
div>At the microphone in Yokohama there was very strong opposition to ULA-o=
nly deployments using NPTv6. We got comment after comment saying that NPTv6=
 should be explicitly not recommended. How can we have text in this documen=
t that so explicitly goes against these opinions?


--001a11c0126e04246b052bd8c833--


From nobody Mon Feb 15 17:25:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2191AD0C5 for ; Mon, 15 Feb 2016 17:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPMn2IFfzRPk for ; Mon, 15 Feb 2016 17:25:21 -0800 (PST)
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 B49381ACE09 for ; Mon, 15 Feb 2016 17:25:21 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id x65so95448238pfb.1 for ; Mon, 15 Feb 2016 17:25:21 -0800 (PST)
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-type :content-transfer-encoding; bh=uF8euixRRbUvZ40BtiuUXg3sPhjLLZWW0xYwJCFrKqA=; b=iw+Amh7aRcBJrXiosmLdq4wVW2OgkuJl0At9GcnjK2Uumo/MiGZzqAbplPm03YsfMk VKHfFdRCXJYhoaEoKcbkBSavvmJp/To8R3a7fR+LwCiTmd3uucRLgXe5FvKeXxBE7UC4 8YHayj+v06TjyOZd+AkMflspOA0pga7kAMl6P4t62ng03LDbp86ZS83+Q8rmbvlQwDiW /heizDv+LlvzM+X3ex7n9Vw24tAd9DBg41UWT3od5VIv6D+bMrPm+pZAOCqw/Gx/iszO TP8ABhX5h6jEJHMogsyddduSFA3i05n2FwqV5NAQf51TJaVDG8BBmZ32cuGtoWxILD38 1ZKw==
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-type :content-transfer-encoding; bh=uF8euixRRbUvZ40BtiuUXg3sPhjLLZWW0xYwJCFrKqA=; b=FZEPasQw1VLkbO55EaAIVLcuUNWkNNnJnB1dR4EbbmGY7G0+6OJG5roDyAbC5/MyS1 zMXFRUpo1q4Jg5opqyYUWuXZ/AKJMjEnU052axXpWP1H60OArXIenweaYsh/bmG750gE AHsBBUZ7NldcvbMaLgQGnVxGiX5h5w0L/yXfyRuAWgWQDBKZCExxs6v+OkBQFP+GL+QE g8EkOmrJmQlyWWA7nx8ioYR5kSbI8Mgsx6dHxuNMnBRTXFJKo07sgAJZONv18MHmsm6A IT2TAF0svIVYc4ruvgEjSBcYTJWcLYgkgws+dHGkWosSrFXbt9yUw7lZeyi7kBCSNNg3 oWZg==
X-Gm-Message-State: AG10YOTxFfqioOD6AMZg9OjuXq81iz4IvtwIqLu82PDbicg9AuZOBOD54pqgEkYDPA4JvQ==
X-Received: by 10.98.12.221 with SMTP id 90mr27589126pfm.95.1455585921296; Mon, 15 Feb 2016 17:25:21 -0800 (PST)
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 r87sm41167913pfa.61.2016.02.15.17.25.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 17:25:19 -0800 (PST)
To: Lorenzo Colitti 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26F44.6000107@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C27A7F.6000207@gmail.com>
Date: Tue, 16 Feb 2016 14:25:19 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 01:25:23 -0000

On 16/02/2016 14:08, Lorenzo Colitti wrote:
> On Tue, Feb 16, 2016 at 9:37 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> 2) The sub-section "ULA-Only Deployment" starts by implying
>> that this might be a good idea. I suggest rewriting the
>> first sentence to make it sound like a doubtful idea:
>>
> 
> Wow. How did we end up with this text?
> 
> At the microphone in Yokohama there was very strong opposition to ULA-only
> deployments using NPTv6. We got comment after comment saying that NPTv6
> should be explicitly not recommended. How can we have text in this document
> that so explicitly goes against these opinions?

Well, to be fair that section of the document also covers app-level proxies,
so the introduction has to cover that as well as NPTv6. But yes, if I'd been
in Yokohama I would have said the same as you.

   Brian


From nobody Mon Feb 15 18:29:57 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5711B3285 for ; Mon, 15 Feb 2016 18:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un3aYV4wMnxG for ; Mon, 15 Feb 2016 18:29:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C58F1B3275 for ; Mon, 15 Feb 2016 18:29:53 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEJ80067; Tue, 16 Feb 2016 02:29:50 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 02:29:49 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Tue, 16 Feb 2016 10:29:45 +0800
From: "Liubing (Leo)" 
To: "Fred Baker (fred)" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt
Thread-Index: AQHRYopTsiSSfxec4kSDLduSs/jiR58t+ssg
Date: Tue, 16 Feb 2016 02:29:45 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D44078@nkgeml514-mbx.china.huawei.com>
References: <20160208154835.5886.17242.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56C2899E.00D7, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 89eafe210dbdf577dce726043dbe83a9
Archived-At: 
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 02:29:55 -0000

Hi Fred,

Thanks for informing the new version draft. I was having the Chinese New Ye=
ar holidays, so please pardon for my late response.

> Bing is trying to revive the ULA discussion with a draft intended to obje=
ctively
> discuss both sides of the debate we have had in this context. Not arguing=
 pro
> or con, but stating both views ("ULAs are evil and imply NAT" and "ULAs a=
re
> useful in identified cases that don't involve NAT").
[Bing] One little complementary: the "both sides" discuss is mostly for the=
 ULA+NPTv6 scenario. The other content basically remains the same as before=
.

Best regards,
Bing


> Commentary appreciated.
>=20
> > Begin forwarded message:
> >
> > From: internet-drafts@ietf.org
> > Subject: I-D Action: draft-ietf-v6ops-ula-usage-considerations-00.txt
> > Date: February 8, 2016 at 7:48:35 AM PST
> > To: 
> > Cc: v6ops@ietf.org
> > Reply-To: internet-drafts@ietf.org
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the IPv6 Operations of the IETF.
> >
> >        Title           : Considerations For Using Unique Local
> Addresses
> >        Authors         : Bing Liu
> >                          Sheng Jiang
> > 	Filename        : draft-ietf-v6ops-ula-usage-considerations-00.txt
> > 	Pages           : 17
> > 	Date            : 2016-02-06
> >
> > Abstract:
> >   This document provides considerations for using IPv6 Unique Local
> >   Addresses (ULAs).  Based on an analysis of different ULA usage
> >   scenarios, this document identifies use cases where ULA addresses are
> >   helpful as well as potential problems caused by using them,
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerat
> > ions/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-
> > 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.i=
etf.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 Mon Feb 15 23:17:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680F61A90C4 for ; Mon, 15 Feb 2016 23:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVFcNM3T1o1r for ; Mon, 15 Feb 2016 23:17:36 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41A41A9028 for ; Mon, 15 Feb 2016 23:17:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIQ16850; Tue, 16 Feb 2016 07:17:33 +0000 (GMT)
Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 07:17:32 +0000
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 07:17:31 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 16 Feb 2016 15:17:27 +0800
From: "Liubing (Leo)" 
To: Fernando Gont 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
Thread-Index: AQHRZCBf+Tzq2HXT1E+bXAAC0O3fuZ8t+5Cg
Date: Tue, 16 Feb 2016 07:17:27 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D44153@nkgeml514-mbx.china.huawei.com>
References: <56BB639E.5010505@si6networks.com>
In-Reply-To: <56BB639E.5010505@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56C2CD0D.00FE, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a02e8ace60bb23b648c87ad1747c6dee
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:17:40 -0000

Hi Fernando,

Many thanks for your throughout review. And please pardon for my late reply=
 due to my holidays in last week.
My replies are inline.

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: Thursday, February 11, 2016 12:22 AM
> To: draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org
> Cc: IPv6 Operations
> Subject: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
>=20
> Folks,
>=20
> I did a fresh review of the aforementioned I-D. I didn't follow previous
> discussions of this topic, so my apologies if I raise something that has
> already been discussed to death, etc.
>=20
>=20
> ** Technical **
>=20
> * Meta: Both section 4 and section 6 contain use cases. This is rather
> confusing. e.g., not sure what's the criteria to ut some of the use cases=
 in
> Section 4, while others in Section 6. Unless I'm missing something, this
> should be fixed.

[Bing] The original idea was to enumerate all possible use cases in Section=
4, and sort out the beneficial ones into Section6.
I also had concerned a bit on the section4/6 overlapping issue in previous =
versions, your comment made me more tendency to merge them. Let me try it i=
n the next version.

> * Section 3.2: Do folks really generate the prefixes as "required"?
> Me, I confess I've used things like fc00:1::/64 because they are simpler =
that
> some random string of bits.
[Bing] This is a human practical issue, but ULA itself is innocent:)
Section 3 is a summary of the ULA features, I think your consideration coul=
d be included in Section 4.

> * Section 3.4, page 4:
> > Externally-destined data can be sent to the Internet or
> > telecommunication network by a separate function, through an
> > appropriate gateway/firewall.
>=20
> Please remove "firewall". A firewall wouldn't really help with that.
[Bing] Ok, will do.

> * Section 4.1, page 4:
> > IP is used ubiquitously.  Some networks like industrial control bus
> > (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces
> > like [MIL-STD-1397] have begun to use IP.  In these kinds of networks,
> > the system may lack the ability to communicate with the public
> > networks.
>=20
> Not sure what you mean by "may lack the ability...".
[Bing] These industrial networks might not support common Internet services=
/functions such as HTTP, DNS etc., and they might not have the requirement =
to talk to the nodes in the public Internet.

> * Section 4.1, page 5:
> > o  Prefix generation: randomly generated according to the algorithms
> > defined in [RFC4193] or manually assigned.  Normally, automatic
> > generation of the prefixes is recommended, following [RFC4193]. If
> > there are some specific reasons that call for manual assignment,
> > administrators have to plan the prefixes carefully to avoid collision.
>=20
> mm.. what do you mean exactly by "automatic generation"? -- In all those
> systems I have employed, the ULA prefixes are not generated automagically=
.
> -- you need to un the algorithm yourself, which means that the prefix is
> alwas manually configured (in the routers sending the RAs).
[Bing] I think we're talking the same thing. "Automatic generation" means t=
here is a function which aligns with the rules in 4193 in the device/softwa=
re to generate the prefixes. We never assign "random" prefixes by our brain=
s, unless there is no software available.
I'll make it more clearer in the next version.

> * Section 4.1, page 5:
> > o  Prefix announcement: in some cases, networks might need to
> announce
> > prefixes to each other.  For example, in vehicle networks with
> > infrastructure-less settings such as Vehicle-to-Vehicle (V2V)
> > communication, prior knowledge of the respective prefixes is unlikely.
> > Hence, a prefix announcement mechanism is needed to enable
> > inter-vehicle communications based on IP.  As one possibility, such
> > announcements could rely on extensions to the Router Advertisement
> > message of the Neighbor Discovery Protocol (e.g.,
> > [I-D.petrescu-autoconf-ra-based-routing] and [I-D.jhlee-mext-mnpp]).
>=20
> This is not specific to ULAs -- hence I'd remove this para.
[Bing] I'll consider removing it in the next version.

> * Section 4.2.1, page 7:
>=20
> > -  If the firewall is located inside the NPTv6 translator, the
> > filtering is then based on the ULA prefixes, and the rules need to be
> > updated correspondingly.  There is no need to update when the NPTv6
> > GUA prefixes are renumbered.
>=20
> not sure what you mean by "need to be updated"... the whole point of ULAs
> is that you'd not renumber them...
[Bing] This is in case the ULAs are renumbered, the filtering rules need to=
 be updated accordingly. But as you said, normally people just won't renumb=
er the ULAs. I'll modify the texts.

> * Section 4.2.2, page 7:
> >  Note:
> >       ULAs provide more benefit for multiple-segment home networks;
> for
> >       home networks containing only one segment, link-local addresses
> >       are better alternatives.
>=20
> You need to expand and back these claims...
[Bing] Ok, I guess some quoting from Homenet documents might be helpful.

> * Section 4.2.2, page 8:
> >    o  Default Routing: connectivity may be broken if ULAs are used as
> >       default route.  When using RIO (Route Information Option) in
> >       [RFC4191], specific routes can be added without a default route,
> >       thus avoiding bad user experience due to timeouts on ICMPv6
> >       redirects.  This behavior was well documented in [RFC7084] as
> rule
> >       ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
> >       router with a Router Lifetime greater than zero whenever all of
> >       its configured and delegated prefixes are ULA prefixes." and alon=
g
> >       with rule L-3 "An IPv6 CE router MUST advertise itself as a
> > router
> [...]
>=20
> If you have a multi-subnet home network, and the CP doesn't advertise its=
elf
> as a default router (and nodes don't support RFC4191), how do you get
> multi-subnet ULA network to work?
[Bing] Per RFC6434(IPv6 node requirement), =20
   "Small Office/Home Office (SOHO) deployments supported by routers
   adhering to [RFC6204] use RFC 4191 to advertise routes to certain
   local destinations.  Consequently, nodes that will be deployed in
   SOHO environments SHOULD implement RFC 4191."

So, I think we just simply state in the document that for nodes that don't =
support RFC4191, they won't work in the situation as you said. I'll modify =
the texts accordingly.

> * Section 4.2.2, page 9:
> >
> >    o  DNS relevant: if administrators choose not to do reverse DNS
> >       delegation inside of their local control of ULA prefixes, a
> >       significant amount of information about the ULA population may
> >       leak to the outside world.  Because reverse queries will be made
> >       and naturally routed to the global reverse tree, so external
> >       parties will be exposed to the existence of a population of ULA
> >       addresses.  [ULA-IN-WILD] provides more detailed situations on
> >       this issue.  Administrators may need a split DNS to separate the
> >       queries from internal and external for ULA entries and GUA
> >       entries.
>=20
> This text seems to imply that someone will do reverse mappings for ULAs.
> Could you please elaboate a bit on the scenario that you envision?
[Bing] [ULA-IN-WILD] provides more detailed situations on this issue. You c=
an see slide 20, which is an instance of "SMTP Received-Via".
[ULA-IN-WILD] link: http://conference.apnic.net/data/36/apnic-36-ula_137749=
5768.pdf

> * Section 6.3.2, pages 11-12:
> >    But there is an issue needs to be noted.  The NAT64 standard
> >    [RFC6146] specifies that the PREF64 should align with [RFC6052], in
> >    which the IPv4-Embedded IPv6 Address format was specified.  If we
> >    pick a /48 for NAT64, it happens to be a standard 48/ part of ULA
> >    (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID).  Then the
> >    40bit of ULA is not violated by being filled with part of the 32bit
> >    IPv4 address.  This is important, because the 40bit assures the
> >    uniqueness of ULA.  If the prefix is shorter than /48, the 40bit
> >    would be violated, and this could cause conformance issues.  But it
> >    is considered that the most common use case will be a /96 PREF64, or
> >    even /64 will be used.  So it seems this issue is not common in
> >    current practice.
>=20
> (Disclaimer: I haven't read RFC6052 any time lately) The text above is
> confusing to me... maybe you could expand and elaborate a bit more?
[Bing] RFC6052 allows the PREF64 shorter than /48, in which case, the embed=
ded IPv4 address would occupy part of the 40bit GLOBAL ID field as required=
 by RFC4193.
I'll improve the readability in the next version.

> * Section 6.3.3, page 12:
> >    ULAs could be self-generated and easily grabbed from the standard
> >    IPv6 stack.  And ULAs don't need to be changed as the GUA prefixes
> >    do.  So they are very suitable to be used as identifiers by the up
> >    layer applications.  And since ULA is not intended to be globally
> >    routed, it is not harmful to the routing system.
>=20
> Using IP addresses as identifiers in upper layers is a really bad idea.
[Bing] If we merge Section6 into Section4, would you share more opinions of=
 why it's bad to use it as identifier?=20


[Bing] The below editorial issues will be addressed as well. Thanks for you=
r so careful review!

Best regards,
Bing

> ** Editorial **
>=20
> * Abstract:
>=20
> > Based on an analysis of different ULA usage scenarios, this document
> > identifies use cases where ULA addresses are helpful as well as
> > potential problems caused by using them,
>=20
> Replace the trailing comma with a dot.
>=20
> * Page 2, intro:
> > Unique Local Addresses (ULA) is defined in [RFC4193], and it is an
> > alternative to site-local address (deprecated in [RFC3879]).
>=20
> "..are defined in... and they are...."
>=20
> * Section 1, Page 3:
> > Thus, the administrators could choose to use ULAs in a certain way
> > that considered benificial for them.
>=20
> "..that is considered..."
>=20
>=20
> * Section 4.2.1, page 6:
> > The comunity has strong controversies of ULA-only deployment in
> > connected networks.
>=20
> s/controversies/concerns/
>=20
>=20
>=20
> * Section 4.2.1, page 6:
> > For those who are strongly against this usage, the main reason is to
> > avoid breaking the end-to-end transparence.  Because people have
> > suffered from the NAT/Proxy middle boxes so much in the IPv4 ear
>=20
> s/ear/era/
>=20
>=20
> Thanks!
>=20
> Cheers,
> --
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Feb 15 23:43:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36F1A8A50 for ; Mon, 15 Feb 2016 23:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkTIYtwxZUek for ; Mon, 15 Feb 2016 23:43:46 -0800 (PST)
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 76D001A8AE1 for ; Mon, 15 Feb 2016 23:43:46 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id h129so133152949ywb.1 for ; Mon, 15 Feb 2016 23:43:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lpkso24fzcqQPCWZGc09AN66KqzPQwsWHr7qiWLHUUo=; b=NU5rU47AItKCsycfmw0zDwbk7Yq2+/3sbdxAlKAw3HCrUAGIfO8cmvwLVt815qigYL uWHjVoOXtTchm3KnFuMXZ+HfCN8cdRbtWT55HcACd+1X/EHqgT90Ski6TBIW/R7mw2Mk SL4oPKAdJCwDyeCRwAqPqgLXfAuQSM8LlCRcLy+RajXA7nXSXQ02lqc9hTRVmJKGBYNS 2d2onwCpqLuUpYJdBDDYao0ypHFrnD2USabmVvv1feVBgwOlGA2W81tGsEOTo3FLfaSe XqrIeJNVm/j90/TaD4dsRDSoWBsbiB6Pfxcgzv1N/krvHzrFScnR9fQhMt+Z8NYyauxl WNfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lpkso24fzcqQPCWZGc09AN66KqzPQwsWHr7qiWLHUUo=; b=Cke3h6D9MbntCDhtv4zwap6zPkE1TA5Y4nHXF2PdjHgZsKiU83AvQNvuHw19ydUm9A 9cUerToRxA2qS9RE4EyuKR+FucvZ/shrdgi6JDHj3iyOwosxKMazuvwKoBDS7OoDh24P +B0z1T2Fx3ve7rA6Z+byRwtDd7Xkp8Go1NQZnbBmLPbWyZ7GAivl7UbBO39FSmNjJMze QMsapQ0RvnF6LC7eyfA8ooEzU+BMCJ/7uoqoKeGxk2epoNCWN3wKhMWP14o5E/Wx2kXx BwASG6dGbZINYQItKPdI3je9J6NvmGeGs3FrYGUpzMyhS1DLnGTLwkW8kU0B4bzk4Lcs +j7A==
X-Gm-Message-State: AG10YORl754WBNd8hPzAZkptyf8s91Gjvc18CLtvQAdCf7L/xcd/sSYRObGXM6S9+GfrnMib2IxUYA1dTvk4oyyU
X-Received: by 10.129.96.213 with SMTP id u204mr11250376ywb.307.1455608625661;  Mon, 15 Feb 2016 23:43:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.55.80 with HTTP; Mon, 15 Feb 2016 23:43:26 -0800 (PST)
In-Reply-To: <56C26B89.3020304@gmail.com>
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com>
From: Lorenzo Colitti 
Date: Tue, 16 Feb 2016 16:43:26 +0900
Message-ID: 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=001a114926e811120d052bde4bd7
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:43:47 -0000

--001a114926e811120d052bde4bd7
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 9:21 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> I believe we should not even suggest that it might be OK to allocate
> manually. This draft isn't a BCP so we can use normal English, for
> example:
>
> o Prefix generation: prefixes must be randomly generated according
>   to the algorithms defined in [RFC4193]. There are on-line tools
>   available to do this interactively, if not performed automatically
>   by the CPE. Manual assignment of easy-to-remember prefixes must
>   never be done because of the high risk of collision, recreating
>   the problems of [RFC1918].


+1. A manually assigned prefix in fc00::/7 is not ULA. It's bogon space.

--001a114926e811120d052bde4bd7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 16, 2016 at 9:21 AM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
I belie=
ve we should not even suggest that it might be OK to allocate

manually. This draft isn't a BCP so we can use normal English, for

example:



o Prefix generation: prefixes must be randomly generated according

=C2=A0 to the algorithms defined in [RFC4193]. There are on-line tools

=C2=A0 available to do this interactively, if not performed automatically
=C2=A0 by the CPE. Manual assignment of easy-to-remember prefixes must

=C2=A0 never be done because of the high risk of collision, recreating

=C2=A0 the problems of [RFC1918].

+1. A man=
ually assigned prefix in fc00::/7 is not ULA. It's bogon space.


--001a114926e811120d052bde4bd7--


From nobody Mon Feb 15 23:51:26 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3A1A0030 for ; Mon, 15 Feb 2016 23:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zFtYvwMU62x for ; Mon, 15 Feb 2016 23:51:22 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 501831A0370 for ; Mon, 15 Feb 2016 23:51:22 -0800 (PST)
Received: (qmail 53820 invoked from network); 16 Feb 2016 07:51:20 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Feb 2016 07:51:20 -0000
Date: Tue, 16 Feb 2016 08:51:20 +0100 (CET)
Message-Id: <20160216.085120.74703683.sthaug@nethelp.no>
To: brian.e.carpenter@gmail.com
From: sthaug@nethelp.no
In-Reply-To: <56C26B89.3020304@gmail.com>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:51:24 -0000

> I believe we should not even suggest that it might be OK to allocate
> manually. This draft isn't a BCP so we can use normal English, for
> example:
> 
> o Prefix generation: prefixes must be randomly generated according
>   to the algorithms defined in [RFC4193]. There are on-line tools
>   available to do this interactively, if not performed automatically
>   by the CPE. Manual assignment of easy-to-remember prefixes must
>   never be done because of the high risk of collision, recreating
>   the problems of [RFC1918].

Assume I want to number my lab using ULA. There's no way I'm going to
be using randomly generated addresses - I want to have an *address
plan*, and predictable addresses acording to a suitable pattern, just
as I would do with regular IPv6 addresses.

Which means I'd probably ignore the above sentence of never doing
manual assignment.

Yes, I understand what you're trying to do here - however, there are
situations where this *will* be ignored.

Steinar Haug, AS2116


From nobody Mon Feb 15 23:56:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2EF1A1A9B for ; Mon, 15 Feb 2016 23:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1L7guPr3Lij for ; Mon, 15 Feb 2016 23:56:33 -0800 (PST)
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 9A1671A0AF8 for ; Mon, 15 Feb 2016 23:56:33 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id e63so38207434ywc.3 for ; Mon, 15 Feb 2016 23:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dtmnqD092ThN9qGGMDOLauORAfjuwL5+7/7372CBkmg=; b=cY8Gj0MRa2klkkP1BSO7QblTET6jWo0i7xCbaQRjBBohB5oFB31ij1db8PpIq652aJ uzvllJFFH+81Kx2Ws5LV9pYaINQjETHhySV2l+t1OdVemGajTj4Hcu6suVG0Qw1/q+lZ NX8cJVWPoLgsm53Kc4eBzn94fGDHKbTvaofW3GV9NRHISqxSFX19Y7oU3jcgA3PD3X54 gt/fTzxu6aWe/FJ4EwBstVfvZ2/P4UF4e9+mOxhZZrpbI2/GEzFasa+R60jCzNfnni7A YkYLwJ6+9+3Prum+S4nmmjJvgYSMHzSmrg0uT4M5YT02IF2cAILiHqyq2da5FCO9DYTG 0wYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dtmnqD092ThN9qGGMDOLauORAfjuwL5+7/7372CBkmg=; b=XecrdhnHB5mzLLcHiwy9vhBFjskeCXK3dkGLme2ePC4l55zpp2FFAFQZ5Dp95ffkaU 9TJoLfHry1P3svw9X3MssXU4pef7Tkc2LEmswhQk8XdsBVG6PbTC4/H5NwopyTB3PD4/ ZnPPYM5G6wmGW95a+ARVmwyqfJG7RfjMdUj7C8A38C4xZh1plbXc5r8ucI/GZeiagjm9 8WxCeWW83/W63k6UgHSsaIRYgN5/NGQUiZRWk5BbhYEgKmul9GamRYOsmfeHJvu9KLYT uo7Q8heNCjB7CcPvXepbADyuTN1m+IgosIboFv3uoELyZQjRR+lOmpmfJJFuHbVKROA6 50Sw==
X-Gm-Message-State: AG10YOTMZ2FP9Hnr2Dzsk1+Kej8OZ3gH2gAmyIrK+DKUpEWPqhrNRNjMvFDHqFFwjVh7lH9nWiazElexQZC//X+R
X-Received: by 10.129.41.150 with SMTP id p144mr12660229ywp.123.1455609392883;  Mon, 15 Feb 2016 23:56:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.55.80 with HTTP; Mon, 15 Feb 2016 23:56:13 -0800 (PST)
In-Reply-To: <20160216.085120.74703683.sthaug@nethelp.no>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no>
From: Lorenzo Colitti 
Date: Tue, 16 Feb 2016 16:56:13 +0900
Message-ID: 
To: sthaug@nethelp.no
Content-Type: multipart/alternative; boundary=001a11421f00cbe5d2052bde78d5
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:56:34 -0000

--001a11421f00cbe5d2052bde78d5
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 4:51 PM,  wrote:

> Assume I want to number my lab using ULA. There's no way I'm going to
> be using randomly generated addresses - I want to have an *address
> plan*, and predictable addresses acording to a suitable pattern, just
> as I would do with regular IPv6 addresses.
>
> Which means I'd probably ignore the above sentence of never doing
> manual assignment.
>
> Yes, I understand what you're trying to do here - however, there are
> situations where this *will* be ignored.
>

I suggest you number your lab with 1::/16 instead. It's a bogon just the
same, and the addresses are even shorter and easier to remember.

More to the point: as a procedural matter, this is an informational
document and as such cannot document propose behaviour that is in direct
contrast with a standards track RFC., period.

--001a11421f00cbe5d2052bde78d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 16, 2016 at 4:51 PM,  <sthaug@nethelp.no> wrote:
=

Assume I want to number my lab using ULA. Th=
ere's no way I'm going to

be using randomly generated addresses - I want to have an *address

plan*, and predictable addresses acording to a suitable pattern, just

as I would do with regular IPv6 addresses.



Which means I'd probably ignore the above sentence of never doing

manual assignment.



Yes, I understand what you're trying to do here - however, there are
situations where this *will* be ignored.

I suggest you number your lab with 1::/16 instead. It's a bogon just =
the same, and the addresses are even shorter and easier to remember.
<=
div>
More to the point: as a procedural matter, this is an in=
formational document and as such cannot document propose behaviour that is =
in direct contrast with a standards track RFC., period.


--001a11421f00cbe5d2052bde78d5--


From nobody Mon Feb 15 23:59:39 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CE1ACEFF for ; Mon, 15 Feb 2016 23:59:37 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYqO-yCUE-QN for ; Mon, 15 Feb 2016 23:59:35 -0800 (PST)
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 543D91ACE8C for ; Mon, 15 Feb 2016 23:59:35 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 C14998527E; Tue, 16 Feb 2016 08:59:31 +0100 (CET)
To: Brian E Carpenter , "Dale W. Carder" 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C2C4FC.5090003@si6networks.com>
Date: Tue, 16 Feb 2016 03:43:08 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BBD6DB.6020507@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 07:59:37 -0000

On 02/10/2016 09:33 PM, Brian E Carpenter wrote:
> On 11/02/2016 09:34, Dale W. Carder wrote:
>> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
>>>
>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>>> that some random string of bits.
>>
>> I absolutely do not believe it can be expected that sites will generate 
>> random prefixes.
> 
> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
> be messing around with these things.

I guess that the thing is that if for one reason or another you need to
e.g. enforce ACLs or whatever, you want such prefixes to be "stable" --
e.g., what if you replace the CPE?

Thanks,
Fernando (a human who manually messed with ULAs :-) )





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





From nobody Tue Feb 16 00:16:02 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6BD1A8881 for ; Tue, 16 Feb 2016 00:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdgAIDokFXrE for ; Tue, 16 Feb 2016 00:15:57 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCF01A1B4B for ; Tue, 16 Feb 2016 00:15:57 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEM14745; Tue, 16 Feb 2016 08:15:23 +0000 (GMT)
Received: from lhreml703-cah.china.huawei.com (10.201.5.104) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 08:15:11 +0000
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 08:15:11 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Tue, 16 Feb 2016 16:15:03 +0800
From: "Liubing (Leo)" 
To: "sthaug@nethelp.no" , "brian.e.carpenter@gmail.com" 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
Thread-Index: AQHRZCBf+Tzq2HXT1E+bXAAC0O3fuZ8lNm6AgABC34CAARtDgIAAcgkAgABwvoCABdpBgIAAfbAAgACKwuA=
Date: Tue, 16 Feb 2016 08:15:03 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D441C8@nkgeml514-mbx.china.huawei.com>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no>
In-Reply-To: <20160216.085120.74703683.sthaug@nethelp.no>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56C2DA9D.0086, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3e7902eb6f7c54850cd609bcf253e16f
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 08:16:00 -0000

Hi Steinar,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
> sthaug@nethelp.no
> Sent: Tuesday, February 16, 2016 3:51 PM
> To: brian.e.carpenter@gmail.com
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
>=20
> > I believe we should not even suggest that it might be OK to allocate
> > manually. This draft isn't a BCP so we can use normal English, for
> > example:
> >
> > o Prefix generation: prefixes must be randomly generated according
> >   to the algorithms defined in [RFC4193]. There are on-line tools
> >   available to do this interactively, if not performed automatically
> >   by the CPE. Manual assignment of easy-to-remember prefixes must
> >   never be done because of the high risk of collision, recreating
> >   the problems of [RFC1918].
>=20
> Assume I want to number my lab using ULA. There's no way I'm going to be
> using randomly generated addresses - I want to have an *address plan*, an=
d
> predictable addresses acording to a suitable pattern, just as I would do =
with
> regular IPv6 addresses.
[Bing] There are only 40bit of the ULA prefix to be randomly generated, we =
still have a 16bit "Subnet ID" to plan the addresses with the same /48 ULA =
prefix.
I guess 16bit should be enough for a lab to do the address plan?

Best regards,
Bing

> Which means I'd probably ignore the above sentence of never doing manual
> assignment.
>=20
> Yes, I understand what you're trying to do here - however, there are
> situations where this *will* be ignored.
>=20
> Steinar Haug, AS2116
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Tue Feb 16 00:19:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB891B2B86 for ; Tue, 16 Feb 2016 00:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uPnTJQOW5R7 for ; Tue, 16 Feb 2016 00:19:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34DF1ACE2E for ; Tue, 16 Feb 2016 00:19:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIQ23594; Tue, 16 Feb 2016 08:19:44 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 16 Feb 2016 08:19:43 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 16 Feb 2016 16:19:37 +0800
From: "Liubing (Leo)" 
To: Brian E Carpenter , Tim Chown 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
Thread-Index: AQHRZCBf+Tzq2HXT1E+bXAAC0O3fuZ8lNm6AgABC34CAARtDgIAAcgkAgABwvoCABdpBgIABCpzA
Date: Tue, 16 Feb 2016 08:19:36 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D441D5@nkgeml514-mbx.china.huawei.com>
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com>
In-Reply-To: <56C26B89.3020304@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.56C2DBA1.012A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a02e8ace60bb23b648c87ad1747c6dee
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 08:19:50 -0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, February 16, 2016 8:21 AM
> To: Tim Chown
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
>=20
> On 12/02/2016 19:59, Tim Chown wrote:
> ...
> >> Exactly. And we should include a very strong warning against manually
> >> assigning a human-friendly prefix.
> >
> > Definitely. Even if we know what's likely to happen in practice. And if=
 you
> are manually picking a ULA /48 at least don't do all zeros - even using s=
ome
> bits of your global /48 in the ULA prefix is better than that.
>=20
> Specifically, I believe that the following paragraph of the draft, in sec=
tion 4.1,
> is dangerous:
>=20
> o Prefix generation: randomly generated according to the algorithms
>   defined in [RFC4193] or manually assigned.  Normally, automatic
>   generation of the prefixes is recommended, following [RFC4193].
>   If there are some specific reasons that call for manual
>   assignment, administrators have to plan the prefixes carefully to
>   avoid collision.
>=20
> I believe we should not even suggest that it might be OK to allocate manu=
ally.
> This draft isn't a BCP so we can use normal English, for
> example:
>=20
> o Prefix generation: prefixes must be randomly generated according
>   to the algorithms defined in [RFC4193]. There are on-line tools
>   available to do this interactively, if not performed automatically
>   by the CPE. Manual assignment of easy-to-remember prefixes must
>   never be done because of the high risk of collision, recreating
>   the problems of [RFC1918].

[Bing] I think the proposed text is better. We do need to encourage people =
to use tools to generate the decent ULA prefixes.
I'll modify it in the next version accordingly. Thanks.

Best regards,
Bing

>    Brian
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Tue Feb 16 00:24:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524061B2A2A for ; Tue, 16 Feb 2016 00:24:41 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbCBueML2NL3 for ; Tue, 16 Feb 2016 00:24:39 -0800 (PST)
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 C79BD1B2A22 for ; Tue, 16 Feb 2016 00:24:38 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 B915B85283; Tue, 16 Feb 2016 09:24:35 +0100 (CET)
To: "Liubing (Leo)" 
References: <56BB639E.5010505@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D44153@nkgeml514-mbx.china.huawei.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C2DC98.70400@si6networks.com>
Date: Tue, 16 Feb 2016 05:23:52 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D44153@nkgeml514-mbx.china.huawei.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 08:24:41 -0000

Hi, Leo,

Thanks so much for your response! -- Comments in-line (only for those
items that needed further comments)...

On 02/16/2016 04:17 AM, Liubing (Leo) wrote:
>> ** Technical **
>> 
>> * Meta: Both section 4 and section 6 contain use cases. This is
>> rather confusing. e.g., not sure what's the criteria to ut some of
>> the use cases in Section 4, while others in Section 6. Unless I'm
>> missing something, this should be fixed.
> 
> [Bing] The original idea was to enumerate all possible use cases in
> Section4, and sort out the beneficial ones into Section6. I also had
> concerned a bit on the section4/6 overlapping issue in previous
> versions, your comment made me more tendency to merge them. Let me
> try it in the next version.

Great!



>> * Section 3.2: Do folks really generate the prefixes as
>> "required"? Me, I confess I've used things like fc00:1::/64 because
>> they are simpler that some random string of bits.
> [Bing] This is a human practical issue, but ULA itself is innocent:) 
> Section 3 is a summary of the ULA features, I think your
> consideration could be included in Section 4.

Agreed. My comment is that in practice, humans my take a shortcut and
produce more "human friendly" prefixes -- I've done that (i.e., "guilty"
:-) )




>> * Section 4.1, page 4:
>>> IP is used ubiquitously.  Some networks like industrial control
>>> bus (e.g.  [RS-485], [SCADA], or even non-networked digital
>>> interfaces like [MIL-STD-1397] have begun to use IP.  In these
>>> kinds of networks, the system may lack the ability to communicate
>>> with the public networks.
>> 
>> Not sure what you mean by "may lack the ability...".
> [Bing] These industrial networks might not support common Internet
> services/functions such as HTTP, DNS etc., and they might not have
> the requirement to talk to the nodes in the public Internet.

This is more clear than the text in the I-D. I'd suggest you appy this
to the I-D.



>> * Section 4.1, page 5:
>>> o  Prefix generation: randomly generated according to the
>>> algorithms defined in [RFC4193] or manually assigned.  Normally,
>>> automatic generation of the prefixes is recommended, following
>>> [RFC4193]. If there are some specific reasons that call for
>>> manual assignment, administrators have to plan the prefixes
>>> carefully to avoid collision.
>> 
>> mm.. what do you mean exactly by "automatic generation"? -- In all
>> those systems I have employed, the ULA prefixes are not generated
>> automagically. -- you need to un the algorithm yourself, which
>> means that the prefix is alwas manually configured (in the routers
>> sending the RAs).
> [Bing] I think we're talking the same thing. "Automatic generation"
> means there is a function which aligns with the rules in 4193 in the
> device/software to generate the prefixes. We never assign "random"
> prefixes by our brains, unless there is no software available. I'll
> make it more clearer in the next version.

FWIW, general purpose operating systems (e.e. Linux) do not really have
such a function.



>> * Section 4.2.2, page 7:
>>> Note: ULAs provide more benefit for multiple-segment home
>>> networks;
>> for
>>> home networks containing only one segment, link-local addresses 
>>> are better alternatives.
>> 
>> You need to expand and back these claims...
> [Bing] Ok, I guess some quoting from Homenet documents might be
> helpful.

Yes.



>> * Section 4.2.2, page 9:
>>> 
>>> o  DNS relevant: if administrators choose not to do reverse DNS 
>>> delegation inside of their local control of ULA prefixes, a 
>>> significant amount of information about the ULA population may 
>>> leak to the outside world.  Because reverse queries will be made 
>>> and naturally routed to the global reverse tree, so external 
>>> parties will be exposed to the existence of a population of ULA 
>>> addresses.  [ULA-IN-WILD] provides more detailed situations on 
>>> this issue.  Administrators may need a split DNS to separate the 
>>> queries from internal and external for ULA entries and GUA 
>>> entries.
>> 
>> This text seems to imply that someone will do reverse mappings for
>> ULAs. Could you please elaboate a bit on the scenario that you
>> envision?
> [Bing] [ULA-IN-WILD] provides more detailed situations on this issue.
> You can see slide 20, which is an instance of "SMTP Received-Via". 
> [ULA-IN-WILD] link:
> http://conference.apnic.net/data/36/apnic-36-ula_1377495768.pdf

Oops, my bad! Thanks! (no changes needed)



>> * Section 6.3.3, page 12:
>>> ULAs could be self-generated and easily grabbed from the
>>> standard IPv6 stack.  And ULAs don't need to be changed as the
>>> GUA prefixes do.  So they are very suitable to be used as
>>> identifiers by the up layer applications.  And since ULA is not
>>> intended to be globally routed, it is not harmful to the routing
>>> system.
>> 
>> Using IP addresses as identifiers in upper layers is a really bad
>> idea.
> [Bing] If we merge Section6 into Section4, would you share more
> opinions of why it's bad to use it as identifier?

One of the main reasons is that applications become tied to a layer-3
protocol. It's better to use names rather than addresses. So I'd remove
the comment on using the addresses as identifiers in the upper layer
protocol.

Thanks!

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





From nobody Tue Feb 16 00:49:21 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBC1B2A44 for ; Tue, 16 Feb 2016 00:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W13iM695FIY for ; Tue, 16 Feb 2016 00:49:18 -0800 (PST)
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 664B21AD35E for ; Tue, 16 Feb 2016 00:49:18 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 DD4A88527B; Tue, 16 Feb 2016 09:49:15 +0100 (CET)
To: Philip Homburg , v6ops@ietf.org
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com> 
From: Fernando Gont 
Message-ID: <56C2DF32.3010901@si6networks.com>
Date: Tue, 16 Feb 2016 05:34:58 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 08:49:19 -0000

On 02/10/2016 08:29 AM, Philip Homburg wrote:
> In your letter dated Wed, 10 Feb 2016 07:21:59 -0300 you wrote:
>> That's the point: you cannot tell if what's inside is an EH or an
>> upper-layer protocol.
>>
>> If the device is whitelisting stuff, I'd agree with you on the
>> end-result. OTOH, if the devices means to blacklist stuff, then this may
>> lead to unnecessarily packet drops.
>>
>> And, in any case, a bug is a bug.
> 
> Call me paranoid, but I'm quite happy if a security device drops stuff it
> doesn't understand.
> 
> It shouldn't be that hard to support a white list of unknown extension
> headers that can be set by the operator. 

How do you skip past an unknown EH?

Thanks!

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





From nobody Tue Feb 16 00:49:31 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC46F1B2A44 for ; Tue, 16 Feb 2016 00:49:29 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIldXNACfUcu for ; Tue, 16 Feb 2016 00:49:25 -0800 (PST)
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 2EE8C1B2AEC for ; Tue, 16 Feb 2016 00:49:24 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 BE8408527B; Tue, 16 Feb 2016 09:49:20 +0100 (CET)
To: Tom Herbert , Brian E Carpenter 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <4044B8C3-844A-40E7-A98E-D26961FADD39@employees.org> <56BBE231.9030706@gmail.com>  <56BD224F.1050406@gmail.com> 
From: Fernando Gont 
Message-ID: <56C2E038.7080003@si6networks.com>
Date: Tue, 16 Feb 2016 05:39:20 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 08:49:29 -0000

On 02/12/2016 05:02 AM, Tom Herbert wrote:
> On Fri, Feb 12, 2016 at 1:07 AM, Brian E Carpenter
>  wrote:
>> On 11/02/2016 22:57, Tom Herbert wrote:
>> ...
>>> Suppose we define an "EH chain length" extension header. This would
>>> include the length of the chain starting from the first byte of the EH
>>> and also a next header value for the header that follow the chain.
>>> This EH could follow HBP. Network nodes can use this to skip over a
>>> long chain to parse the transport header. The receiver would need to
>>> validate the length and protocol are correct in order to prevent
>>> someone from spoofing transport headers.
>>
>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01
>>
>> But it doesn't help, because any middlebox that insists on trying
>> to parse all the headers will not make use of this feature.
>>
> Right, but realistically if we want to send extension headers into the
> Internet we can't wait an indefinite amount of time for every single
> device to properly handle them. It seems that we'd want to apply a
> happy eyeballs approach. If the offset option makes it more palatable
> for some devices to forward packets with EH that could move things
> forward by some amount. I also see a use case for this at the end
> hosts, a ridiculously long chain could be a nice DOS attack and the
> offset option might mitigate that. For instance, before processing the
> chain we could verify if an encapsulated TCP packet refers to a valid
> connection.

Other things aside, this would be done by a totally different layer of
code... layer-3 vs layer-4...

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





From nobody Tue Feb 16 04:10:46 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0A81B35A7 for ; Tue, 16 Feb 2016 04:10:45 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1rY2nIxNi-x for ; Tue, 16 Feb 2016 04:10:42 -0800 (PST)
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 813171B35A5 for ; Tue, 16 Feb 2016 04:10:42 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 CD2A385267; Tue, 16 Feb 2016 13:10:37 +0100 (CET)
To: Brian E Carpenter , Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B40916.1060504@si6networks.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56C303EC.7040004@si6networks.com>
Date: Tue, 16 Feb 2016 08:11:40 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BBF425.5070107@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 12:10:45 -0000

On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
> On 10/02/2016 10:41, Tom Herbert wrote:
>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>  wrote:
>>> Ole,
>>>
>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>> ...
>>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>>> anyone studied this over time?
>>>>>
>>>>> We're planning for the long term here. While I agree that this is a very
>>>>> interesting question, we shouldn't base future practice on it.
>>>>
>>>> I'm not sure what you imply by that.
>>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>
>>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>>> load balancing products that support the flow label, in order to create an incentive
>>> for users to run host stacks that set the flow label by default. Actually I think
>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>>> to 3-tuple if the transport header isn't the first Next Header.
>>>
>>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>>
>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>
>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
>> time now. Support was added in Linux to send non-zero flow labels by
>> default, Android will pick those up the next time they rebase (I still
>> don't know what the status is in Windows). In reality, setting the
>> flow label on the host is near zero cost and as long as network
>> devices are choking on them (we don't have any evidence of that)
>> there's no reason why we can't get to widespread usage in a relatively
>> short period of time.
> 
> Windows 7 doesn't set any value by default, and I can't find a netshell
> command to switch it on. (I assume a TCP app can set it through the socket
> interface, but that's beside the point.)

FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS
they would set the FL to zero, and once established it would be set to
non-zero.. not sure if this changed.

In some scenarios (think SYN-cookies) this behavior might be difficult
to avoid.

Thanks!

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





From nobody Tue Feb 16 05:27:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE3F1ACD9A for ; Tue, 16 Feb 2016 05:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2PIg7OPcZAC for ; Tue, 16 Feb 2016 05:27:14 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E38DB1A8A4D for ; Tue, 16 Feb 2016 05:27:12 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aVfep-0000CuC; Tue, 16 Feb 2016 14:27:11 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <56B 9D9BE.6050405@si6networks.com> <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <56BAF7 3D.9040707@si6networks.com> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org> <56BB0F47. 6000804@si6networks.com>  <56C2DF32.3010901@s i6networks.com> 
In-reply-to: Your message of "Tue, 16 Feb 2016 05:34:58 -0300 ." <56C2DF32.3010901@si6networks.com> 
Date: Tue, 16 Feb 2016 14:27:09 +0100
Archived-At: 
Cc: Fernando Gont 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 13:27:16 -0000

>On 02/10/2016 08:29 AM, Philip Homburg wrote:
>> It shouldn't be that hard to support a white list of unknown extension
>> headers that can be set by the operator. 
>
>How do you skip past an unknown EH?

A local config file on the middle box. 

Something like 'safe-unknown-extension-headers: ddd'

The operator adds the number when it is determined to be perfectly
safe (that I find unlikely for new extension headers) and enough people
are speaking up that the operator is a aware of the problem.


From nobody Tue Feb 16 07:11:03 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2D1A897A for ; Tue, 16 Feb 2016 07:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fTbrp9PwWjY for ; Tue, 16 Feb 2016 07:10:59 -0800 (PST)
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 AA03C1A066C for ; Tue, 16 Feb 2016 07:10:59 -0800 (PST)
Received: from mb-2.local ([172.58.32.48]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1GFApVn034876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 15:10:54 GMT (envelope-from joelja@bogus.com)
To: Fernando Gont , Brian E Carpenter , Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B49E82.6030900@foobar.org> <56B4B81E.6080904@isi.edu> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com> <56C303EC.7040004@si6networks.com>
From: joel jaeggli 
Message-ID: 
Date: Tue, 16 Feb 2016 07:10:46 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <56C303EC.7040004@si6networks.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="INaRKXFEsgb4CcW1Ibaumil8euvBwv1M0"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:11:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--INaRKXFEsgb4CcW1Ibaumil8euvBwv1M0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2/16/16 3:11 AM, Fernando Gont wrote:
> On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
>> On 10/02/2016 10:41, Tom Herbert wrote:
>>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>>  wrote:
>>>> Ole,
>>>>
>>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>>> ...
>>>>>>> what's the ratio of flow label =3D 0 to set flow labels in your n=
etwork?
>>>>>>> anyone studied this over time?
>>>>>>
>>>>>> We're planning for the long term here. While I agree that this is =
a very
>>>>>> interesting question, we shouldn't base future practice on it.
>>>>>
>>>>> I'm not sure what you imply by that.
>>>>> if the flow label is set, then router implementations / deployments=
 can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>>
>>>> Because of the chicken/egg problem, we need operators to require ECM=
P/LAG and server
>>>> load balancing products that support the flow label, in order to cre=
ate an incentive
>>>> for users to run host stacks that set the flow label by default. Act=
ually I think
>>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and =
drop back
>>>> to 3-tuple if the transport header isn't the first Next Header.
>>>>
>>>>> if generally flow label =3D 0, then we could at least identify impl=
ementations that needs to be fixed so that we at some point can change.
>>>>
>>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>>
>>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for som=
e
>>> time now. Support was added in Linux to send non-zero flow labels by
>>> default, Android will pick those up the next time they rebase (I stil=
l
>>> don't know what the status is in Windows). In reality, setting the
>>> flow label on the host is near zero cost and as long as network
>>> devices are choking on them (we don't have any evidence of that)
>>> there's no reason why we can't get to widespread usage in a relativel=
y
>>> short period of time.
>>
>> Windows 7 doesn't set any value by default, and I can't find a netshel=
l
>> command to switch it on. (I assume a TCP app can set it through the so=
cket
>> interface, but that's beside the point.)
>=20
> FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS=

> they would set the FL to zero, and once established it would be set to
> non-zero.. not sure if this changed.
>=20
> In some scenarios (think SYN-cookies) this behavior might be difficult
> to avoid.

right, if you want a flow label that is itself not derived from some
deterministic transform you kind of have to keep track of what it is
once you set it.

syn cookies causes a non-zero amount of breakage so it tends to be used
sparingly but it remains an extremely useful tool under duress.

> Thanks!
>=20
> Cheers,
>=20



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

iEYEARECAAYFAlbDO/YACgkQ8AA1q7Z/VrLn9wCggyogrNRx2rfbP9c05ivtsC46
3XgAniQ07EQzCPplkXN0YQhEOr8M4u+T
=iYll
-----END PGP SIGNATURE-----

--INaRKXFEsgb4CcW1Ibaumil8euvBwv1M0--


From nobody Tue Feb 16 07:14:08 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E991B2A50 for ; Tue, 16 Feb 2016 07:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQXli7VLT1Y7 for ; Tue, 16 Feb 2016 07:14:04 -0800 (PST)
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 6361C1B2A49 for ; Tue, 16 Feb 2016 07:14:04 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id g127so141343449ywf.2 for ; Tue, 16 Feb 2016 07:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Q0zmvMJz223yZNIyCW+5ewDhaINgFiRCJmdCklrYaDI=; b=JnrqDv3GFU4dcRr0TSdq8kI002WgBM/G0+U02CAhqFriOCtk4jRLxC04ktGhKkXcbB dWdnliRmbMr+08x3k3aOQSWxYOLkk1+qhuEdcGBuBl3Hjy77tvSxeWPKGkZTNJ6pUu7x ZkG6eDmI3EtopHzaB8F77senX0KDXYThpzwqVfd0DSAuBodACALZmng8kWb2ajii8ed9 Y398MXR7Cr31x30GcP8Z5Wn7pVaZFKDcNMs/gKvkCSNnRwBWMVtCHdYvIdi8dJFvb9uj PxrtRSKY6r8085XPLBpl/7Hw612CLVKWjiPsVb4BwsYjCAwj9Vyntpov337ei4G7RC4W 1Rgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Q0zmvMJz223yZNIyCW+5ewDhaINgFiRCJmdCklrYaDI=; b=bIci8bUgKpxsr8gz9elM23ODSIkjQaW8Rs97Jp20NLe4L0iTSAK0IsGweLOi7o0i7v bNxPkwoa+hFI72yWeO19S9aXmI0sf/9b+S302MurjLI3NIB04QUCMALjay6bQhn4rPSx pFtJFq/L8wsQx1pHh/i4et819WKtdkok2JfK6f5u2iSYaE50Uc9v+L8MPaSwhqq/3tJr EJcYDy3HAU2h3/ZZNFYE6XQw5375C9t/RfpVFWyZKVm082PvLWkGklgobha7vvWKSqfE 0i8U2tsrVOK0U5Uw6sWB5HW3tvWJGhEOoWyB2LgrwabUhFiqHq8CD8oqP6aPUKM1olHc X50A==
X-Gm-Message-State: AG10YOS7X84Gl5aJfun0S1ApmscVlsJgEQfR4UJ7usOEpFiOLmJfQmWWYWG/rYJAC6j6YQfBWqbbp10yw5aoDIwZ
X-Received: by 10.129.145.82 with SMTP id i79mr12419212ywg.345.1455635643766;  Tue, 16 Feb 2016 07:14:03 -0800 (PST)
MIME-Version: 1.0
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org>  <56C2DF32.3010901@si6networks.com> 
In-Reply-To: 
From: Warren Kumari 
Date: Tue, 16 Feb 2016 15:13:54 +0000
Message-ID: 
To: Philip Homburg , v6ops@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c093a3e7847d0052be49589
Archived-At: 
Cc: Fernando Gont 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:14:06 -0000

--94eb2c093a3e7847d0052be49589
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 16, 2016 at 8:27 AM Philip Homburg 
wrote:

> >On 02/10/2016 08:29 AM, Philip Homburg wrote:
> >> It shouldn't be that hard to support a white list of unknown extension
> >> headers that can be set by the operator.
> >
> >How do you skip past an unknown EH?
>
> A local config file on the middle box.
>
> Something like 'safe-unknown-extension-headers: ddd'
>
> The operator adds the number when it is determined to be perfectly
> safe (that I find unlikely for new extension headers) and enough people
> are speaking up that the operator is a aware of the problem.
>
>
This also requires that the application developer makes a judgment call as
to when it is safe to be able to enable this unknown EH.
So, after all middle boxes support "safe-unknown-extension-headers" we need:
A: the new unknown EH written
B: someone to be brave enough to try using it (and have it fail in many /
most cases)
C: a large upswell of people going around an poking operators (including
Billybob, who runs the edge middlebox "protecting" Henrys Tire and Wheel
Balancing, Middleburg, VA) to get them to log onto all their devices and
add this new EH to the list of safe things
D: More applications to try using this and have it fail elegantly in some
set of conditions
E: outreach to once again poke Billybob, who replaced his middlebox with
the backup one which lives in the spares closet and wasn't turned on in
step C.
F: application developers to have enough faith that this will work 100% of
the time (keeping in mind that they got bitten in B and D) to turn it on.

This EH would need to provide some *really* compelling benefit to make this
process worthwhile. We've already seen that it is hard to get something
deployed which requires reaching out to all operators and getting everyone
to take some action without direct benefit (e.g BCP38...)

W



> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--94eb2c093a3e7847d0052be49589
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue=
, Feb 16, 2016 at 8:27 AM Philip Homburg <pch-v6ops-4@u-1.phicoh.com> wrote:
>On 02/10/2016 08:29 AM, Philip Homburg wrote:
>> It shouldn't be that hard to support a white list of unknown e=
xtension

>> headers that can be set by the operator.

>

>How do you skip past an unknown EH?



A local config file on the middle box.



Something like 'safe-unknown-extension-headers: ddd'



The operator adds the number when it is determined to be perfectly

safe (that I find unlikely for new extension headers) and enough people

are speaking up that the operator is a aware of the problem.



This also requires that the applicatio=
n developer makes a judgment call as to when it is safe to be able to enabl=
e this unknown EH.
So, after all middle boxes support "safe-=
unknown-extension-headers" we need:
A: the new unknown EH wr=
itten
B: someone to be brave enough to try using it (and have it =
fail in many / most cases)
C: a large upswell of people going aro=
und an poking operators (including Billybob, who runs the edge middlebox &q=
uot;protecting" Henrys Tire and Wheel Balancing, Middleburg, VA) to ge=
t them to log onto all their devices and add this new EH to the list of saf=
e things
D: More applications to try using this and have it fail =
elegantly in some set of conditions
E: outreach to once again pok=
e Billybob, who replaced his middlebox with the backup one which lives in t=
he spares closet and wasn't turned on in step C.
F: applicati=
on developers to have enough faith that this will work 100% of the time (ke=
eping in mind that they got bitten in B and D) to turn it on.
This EH would need to provide some *really* compelling benefit =
to make this process worthwhile. We've already seen that it is hard to =
get something deployed which requires reaching out to all operators and get=
ting everyone to take some action without direct benefit (e.g BCP38...)

W

=C2=A0

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops




--94eb2c093a3e7847d0052be49589--


From nobody Tue Feb 16 07:33:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61AE1B2D73 for ; Tue, 16 Feb 2016 07:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdTFdnvRTAE3 for ; Tue, 16 Feb 2016 07:33:07 -0800 (PST)
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 8E4F21B2CCD for ; Tue, 16 Feb 2016 07:33:05 -0800 (PST)
Received: from mb-2.local ([172.58.32.48]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1GFWvi6035017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2016 15:32:58 GMT (envelope-from joelja@bogus.com)
To: Lorenzo Colitti , sthaug@nethelp.no
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> 
From: joel jaeggli 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Tue, 16 Feb 2016 07:32:52 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1HdK8LcTqG235bFK68WKxJq4Vnog2KDk2"
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:33:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1HdK8LcTqG235bFK68WKxJq4Vnog2KDk2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2/15/16 11:56 PM, Lorenzo Colitti wrote:
> On Tue, Feb 16, 2016 at 4:51 PM,  > wrote:
>=20
>     Assume I want to number my lab using ULA. There's no way I'm going =
to
>     be using randomly generated addresses - I want to have an *address
>     plan*, and predictable addresses acording to a suitable pattern, ju=
st
>     as I would do with regular IPv6 addresses.
>=20
>     Which means I'd probably ignore the above sentence of never doing
>     manual assignment.
>=20
>     Yes, I understand what you're trying to do here - however, there ar=
e
>     situations where this *will* be ignored.
>=20
>=20
> I suggest you number your lab with 1::/16 instead. It's a bogon just th=
e
> same, and the addresses are even shorter and easier to remember.
>=20
> More to the point: as a procedural matter, this is an informational
> document and as such cannot document propose behaviour that is in direc=
t
> contrast with a standards track RFC., period.

There are more or less infinite variations on how  a lab might be
numbered, depending on what the affect to be achieved is.  I wouldn't
"recommend"  a ula usage inconsistent with any other recomended ula
usage. various applications such as simulating one's production network
can require prefix ranges much larger than the documentation prefix, or
traditional ULA  assignment are intended to support. that's fine, but
it's up to the developer.

joel

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20



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

iEYEARECAAYFAlbDQSQACgkQ8AA1q7Z/VrJAbQCdGc9QpBfOx6DhSra2VukrEE7z
qNAAnj4+dJa1UhX6zDvCuwn4V8Q/Cr9q
=w6pF
-----END PGP SIGNATURE-----

--1HdK8LcTqG235bFK68WKxJq4Vnog2KDk2--


From nobody Tue Feb 16 07:38:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4141A90B5 for ; Tue, 16 Feb 2016 07:38:22 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QKW8DGRDC3n for ; Tue, 16 Feb 2016 07:38:20 -0800 (PST)
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 3541E1A890D for ; Tue, 16 Feb 2016 07:38:20 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 9AC9081DCA; Tue, 16 Feb 2016 16:38:16 +0100 (CET)
To: Warren Kumari , Philip Homburg , v6ops@ietf.org
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org>  <56C2DF32.3010901@si6networks.com>  
From: Fernando Gont 
Message-ID: <56C34009.1070508@si6networks.com>
Date: Tue, 16 Feb 2016 12:28:09 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 15:38:23 -0000

On 02/16/2016 12:13 PM, Warren Kumari wrote:
> 
> 
> On Tue, Feb 16, 2016 at 8:27 AM Philip Homburg
> > wrote:
> 
>     >On 02/10/2016 08:29 AM, Philip Homburg wrote:
>     >> It shouldn't be that hard to support a white list of unknown
>     extension
>     >> headers that can be set by the operator.
>     >
>     >How do you skip past an unknown EH?
> 
>     A local config file on the middle box.
> 
>     Something like 'safe-unknown-extension-headers: ddd'
> 
>     The operator adds the number when it is determined to be perfectly
>     safe (that I find unlikely for new extension headers) and enough people
>     are speaking up that the operator is a aware of the problem.
> 
> 
> This also requires that the application developer makes a judgment call
> as to when it is safe to be able to enable this unknown EH.
> So, after all middle boxes support "safe-unknown-extension-headers" we need:
> A: the new unknown EH written
> B: someone to be brave enough to try using it (and have it fail in many
> / most cases)
> C: a large upswell of people going around an poking operators (including
> Billybob, who runs the edge middlebox "protecting" Henrys Tire and Wheel
> Balancing, Middleburg, VA) to get them to log onto all their devices and
> add this new EH to the list of safe things
> D: More applications to try using this and have it fail elegantly in
> some set of conditions
> E: outreach to once again poke Billybob, who replaced his middlebox with
> the backup one which lives in the spares closet and wasn't turned on in
> step C.
> F: application developers to have enough faith that this will work 100%
> of the time (keeping in mind that they got bitten in B and D) to turn it on.
> 
> This EH would need to provide some *really* compelling benefit to make
> this process worthwhile. 

I think I learned a long-version of the English word "never" (?). :-)

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





From nobody Tue Feb 16 10:25:38 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A148F1B338E for ; Tue, 16 Feb 2016 10:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.564
X-Spam-Level: ***
X-Spam-Status: No, score=3.564 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4t-kj8LCfse for ; Tue, 16 Feb 2016 10:25:35 -0800 (PST)
Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5849E1B3387 for ; Tue, 16 Feb 2016 10:25:35 -0800 (PST)
X-SENDER-IP: 10.64.163.161
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.22,456,1449550800";  d="scan'208,217";a="1009248173"
Received: from unknown (HELO exchpapp20.corp.twcable.com) ([10.64.163.161]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 16 Feb 2016 13:22:42 -0500
Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp20.corp.twcable.com (10.64.163.161) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 16 Feb 2016 13:25:24 -0500
Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1130.005; Tue, 16 Feb 2016 13:25:24 -0500
From: "Howard, Lee" 
To: Lorenzo Colitti , Brian E Carpenter 
Thread-Topic: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00
Thread-Index: AQHRaFI9cDXgpgY+xEWmucaLrcWTEZ8uMF8AgADNxwA=
Date: Tue, 16 Feb 2016 18:25:24 +0000
Message-ID: 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BD2422.4090501@gmail.com> <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26F44.6000107@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.0.151221
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.239]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22134.004
x-tm-as-result: No--35.336700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_D2E8D1A5D7518LeeHowardtwcablecom_"
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 18:25:37 -0000

--_000_D2E8D1A5D7518LeeHowardtwcablecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: v6ops > on beha=
lf of Lorenzo Colitti >
Date: Monday, February 15, 2016 at 8:08 PM
To: Brian Carpenter >
Cc: 'IPv6 Operations' >
Subject: Re: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usa=
ge-considerations-00

On Tue, Feb 16, 2016 at 9:37 AM, Brian E Carpenter > wrote:
2) The sub-section "ULA-Only Deployment" starts by implying
that this might be a good idea. I suggest rewriting the
first sentence to make it sound like a doubtful idea:

Wow. How did we end up with this text?

At the microphone in Yokohama there was very strong opposition to ULA-only =
deployments using NPTv6. We got comment after comment saying that NPTv6 sho=
uld be explicitly not recommended. How can we have text in this document th=
at so explicitly goes against these opinions?


The discussion on list has not been as clearly against NPT in every circums=
tance as the discussion at the meeting. I suggested the authors try to desc=
ribe the reasons people support or oppose its use, so readers could make we=
ll-informed decisions. Even well-informed bad decisions are better than uni=
nformed bad decisions.

Lee



________________________________

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_D2E8D1A5D7518LeeHowardtwcablecom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable



















From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo =
Colitti <lorenzo@google.com>=
;

Date: Monday, February 15, 2016 at =
8:08 PM

To: Brian Carpenter <brian.e.carpenter@gmail.com>

Cc: 'IPv6 Operations' <v6ops@ietf.org>

Subject: Re: [v6ops] Connected Netw=
orks section of draft-ietf-v6ops-ula-usage-considerations-00



















On Tue, Feb 16, 2016 at 9:37 AM, Brian E Carpent=
er 
<brian.=
e.carpenter@gmail.com> wrote:



2) The sub-section "ULA-Only Deployment" starts by implying

that this might be a good idea. I suggest rewriting the

first sentence to make it sound like a doubtful idea:









Wow. How did we end up with this text?







At the microphone in Yokohama there was very strong opposition to ULA-=
only deployments using NPTv6. We got comment after comment saying that NPTv=
6 should be explicitly not recommended. How can we have text in this docume=
nt that so explicitly goes against
 these opinions?

























The discussion on list has not been as clearly against NPT in every ci=
rcumstance as the discussion at the meeting. I suggested the authors try to=
 describe the reasons people support or oppose its use, so readers could ma=
ke well-informed decisions. Even
 well-informed bad decisions are better than uninformed bad decisions.






Lee

















This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to
 which it is addressed. If you are not the intended recipient of this E-mai=
l, you are hereby notified that any dissemination, distribution, copying, o=
r action taken in relation to the contents of and attachments to this E-mai=
l is strictly prohibited and may
 be unlawful. If you have received this E-mail in error, please notify the =
sender immediately and permanently delete the original and any copy of this=
 E-mail and any printout.





--_000_D2E8D1A5D7518LeeHowardtwcablecom_--


From nobody Tue Feb 16 11:31:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E551A871B for ; Tue, 16 Feb 2016 11:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOvtJz2-K6fl for ; Tue, 16 Feb 2016 11:31:09 -0800 (PST)
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 495F91A8739 for ; Tue, 16 Feb 2016 11:31:09 -0800 (PST)
Received: by mail-pa0-x229.google.com with SMTP id ho8so109729558pac.2 for ; Tue, 16 Feb 2016 11:31:09 -0800 (PST)
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-type :content-transfer-encoding; bh=sswFoP9MU/I6BHroDOBjc4jqf4RS0AiLJgCTCWJ4prg=; b=VUxZV9OUCymOKsXvrPdqEnUMGtTVQQekvHggo7AT0t3dINX9+lcTfXGRD64ciaDj5I WSlmxyIjGLK6zDzyjX++MTEfBMIUeIFvFbsMsAxpEMybwnHFYyHeDlthuTlj8YYCQhbr japt30JygJBgaeA8bC2RVQRRE1EiznyvDx3xrIi3tyxLqu/pOdkAcj6rf6lEDpcSiHvx g8dnVlC1COPrbk3QsD9EH+YaqwVGaTTar/uOC5rGyXazqNnPx4sewf7OTNeTuUxIvm3X u8f/mRC50ClrJb5LNPdUvmh3AGlH2b46qrYBepzqxO7iEKBc1lGSzK1i05L8KjMSjrNz mypA==
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-type :content-transfer-encoding; bh=sswFoP9MU/I6BHroDOBjc4jqf4RS0AiLJgCTCWJ4prg=; b=l/YwWlF32ma/XmgmWiOLCOce+BAuJOY9oibt6sHHjrLpy7s6viYazLljto+M07YQsa tnH97ClG1SJDPDBl/+1KITGgtW5d7w4Crq0DVKgqRarkA5ephUlrZ0Cw48Gk7nUaYVpV Ub1iquqPmXCxf6zeHy2HRAz4jgkwuPLp45uDRzqw0HLgjtY6bVsnGOAWvr0wlz8BfYCT KF9FSG4+wLnUifjymuiE7Q9MziyDA2paJWXOG5ZbRNhR3hvFj7eZhWBK00TiQ15RCJg2 d6dgorjhq3GtSikNm9baP9JCbut10J1Z98Crb6DYWnELX96aWxQ4o8zA1EbFD6ST5eKO Jtfg==
X-Gm-Message-State: AG10YOQEVMe5mKrVUB3gnM32O3dPJMyduNqVoA9CEmtrtoRYpBWlEp0bUx8ngpD6yOKxcQ==
X-Received: by 10.66.154.233 with SMTP id vr9mr32111104pab.66.1455651068994; Tue, 16 Feb 2016 11:31:08 -0800 (PST)
Received: from ?IPv6:2406:e007:666a:1:28cc:dc4c:9703:6781? ([2406:e007:666a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p8sm47568804pfi.34.2016.02.16.11.31.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 11:31:07 -0800 (PST)
To: joel jaeggli , Fernando Gont , Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com> <56C303EC.7040004@si6networks.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C378FD.7060903@gmail.com>
Date: Wed, 17 Feb 2016 08:31:09 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 19:31:11 -0000

On 17/02/2016 04:10, joel jaeggli wrote:
> On 2/16/16 3:11 AM, Fernando Gont wrote:
>> On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
>>> On 10/02/2016 10:41, Tom Herbert wrote:
>>>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>>>  wrote:
>>>>> Ole,
>>>>>
>>>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>>>> ...
>>>>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>>>>> anyone studied this over time?
>>>>>>>
>>>>>>> We're planning for the long term here. While I agree that this is a very
>>>>>>> interesting question, we shouldn't base future practice on it.
>>>>>>
>>>>>> I'm not sure what you imply by that.
>>>>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>>>
>>>>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>>>>> load balancing products that support the flow label, in order to create an incentive
>>>>> for users to run host stacks that set the flow label by default. Actually I think
>>>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>>>>> to 3-tuple if the transport header isn't the first Next Header.
>>>>>
>>>>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>>>>
>>>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>>>
>>>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
>>>> time now. Support was added in Linux to send non-zero flow labels by
>>>> default, Android will pick those up the next time they rebase (I still
>>>> don't know what the status is in Windows). In reality, setting the
>>>> flow label on the host is near zero cost and as long as network
>>>> devices are choking on them (we don't have any evidence of that)
>>>> there's no reason why we can't get to widespread usage in a relatively
>>>> short period of time.
>>>
>>> Windows 7 doesn't set any value by default, and I can't find a netshell
>>> command to switch it on. (I assume a TCP app can set it through the socket
>>> interface, but that's beside the point.)
>>
>> FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS
>> they would set the FL to zero, and once established it would be set to
>> non-zero.. not sure if this changed.
>>
>> In some scenarios (think SYN-cookies) this behavior might be difficult
>> to avoid.
> 
> right, if you want a flow label that is itself not derived from some
> deterministic transform you kind of have to keep track of what it is
> once you set it.

That's exactly why a stateless hash is the way to go, but certainly it
should be applied from the SYN packet onwards (in both directions).
I guess we should have specified that in RFC 6437.

   Brian

> 
> syn cookies causes a non-zero amount of breakage so it tends to be used
> sparingly but it remains an extremely useful tool under duress.
> 
>> Thanks!
>>
>> Cheers,
>>
> 
> 


From nobody Tue Feb 16 11:43:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076221B2CF7 for ; Tue, 16 Feb 2016 11:43:08 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjlbqlT-IW2c for ; Tue, 16 Feb 2016 11:43:02 -0800 (PST)
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 8D6EB1B2C18 for ; Tue, 16 Feb 2016 11:43:01 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 B610985297; Tue, 16 Feb 2016 20:42:57 +0100 (CET)
To: Brian E Carpenter , joel jaeggli , Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com> <56C303EC.7040004@si6networks.com>  <56C378FD.7060903@gmail.com>
From: Fernando Gont 
Message-ID: <56C37B45.8040701@si6networks.com>
Date: Tue, 16 Feb 2016 16:40:53 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C378FD.7060903@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 19:43:08 -0000

On 02/16/2016 04:31 PM, Brian E Carpenter wrote:
> On 17/02/2016 04:10, joel jaeggli wrote:
>> On 2/16/16 3:11 AM, Fernando Gont wrote:
>>> On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
>>>> On 10/02/2016 10:41, Tom Herbert wrote:
>>>>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>>>>  wrote:
>>>>>> Ole,
>>>>>>
>>>>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>>>>> ...
>>>>>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>>>>>> anyone studied this over time?
>>>>>>>>
>>>>>>>> We're planning for the long term here. While I agree that this is a very
>>>>>>>> interesting question, we shouldn't base future practice on it.
>>>>>>>
>>>>>>> I'm not sure what you imply by that.
>>>>>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>>>>
>>>>>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>>>>>> load balancing products that support the flow label, in order to create an incentive
>>>>>> for users to run host stacks that set the flow label by default. Actually I think
>>>>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>>>>>> to 3-tuple if the transport header isn't the first Next Header.
>>>>>>
>>>>>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>>>>>
>>>>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>>>>
>>>>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
>>>>> time now. Support was added in Linux to send non-zero flow labels by
>>>>> default, Android will pick those up the next time they rebase (I still
>>>>> don't know what the status is in Windows). In reality, setting the
>>>>> flow label on the host is near zero cost and as long as network
>>>>> devices are choking on them (we don't have any evidence of that)
>>>>> there's no reason why we can't get to widespread usage in a relatively
>>>>> short period of time.
>>>>
>>>> Windows 7 doesn't set any value by default, and I can't find a netshell
>>>> command to switch it on. (I assume a TCP app can set it through the socket
>>>> interface, but that's beside the point.)
>>>
>>> FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS
>>> they would set the FL to zero, and once established it would be set to
>>> non-zero.. not sure if this changed.
>>>
>>> In some scenarios (think SYN-cookies) this behavior might be difficult
>>> to avoid.
>>
>> right, if you want a flow label that is itself not derived from some
>> deterministic transform you kind of have to keep track of what it is
>> once you set it.
> 
> That's exactly why a stateless hash is the way to go, but certainly it
> should be applied from the SYN packet onwards (in both directions).
> I guess we should have specified that in RFC 6437.

I did something along those lines in:


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





From nobody Tue Feb 16 14:57:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595701AC44C for ; Tue, 16 Feb 2016 14:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSq_DTVdQP7R for ; Tue, 16 Feb 2016 14:57:07 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EE11AC44D for ; Tue, 16 Feb 2016 14:57:06 -0800 (PST)
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)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 191E71FCACD; Tue, 16 Feb 2016 22:57:03 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E5FB2160043; Tue, 16 Feb 2016 22:57:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D4902160085; Tue, 16 Feb 2016 22:57:01 +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 h-9Lp1rS-EVw; Tue, 16 Feb 2016 22:57:01 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 8E8AE160043; Tue, 16 Feb 2016 22:57:01 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AB4674252091; Wed, 17 Feb 2016 09:56:57 +1100 (EST)
To: Tim Chown 
From: Mark Andrews 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <55D51005-3098-43C6-9164-5903851133A1@ecs.soton.ac.uk> 
In-reply-to: Your message of "Thu, 11 Feb 2016 16:34:10 -0000." 
Date: Wed, 17 Feb 2016 09:56:57 +1100
Message-Id: <20160216225657.AB4674252091@rock.dv.isc.org>
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 22:57:09 -0000

In message , Tim Chown writes:
> > On 11 Feb 2016, at 00:33, Brian E Carpenter
>  wrote:
> >
> > On 11/02/2016 09:34, Dale W. Carder wrote:
> >> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016
> at 01:21:50PM -0300:
> >>>
> >>> * Section 3.2: Do folks really generate the prefixes as "required"?
> >>> Me, I confess I've used things like fc00:1::/64 because they are
> simpler
> >>> that some random string of bits.
> >>
> >> I absolutely do not believe it can be expected that sites will
> generate
> >> random prefixes.
> >
> > Why not, if it's a built-in feature of the CPE? Obviously, humans
> shouldn't
> > be messing around with these things.
>
> Sure, for a home network maybe. But in a campus youd probably form an
> address plan
> for your global prefix and map that to ULA space, e.g.
> 2001:db8:123:456::/64 would have
> a corresponding ULA prefix of fc00::123:456::/64.

No.  It would should be fdxx:xxxx:xxxx:0456::/64.  Where the x's
are randomly choosen nibbles (toss a fair coin 40 times - heads 1,
tails 0 to get the prefix bits).  So when you have 2 PA prefixes
you would have:

	2001:0db8:0123:0456::/64	provider 1 prefix 2001:0db8:0123::/48
	2001:0db8:eadf:0456::/64	provider 2 prefix 2001:0db8:eadf::/48
	fdxx:xxxx:xxxx:0456::/64	ULA prefix fdxx:xxxx:xxxx::/48

You DO NOT copy bits 33..48 from the PA address.  Yes, there are
shorter presentation forms of the above prefixes.  The leading zeros
are include for alignment purposes.

Note: that is "fdxx" not "fcxx" as they are Unique Local Assigned
prefixes.

> Not that Im aware of any campuses yet using ULAs.
>
> >> This will result in more NAT
> >
> > No. ULA is for internal traffic only. You use your ISP-provided prefix
> for
> > the Internet.
>
> Indeed. In theory.
>
> >> and all of the horror
> >> stories from rfc1918 getting copied over.  For a while someone (SixXS?)
> >> was running a ULA registry, but I am not sure what came of it.
> >>
> >
> > It's still there for people who believe it matters. I've never seen the
> > point, myself.
> > https://www.sixxs.net/tools/grh/ula/
>
> Dates back to the old ULA-C proposal, that died a death.
> I think thats draft-hain-ipv6-ulac-02.
>
> Tim
>
> >
> >   Brian
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Tue Feb 16 15:26:07 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986A91A8A87 for ; Tue, 16 Feb 2016 15:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level: 
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxpmSVRKwJII for ; Tue, 16 Feb 2016 15:26:04 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855921A8A7D for ; Tue, 16 Feb 2016 15:26:04 -0800 (PST)
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)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id E228A1FCAB8; Tue, 16 Feb 2016 23:26:00 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C5447160086; Tue, 16 Feb 2016 23:25:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B8D49160085; Tue, 16 Feb 2016 23:25:59 +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 9ncxNrtNbqp8; Tue, 16 Feb 2016 23:25:59 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 440F5160043; Tue, 16 Feb 2016 23:25:59 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 14A4E425236C; Wed, 17 Feb 2016 10:25:57 +1100 (EST)
To: "Dale W. Carder" 
From: Mark Andrews 
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
In-reply-to: Your message of "Thu, 11 Feb 2016 11:27:21 -0600." <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
Date: Wed, 17 Feb 2016 10:25:57 +1100
Message-Id: <20160216232557.14A4E425236C@rock.dv.isc.org>
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 23:26:06 -0000

In message <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>, "Dale W. Carder" writes:
> Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Thu, Feb 11, 2016 at 01:33:31PM +1300:
> > On 11/02/2016 09:34, Dale W. Carder wrote:
> > > Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
> > >>
> > >> * Section 3.2: Do folks really generate the prefixes as "required"?
> > >> Me, I confess I've used things like fc00:1::/64 because they are simpler
> > >> that some random string of bits.
> > > 
> > > I absolutely do not believe it can be expected that sites will generate 
> > > random prefixes.
> > 
> > Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
> > be messing around with these things.
> 
> Oh, I should clarify my concerns are not at the CPE level, but at the 
> enterprise scale where ULA may be used with human friendly / poorly chosen 
> prefixes that inevitably overlap.
> 
> > > This will result in more NAT
> ...
> > No. ULA is for internal traffic only. You use your ISP-provided prefix for
> > the Internet.
> 
> To clarify, to mitigate the ULA prefix overlap internally after a merger of 
> two internal networks, nothing related to off-site connectivity.  We
> have had this issue at our site on ipv4 when our healthcare system and campus 
> enterprise network ended up overlapping in 10/8 and needed NAT just to get 
> between the two, completely unrelated to off-site connectivity.  Having 
> first-hand experienced getting burned I hope we can emphasize the risk
> to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 
> networks.

And if you do.  You generate two new ULA prefixes which DO NOT
overlap with any of the existing ULA prefixes and migrate both sides
to using these and then stop advertising the old ULA prefix in RAs.
You mark the common ULA prefix as "not to be used" in case there
is still some configuration stanzas referencing it.  You don't NAT
between the two sites, you just pass routing information for the
new prefixes and block packets with the common prefix at the internal
border routers with a approriate ICMPv6 code returned.

	permit from any to self in ifX
	deny from prefix to any ICMPv6 ... in ifX
	deny from any to prefix ICMPv6 ... in ifX

where ifX is in the prefix site.  This allows applications to know
that the packets have been blocked, for TCP generate RST as it is
more reliable.

If the two sites are using a common border router then the border
router needs to know how to send reply traffic out the correct
interface.  pktinfo is useful for managing this at the application
layer.  For TCP the kernel will do the correct thing.  For UDP you
may need to request it.  We do this in named when managing DNS/UDP
responses.  Most of the time there will be a neutral link in between
two border routers so this is not a issue.

This is similar to how a site border router to the Internet is
configured except the prefix is fc00::/7 as you are blocking all
of the reserved range.

> I was going to make a similar comment that I initially withheld about
> section "6.1. Used in Isolated Networks" to which I would claim
> isolation, though often well-intended in my experience ends up being 
> temporary when it is found that devices later need external software
> updates, control, logging, or ancillary support systems for which
> proxying is too hard.  
> 
> If it's not obvious I do not like ULA at all, and I know a lot of the
> arguments have already been hashed out.  I am hoping that this
> guidance can at least be clear about the corners that people will (in 
> my mind) inevitably back themselves into so it can be avoided.  There's
> a lot of value getting that out.
> 
> Dale
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Tue Feb 16 15:29:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7F1ACCF0 for ; Tue, 16 Feb 2016 15:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWHpYA0hRcFr for ; Tue, 16 Feb 2016 15:29:07 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6271ACDA7 for ; Tue, 16 Feb 2016 15:29:06 -0800 (PST)
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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 71B483493BB; Tue, 16 Feb 2016 23:29:04 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 67997160043; Tue, 16 Feb 2016 23:29:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 520D1160085; Tue, 16 Feb 2016 23:29:04 +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 DndlJvCLa70q; Tue, 16 Feb 2016 23:29:04 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 0592B160043; Tue, 16 Feb 2016 23:29:04 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 461A44252450; Wed, 17 Feb 2016 10:29:02 +1100 (EST)
To: sthaug@nethelp.no
From: Mark Andrews 
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no>
In-reply-to: Your message of "Tue, 16 Feb 2016 08:51:20 +0100." <20160216.085120.74703683.sthaug@nethelp.no>
Date: Wed, 17 Feb 2016 10:29:02 +1100
Message-Id: <20160216232902.461A44252450@rock.dv.isc.org>
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Feb 2016 23:29:09 -0000

In message <20160216.085120.74703683.sthaug@nethelp.no>, sthaug@nethelp.no writes:
> > I believe we should not even suggest that it might be OK to allocate
> > manually. This draft isn't a BCP so we can use normal English, for
> > example:
> > 
> > o Prefix generation: prefixes must be randomly generated according
> >   to the algorithms defined in [RFC4193]. There are on-line tools
> >   available to do this interactively, if not performed automatically
> >   by the CPE. Manual assignment of easy-to-remember prefixes must
> >   never be done because of the high risk of collision, recreating
> >   the problems of [RFC1918].
> 
> Assume I want to number my lab using ULA. There's no way I'm going to
> be using randomly generated addresses - I want to have an *address
> plan*, and predictable addresses acording to a suitable pattern, just
> as I would do with regular IPv6 addresses.

With regular addresses the first 48 bits are given to you by the RIR
or ISP.  With ULA addresses we are saying generate the first 40 of the
first 48 bits randomly.  What is your issue here?
 
> Which means I'd probably ignore the above sentence of never doing
> manual assignment.
> 
> Yes, I understand what you're trying to do here - however, there are
> situations where this *will* be ignored.
> 
> Steinar Haug, AS2116
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Tue Feb 16 17:03:21 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953E41B2D1C for ; Tue, 16 Feb 2016 17:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC-TufnqjVGt for ; Tue, 16 Feb 2016 17:03:17 -0800 (PST)
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 879231B2CB7 for ; Tue, 16 Feb 2016 17:03:17 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id x65so1149887pfb.1 for ; Tue, 16 Feb 2016 17:03:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:references:from:organization:to:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9eK3HN6eF7NeBgB0MZ8IoIp29FNTxzoXhoJRsjyr/AA=; b=xHvq3LJoNUDw7VaMgQuR/n5UU2iIGGBqb7Boc1OuhRO9wqL3CvHoWLGvCS63hoPYwG lXJx3jrgbE7E8nftPMAQCVeFU6ukJhErBdhrAXKGmre4eHF1wcR07mcNGIT6WMraxh1u 08gcQ1Tn5GJ3MtycB2wylk/ytry5bgkDNneMFBfX0OcNq6sbDURlVCX+u59jtqxt9jNs YTU974hk1hBUP78s/lnCbAj55bqXyBLdnUHzJhXK20h+q3ZouraRsBCl4GO25w/7yA94 6IEnDBE1K5L5QknHddibMzP93XyAOV3t+D2clGpZhty6I/oYTNj8LgaVe51KSNFM+a3S M6HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:organization:to :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9eK3HN6eF7NeBgB0MZ8IoIp29FNTxzoXhoJRsjyr/AA=; b=IgD6PlX3CZlEipsp297VbukwUlB36JdwVk6h/SJ7XkOJxfse5F1nS7pU1giRzIdW03 kb+zOuo7MoFmSJBlh0zr1VyZ6Br7eo5+FxyEyaOpYL48Vi29pw57kMRF1cORQ/nJis6D j72uhG8yOZwYl1VtwQgAj6ogW+rv5Smkwh4QyS880ftLshSKator7yhl461Z1LY0Uuuy lZA365Na9R8N41kGG72enltc//mO2LLEe8xSrR2nm0p2cMCNpl/Fr2+J1Q1LKjI8LBhU 5awLBeSb+r7XkVkllypC5duE2RD3oT0RLlcv8DFx4+8hlwR0eFCyhjD7oJuET4NcD6ng UH6A==
X-Gm-Message-State: AG10YOQZ8XTObJJW4EDW1RRVNYkhyBBixq5lphyWgxs125aDJHYnSti+82FRQcSMjdz+dQ==
X-Received: by 10.98.2.21 with SMTP id 21mr35246884pfc.11.1455670997085; Tue, 16 Feb 2016 17:03:17 -0800 (PST)
Received: from ?IPv6:2406:e007:666a:1:28cc:dc4c:9703:6781? ([2406:e007:666a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id cq4sm48459356pad.28.2016.02.16.17.03.13 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 17:03:15 -0800 (PST)
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <56C2C4FC.5090003@si6networks.com>
From: Brian E Carpenter 
Organization: University of Auckland
To: v6ops@ietf.org
Message-ID: <56C3C6D6.8080001@gmail.com>
Date: Wed, 17 Feb 2016 14:03:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C2C4FC.5090003@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 01:03:19 -0000

On 16/02/2016 19:43, Fernando Gont wrote:
> On 02/10/2016 09:33 PM, Brian E Carpenter wrote:
>> On 11/02/2016 09:34, Dale W. Carder wrote:
>>> Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
>>>>
>>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>>>> that some random string of bits.
>>>
>>> I absolutely do not believe it can be expected that sites will generate 
>>> random prefixes.
>>
>> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
>> be messing around with these things.
> 
> I guess that the thing is that if for one reason or another you need to
> e.g. enforce ACLs or whatever,

The ACL in the CPE needs to filter fc00::/7 anyway. Internally,
the ULA prefix is a /48 so any internal ACLs will be based on
a longer prefix than the /48.

On 16/02/2016 20:51, sthaug@nethelp.no wrote:
...
> Assume I want to number my lab using ULA. There's no way I'm going to
> be using randomly generated addresses - I want to have an *address
> plan*, 

Yes, within the /48 that would be normal procedure. But the /48
itself is just an opaque bit string, like the GUA prefix that
my ISP gives me each time I restart the CPE. Yesterday it was
2406:e007:6fe2::/48, the day before it was 2406:e007:413e::/48.
I log it but I absolutely don't care about it.

> and predictable addresses acording to a suitable pattern, just
> as I would do with regular IPv6 addresses.
>
> Which means I'd probably ignore the above sentence of never doing
> manual assignment.

You generate an opaque value with https://www.sixxs.net/tools/grh/ula/
and use for the rest of your life, if you want. However, it will
be cut-and-paste unless you enjoy memorizing hex digits.

> Yes, I understand what you're trying to do here - however, there are
> situations where this *will* be ignored.

Very likely, but we must warn people anyway. However...

On 16/02/2016 19:43, Fernando Gont wrote:
...
> you want such prefixes to be "stable" --
> e.g., what if you replace the CPE?

This is an important point. In some contexts like a SOHO network, we
surely want any usage of ULAs to be fully automatic, even autonomic,
with no human intervention - dynamic DNS, automatic prefix assignment,
etc. So it's fine if replacing the CPE generates a new ULA prefix.
But in other contexts, such as a large enterprise network wishing
to use ULAs for all traffic inside the firewall, a fully automatic
solution may be unreasonable and we want the ULA prefix to be perennial.
In that case it needs to be handled by the same address management
mechanism or IPAM tool that's used for PA or PI prefixes.

This is a topic that we partly discussed in 6renum (RFC 6879and 7010).

   Brian


From nobody Wed Feb 17 00:26:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53F81B2A5C for ; Wed, 17 Feb 2016 00:26:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ewxl80FASrwx for ; Wed, 17 Feb 2016 00:26:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F501B346D for ; Wed, 17 Feb 2016 00:26:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEN49868; Wed, 17 Feb 2016 08:26:05 +0000 (GMT)
Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 08:26:04 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 08:25:57 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 16:25:50 +0800
From: "Liubing (Leo)" 
To: Fernando Gont 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
Thread-Index: AQHRZCBf+Tzq2HXT1E+bXAAC0O3fuZ8t+5Cg///czwCAAhaVkA==
Date: Wed, 17 Feb 2016 08:25:50 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D448F7@nkgeml514-mbx.china.huawei.com>
References: <56BB639E.5010505@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D44153@nkgeml514-mbx.china.huawei.com> <56C2DC98.70400@si6networks.com>
In-Reply-To: <56C2DC98.70400@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56C42E9D.0180, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3e7902eb6f7c54850cd609bcf253e16f
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 08:26:10 -0000

Hi Fernando,

> >> * Section 4.1, page 4:
> >>> IP is used ubiquitously.  Some networks like industrial control bus
> >>> (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces
> >>> like [MIL-STD-1397] have begun to use IP.  In these kinds of
> >>> networks, the system may lack the ability to communicate with the
> >>> public networks.
> >>
> >> Not sure what you mean by "may lack the ability...".
> > [Bing] These industrial networks might not support common Internet
> > services/functions such as HTTP, DNS etc., and they might not have the
> > requirement to talk to the nodes in the public Internet.
>=20
> This is more clear than the text in the I-D. I'd suggest you appy this to=
 the
> I-D.
[Bing] Ok, thanks.


> >> * Section 4.1, page 5:
> >>> o  Prefix generation: randomly generated according to the algorithms
> >>> defined in [RFC4193] or manually assigned.  Normally, automatic
> >>> generation of the prefixes is recommended, following [RFC4193]. If
> >>> there are some specific reasons that call for manual assignment,
> >>> administrators have to plan the prefixes carefully to avoid
> >>> collision.
> >>
> >> mm.. what do you mean exactly by "automatic generation"? -- In all
> >> those systems I have employed, the ULA prefixes are not generated
> >> automagically. -- you need to un the algorithm yourself, which means
> >> that the prefix is alwas manually configured (in the routers sending
> >> the RAs).
> > [Bing] I think we're talking the same thing. "Automatic generation"
> > means there is a function which aligns with the rules in 4193 in the
> > device/software to generate the prefixes. We never assign "random"
> > prefixes by our brains, unless there is no software available. I'll
> > make it more clearer in the next version.
>=20
> FWIW, general purpose operating systems (e.e. Linux) do not really have
> such a function.
[Bing] Ok, this is a useful note which could be included in the text.=20


> >> * Section 6.3.3, page 12:
> >>> ULAs could be self-generated and easily grabbed from the standard
> >>> IPv6 stack.  And ULAs don't need to be changed as the GUA prefixes
> >>> do.  So they are very suitable to be used as identifiers by the up
> >>> layer applications.  And since ULA is not intended to be globally
> >>> routed, it is not harmful to the routing system.
> >>
> >> Using IP addresses as identifiers in upper layers is a really bad
> >> idea.
> > [Bing] If we merge Section6 into Section4, would you share more
> > opinions of why it's bad to use it as identifier?
>=20
> One of the main reasons is that applications become tied to a layer-3
> protocol. It's better to use names rather than addresses. So I'd remove t=
he
> comment on using the addresses as identifiers in the upper layer protocol=
.
[Bing] I agree it's a layer violation in general consideration, although so=
metimes it really works. Maybe in the next version I don't rank it as "bene=
ficial", but as controversial, just like the ULA+NPTv6 case.

Thank again for your valuable comments.

Best regards,
Bing


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


From nobody Wed Feb 17 01:14:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F721B374F for ; Wed, 17 Feb 2016 01:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.607
X-Spam-Level: 
X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK62Xsvx8uQ2 for ; Wed, 17 Feb 2016 01:14:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DA81B374C for ; Wed, 17 Feb 2016 01:14:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIR63243; Wed, 17 Feb 2016 09:14:04 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Feb 2016 09:14:03 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 17:13:58 +0800
From: "Liubing (Leo)" 
To: "Dale W. Carder" , Brian E Carpenter 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
Thread-Index: AQHRZCBf+Tzq2HXT1E+bXAAC0O3fuZ8lNm6AgABC34CAARtDgIAJY8lA
Date: Wed, 17 Feb 2016 09:13:57 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D4491A@nkgeml514-mbx.china.huawei.com>
References: <56BB639E.5010505@si6networks.com> <20160210203411.GH387@DOIT-2NW1MRFY-X.doit.wisc.edu> <56BBD6DB.6020507@gmail.com> <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
In-Reply-To: <20160211172721.GA15156@DOIT-2NW1MRFY-X.doit.wisc.edu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010204.56C439DD.00A1, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a02e8ace60bb23b648c87ad1747c6dee
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 09:14:11 -0000

Hi Dale,

Thanks much for your elaborating explanation.=20
Replies inline.


> To clarify, to mitigate the ULA prefix overlap internally after a merger =
of two
> internal networks, nothing related to off-site connectivity.  We have had
> this issue at our site on ipv4 when our healthcare system and campus
> enterprise network ended up overlapping in 10/8 and needed NAT just to ge=
t
> between the two, completely unrelated to off-site connectivity.  Having
> first-hand experienced getting burned I hope we can emphasize the risk to
> avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE)
> networks.

> I was going to make a similar comment that I initially withheld about sec=
tion
> "6.1. Used in Isolated Networks" to which I would claim isolation, though
> often well-intended in my experience ends up being temporary when it is
> found that devices later need external software updates, control, logging=
, or
> ancillary support systems for which proxying is too hard.
>=20
> If it's not obvious I do not like ULA at all, and I know a lot of the arg=
uments
> have already been hashed out.  I am hoping that this guidance can at leas=
t
> be clear about the corners that people will (in my mind) inevitably back
> themselves into so it can be avoided.  There's a lot of value getting tha=
t
> out.

[Bing] From your above comments, I read two warnings:
1. Warning people that when they use human-friendly/poorly-chosen ULA prefi=
xes, it might result in renumbering or ULA-to-ULA NAT if collision happens =
when sites merging.
2. Warning people that isolation would be probably temporary, when connecte=
d, they either deal with ULA+PA, or they'll have to let NAT/proxy involved.

In current Section 4.1, there is some text discuss the two points a bit, bu=
t I think the text needs to be tilt up and be put at a more noteworthy plac=
e in the next version. Thanks for raising these issues up.

Best regards,
Bing

> Dale
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Feb 17 03:23:59 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5FA1B3945 for ; Wed, 17 Feb 2016 03:23:57 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTzo6qXFvY66 for ; Wed, 17 Feb 2016 03:23:54 -0800 (PST)
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 2C7091B3946 for ; Wed, 17 Feb 2016 03:23:54 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aW0D2-0000F2C; Wed, 17 Feb 2016 12:23:52 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org>  <56C2DF32.3010901@si6networks.com>   <56C34009.1070 508@si6networks.com> 
In-reply-to: Your message of "Tue, 16 Feb 2016 12:28:09 -0300 ." <56C34009.1070508@si6networks.com> 
Date: Wed, 17 Feb 2016 12:23:50 +0100
Archived-At: 
Cc: Fernando Gont 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 11:23:57 -0000

>On 02/16/2016 12:13 PM, Warren Kumari wrote:
>>     The operator adds the number when it is determined to be perfectly
>>     safe (that I find unlikely for new extension headers) and enough people
>>     are speaking up that the operator is a aware of the problem.
>> 
>> 
>> This also requires that the application developer makes a judgment call
>> as to when it is safe to be able to enable this unknown EH.
>> So, after all middle boxes support "safe-unknown-extension-headers" we need:
>> A: the new unknown EH written
>> B: someone to be brave enough to try using it (and have it fail in many
>> / most cases)
>> C: a large upswell of people going around an poking operators (including
>> Billybob, who runs the edge middlebox "protecting" Henrys Tire and Wheel
>> Balancing, Middleburg, VA) to get them to log onto all their devices and
>> add this new EH to the list of safe things
>> D: More applications to try using this and have it fail elegantly in
>> some set of conditions
>> E: outreach to once again poke Billybob, who replaced his middlebox with
>> the backup one which lives in the spares closet and wasn't turned on in
>> step C.
>> F: application developers to have enough faith that this will work 100%
>> of the time (keeping in mind that they got bitten in B and D) to turn it on.
>> 
>> This EH would need to provide some *really* compelling benefit to make
>> this process worthwhile. 
>
>I think I learned a long-version of the English word "never" (?). :-)

I don't see anything that we do about this at the protocol level. Do you want
to allocate a not-evil bit that can be set on extension headers? "This
unknown extension header is IETF certified to be not evil, please pass it
along unchecked".



From nobody Wed Feb 17 06:23:54 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B081B31E0 for ; Wed, 17 Feb 2016 06:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ6dSrvjZ6Ts for ; Wed, 17 Feb 2016 06:23:51 -0800 (PST)
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 A7AE21B351E for ; Wed, 17 Feb 2016 06:23:51 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id u200so13961549ywf.0 for ; Wed, 17 Feb 2016 06:23:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=MLkJWCjEdrKbOtBC01aBiILGDXvXXHrsdn3zs5eU2pc=; b=nYuT8A+dHhpFFQys1sKMf4ABCZg8vbL6f3zv8V34b07qrEHax45fXp9oIffyWynupu zCt3rjguBiTLTb4dti5oYUX0CjPYDps6+wlfNcTGMvTVs7P8WEIXH+KwgCpStmRCKd1D bDE7EFFkr1+enTMkuQnJMDTEz46qA+lceyHy/gCX/3CO1xmR2m5yDkwjA4tN8ektlRW9 GgQPm6OejmLn0t0vADNvt6SzgXMNgCKDemUMinXdHAWCf3nSdQQKeNxm9S8Hx/vcgxGj 9qa2I3xQH2edYZaBc6sTjKpRyS1LcIgWpDjyfcELTg+Dc935tR1fb5xflVBMoDjqraW0 w8jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=MLkJWCjEdrKbOtBC01aBiILGDXvXXHrsdn3zs5eU2pc=; b=LFUu11OXJP2y+Qy2/8okF4V5SmvEbFp/xms8Uxzpf3TyupWHP7pUNQdoQGBOMpf3io qzvdKgS3HANjWRDrpgdGTIEQ8/TWD5Ut3/xO59jAi6RdWr7hkpNmx6x1WkbhqH8Xn2VA I8OARazEdGB6aV1ujIZsd+YJRDiy9ciRbfBfJ5cXWAGiNme5VH6wkmLSEmn2eE3CEwSI we7Od678L+96XV/n2FRKQYNDq0bvF2vf8Ki+frGEkqsti3EZ+kkLhjdMYzV6/P9gyMMR mZPZMtkWqBa5sLqLTzh/CeYTfnJPuB0BGbHTeDKjV72RsPniwgL/PuQKmc37UEIeSbpr kLxw==
X-Gm-Message-State: AG10YORN2hhq1vwIf99TJMLuXdFtji5rw84Q2UVjfmDrOMY930Q8WfvKv8t8d6FmkDeSI7f+ommzxdOqiU5ghCSC
X-Received: by 10.129.70.8 with SMTP id t8mr942865ywa.105.1455719030898; Wed, 17 Feb 2016 06:23:50 -0800 (PST)
MIME-Version: 1.0
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8BA32.3010505@foobar.org> <56B8F12F.30307@isi.edu> <56B90B6C.9060105@si6networks.com> <56B90E16.1090402@gmail.com> <56B933A4.6060405@si6networks.com>  <74B4E9A1-E6FE-40C0-9EC9-0C2C5172A246@employees.org> <6E0AE4AB-330D-4670-9EF0-21F8E43AC6CB@employees.org>  <56C2DF32.3010901@si6networks.com>   <56C34009.1070508@si6networks.com> 
In-Reply-To: 
From: Warren Kumari 
Date: Wed, 17 Feb 2016 14:23:41 +0000
Message-ID: 
To: Philip Homburg , v6ops@ietf.org
Content-Type: multipart/alternative; boundary=001a114d71a8bb2045052bf7ff34
Archived-At: 
Cc: Fernando Gont 
Subject: Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 14:23:53 -0000

--001a114d71a8bb2045052bf7ff34
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 17, 2016 at 6:23 AM Philip Homburg 
wrote:

> >On 02/16/2016 12:13 PM, Warren Kumari wrote:
> >>     The operator adds the number when it is determined to be perfectly
> >>     safe (that I find unlikely for new extension headers) and enough
> people
> >>     are speaking up that the operator is a aware of the problem.
> >>
> >>
> >> This also requires that the application developer makes a judgment call
> >> as to when it is safe to be able to enable this unknown EH.
> >> So, after all middle boxes support "safe-unknown-extension-headers" we
> need:
> >> A: the new unknown EH written
> >> B: someone to be brave enough to try using it (and have it fail in many
> >> / most cases)
> >> C: a large upswell of people going around an poking operators (including
> >> Billybob, who runs the edge middlebox "protecting" Henrys Tire and Wheel
> >> Balancing, Middleburg, VA) to get them to log onto all their devices and
> >> add this new EH to the list of safe things
> >> D: More applications to try using this and have it fail elegantly in
> >> some set of conditions
> >> E: outreach to once again poke Billybob, who replaced his middlebox with
> >> the backup one which lives in the spares closet and wasn't turned on in
> >> step C.
> >> F: application developers to have enough faith that this will work 100%
> >> of the time (keeping in mind that they got bitten in B and D) to turn
> it on.
> >>
> >> This EH would need to provide some *really* compelling benefit to make
> >> this process worthwhile.
> >
> >I think I learned a long-version of the English word "never" (?). :-)
>
> I don't see anything that we do about this at the protocol level.


I fully agree -- and yet we seem to keep trying to...


> Do you want
> to allocate a not-evil bit that can be set on extension headers? "This
> unknown extension header is IETF certified to be not evil, please pass it
> along unchecked".
>
>
That sounds like a grand idea! Let's do that!

More seriously, I think that new EH (and "long" chains") simply won't fly,
that we should admit this and get on with fixing the other issues.
Yes, v6 was supposed to be the grand panacea, curing all ills and being
infinitely extensible - but it turns out that (just like for the
alchemists) the real world gets in the way. Shaking your fists at the gods
and demanding that the world change simply makes your feet sore and your
arm tired :-)

W

--001a114d71a8bb2045052bf7ff34
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wed, Fe=
b 17, 2016 at 6:23 AM Philip Homburg <pch-v6ops-4@u-1.phicoh.com> wrote:
>On 02/16/2016 12:13 PM, Warren Kumari wrote:

>>=C2=A0 =C2=A0 =C2=A0The operator adds the number when it is determi=
ned to be perfectly

>>=C2=A0 =C2=A0 =C2=A0safe (that I find unlikely for new extension he=
aders) and enough people

>>=C2=A0 =C2=A0 =C2=A0are speaking up that the operator is a aware of=
 the problem.

>>

>>

>> This also requires that the application developer makes a judgment=
 call

>> as to when it is safe to be able to enable this unknown EH.

>> So, after all middle boxes support "safe-unknown-extension-he=
aders" we need:

>> A: the new unknown EH written

>> B: someone to be brave enough to try using it (and have it fail in=
 many

>> / most cases)

>> C: a large upswell of people going around an poking operators (inc=
luding

>> Billybob, who runs the edge middlebox "protecting" Henry=
s Tire and Wheel

>> Balancing, Middleburg, VA) to get them to log onto all their devic=
es and

>> add this new EH to the list of safe things

>> D: More applications to try using this and have it fail elegantly =
in

>> some set of conditions

>> E: outreach to once again poke Billybob, who replaced his middlebo=
x with

>> the backup one which lives in the spares closet and wasn't tur=
ned on in

>> step C.

>> F: application developers to have enough faith that this will work=
 100%

>> of the time (keeping in mind that they got bitten in B and D) to t=
urn it on.

>>

>> This EH would need to provide some *really* compelling benefit to =
make

>> this process worthwhile.

>

>I think I learned a long-version of the English word "never" =
(?). :-)



I don't see anything that we do about this at the protocol level. 

I fully agree -- and yet we seem to keep trying=
 to...
=C2=A0
Do you want

to allocate a not-evil bit that can be set on extension headers? "This=


unknown extension header is IETF certified to be not evil, please pass it
along unchecked".



That sounds like a grand idea! Let'=
;s do that!

More seriously, I think that new EH (a=
nd "long" chains") simply won't fly, that we should admi=
t this and get on with fixing the other issues.
Yes, v6 was suppo=
sed to be the grand panacea, curing all ills and being infinitely extensibl=
e - but it turns out that (just like for the alchemists) the real world get=
s in the way. Shaking your fists at the gods and demanding that the world c=
hange simply makes your feet sore and your arm tired :-)

W



--001a114d71a8bb2045052bf7ff34--


From nobody Wed Feb 17 07:25:23 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4534B1A702C for ; Wed, 17 Feb 2016 07:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKNwA3op0Slg for ; Wed, 17 Feb 2016 07:25:20 -0800 (PST)
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 4C5501A700F for ; Wed, 17 Feb 2016 07:25:20 -0800 (PST)
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 u1HFPI8j008629 for ; Wed, 17 Feb 2016 16:25:18 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2E0D2080A4 for ; Wed, 17 Feb 2016 16:33:45 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9B68208046 for ; Wed, 17 Feb 2016 16:33:45 +0100 (CET)
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 u1HFPI7s011013 for ; Wed, 17 Feb 2016 16:25:18 +0100
To: "v6ops@ietf.org" 
References: <20140626205546.713F21801AE@rfc-editor.org>
From: Alexandre Petrescu 
Message-ID: <56C490DE.8000406@gmail.com>
Date: Wed, 17 Feb 2016 16:25:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20140626205546.713F21801AE@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 15:25:22 -0000

Hi,

I have a comment on this RFC7278.

The comment comes from the observation that the operator also uses an 
address from the 64share prefix (a global address).

As such that address too should not be used in the 'LAN'.

This may lead to several textual modifications to the document.  For 
example:
> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.

This is wrongly stated, because the UE does not own that prefix, so it 
can't say "its IPv6 addresses".  That prefix is belonging to a link not 
to the UE, because the operator also makes an address out of it.

Alex

Le 26/06/2014 22:55, rfc-editor@rfc-editor.org a écrit :
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 7278
>
>          Title:      Extending an IPv6 /64 Prefix from
>                      a Third Generation Partnership Project (3GPP)
>                      Mobile Interface to a LAN Link
>          Author:     C. Byrne,
>                      D. Drown,
>                      A. Vizdal
>          Status:     Informational
>          Stream:     IETF
>          Date:       June 2014
>          Mailbox:    cameron.byrne@t-mobile.com,
>                      dan@drown.org,
>                      ales.vizdal@t-mobile.cz
>          Pages:      10
>          Characters: 19965
>          Updates/Obsoletes/SeeAlso:   None
>
>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>
>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>
> This document describes requirements for extending an IPv6 /64 prefix
> from a User Equipment Third Generation Partnership Project (3GPP)
> radio interface to a LAN link and describes two implementation
> examples.
>
> This document is a product of the IPv6 Operations Working Group of the IETF.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    http://www.ietf.org/mailman/listinfo/ietf-announce
>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/search
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
>


From nobody Wed Feb 17 07:26:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827D51A0015 for ; Wed, 17 Feb 2016 07:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PFYiX-xofwd for ; Wed, 17 Feb 2016 07:26:46 -0800 (PST)
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 E167A1A6FA3 for ; Wed, 17 Feb 2016 07:26:38 -0800 (PST)
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 u1HFQauA032697 for ; Wed, 17 Feb 2016 16:26:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D142A2080BA for ; Wed, 17 Feb 2016 16:35:03 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C86592080A4 for ; Wed, 17 Feb 2016 16:35:03 +0100 (CET)
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 u1HFQaOg012022 for ; Wed, 17 Feb 2016 16:26:36 +0100
From: Alexandre Petrescu 
To: "v6ops@ietf.org" 
References: <20140626205546.713F21801AE@rfc-editor.org>
Message-ID: <56C4912C.6010806@gmail.com>
Date: Wed, 17 Feb 2016 16:26:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20140626205546.713F21801AE@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 15:26:48 -0000

Hi,

I have a comment on this RFC7278.

The comment comes from the observation that the operator also uses an 
address from the 64share prefix (a global address).

As such that address too should not be used in the 'LAN'.

This may lead to several textual modifications to the document.  For 
example:
> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.

This is wrongly stated, because the UE does not own that prefix, so it 
can't say "its IPv6 addresses".  That prefix is belonging to a link not 
to the UE, because the operator also makes an address out of it.

Alex

Le 26/06/2014 22:55, rfc-editor@rfc-editor.org a écrit :
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 7278
>
>          Title:      Extending an IPv6 /64 Prefix from
>                      a Third Generation Partnership Project (3GPP)
>                      Mobile Interface to a LAN Link
>          Author:     C. Byrne,
>                      D. Drown,
>                      A. Vizdal
>          Status:     Informational
>          Stream:     IETF
>          Date:       June 2014
>          Mailbox:    cameron.byrne@t-mobile.com,
>                      dan@drown.org,
>                      ales.vizdal@t-mobile.cz
>          Pages:      10
>          Characters: 19965
>          Updates/Obsoletes/SeeAlso:   None
>
>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>
>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>
> This document describes requirements for extending an IPv6 /64 prefix
> from a User Equipment Third Generation Partnership Project (3GPP)
> radio interface to a LAN link and describes two implementation
> examples.
>
> This document is a product of the IPv6 Operations Working Group of the IETF.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    http://www.ietf.org/mailman/listinfo/ietf-announce
>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/search
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
>


From nobody Wed Feb 17 08:45:47 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A221A9145 for ; Wed, 17 Feb 2016 08:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHinJfLJrRSB for ; Wed, 17 Feb 2016 08:45:44 -0800 (PST)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 17D911A9142 for ; Wed, 17 Feb 2016 08:45:44 -0800 (PST)
Received: by mail-ig0-x22b.google.com with SMTP id y8so19042370igp.1 for ; Wed, 17 Feb 2016 08:45:44 -0800 (PST)
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-type; bh=S6Zv0EFcAuhanhFwKnjAfkJXpwSb0GhDL8mjCgBq8oI=; b=rmRQIkOqqOLf8w92i71/chGDjZa1N23r+lzzaXXr76/3clcWKypx7bl2zcXGpnCs6t LwDwzRHY5QCD5a6AvLLM8LcjIITcxi1Ge3w0UEbPYffFzOfrGjVBOCBtuTE1KjEgB2Np WfubIqguG6DvtkOhUqfUJSn9XeK10ijfhbBt6NlUCZy/IVS4oyYgaLZeAg687O8+uoHo WRUXEJozB9ZdTCcSZfBWZsyiJmrhwf1Sjyug6YWSeExMAlX7sf9uHvViqEgR/2IUMip+ cC4pZ7tQ8ocmlaLUWCV4nScsrfbC+6eQeQ/IN+o23uWe/UMmIMzZJDqIqWHa7NKBDMJI dKRQ==
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-type; bh=S6Zv0EFcAuhanhFwKnjAfkJXpwSb0GhDL8mjCgBq8oI=; b=KZwz345zwIFi+Vf/vzfRfE5rea9TmH1YBvmBbhLTLR8R39gbcj6HW4TvilfbAEZydE GEMLdxklYehf2bQFo9qB5lKJeUJhyIUDDR0CumgvyME8T0sMzo4JiSNHZWwZjbQTTgAW yL+eAwVQVGzuLqh/baLGL1j/MYYOoJOKYfjarWYWU1eCrZzu1SqnuXN9U8QnUKniC+EB 6i+nAuIDUXFdSy9UjAGNYMWcs/DcjJ3jBhx8k8gy0YEudu2dYNGhZ2PWC/19RE6ISqT/ +i77Y6KFLsa8kzRYbLiERvlMro+i2+SgRKMnPq7w5yZ7a8UWGl6XnfGRa95802MFfLZ8 dIBg==
X-Gm-Message-State: AG10YORmHHJRhMl7hOqnYlVVekQLdROIvIU0Fu2sO8xu5K1gcy54MK07lME5v/tHK7D/GFLqvW57TdOSlpO9+w==
MIME-Version: 1.0
X-Received: by 10.50.87.7 with SMTP id t7mr26178287igz.65.1455727543309; Wed, 17 Feb 2016 08:45:43 -0800 (PST)
Received: by 10.107.160.203 with HTTP; Wed, 17 Feb 2016 08:45:43 -0800 (PST)
In-Reply-To: <56C378FD.7060903@gmail.com>
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <20160205154722.GQ58491@Space.Net> <56B4C527.1040600@isi.edu> <56B4CDDD.9080006@foobar.org> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com> <56C303EC.7040004@si6networks.com>  <56C378FD.7060903@gmail.com>
Date: Wed, 17 Feb 2016 08:45:43 -0800
Message-ID: 
From: Tom Herbert 
To: Brian E Carpenter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Fernando Gont , v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 16:45:45 -0000

On Tue, Feb 16, 2016 at 11:31 AM, Brian E Carpenter
 wrote:
> On 17/02/2016 04:10, joel jaeggli wrote:
>> On 2/16/16 3:11 AM, Fernando Gont wrote:
>>> On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
>>>> On 10/02/2016 10:41, Tom Herbert wrote:
>>>>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>>>>  wrote:
>>>>>> Ole,
>>>>>>
>>>>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>>>>> ...
>>>>>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>>>>>> anyone studied this over time?
>>>>>>>>
>>>>>>>> We're planning for the long term here. While I agree that this is a very
>>>>>>>> interesting question, we shouldn't base future practice on it.
>>>>>>>
>>>>>>> I'm not sure what you imply by that.
>>>>>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>>>>
>>>>>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>>>>>> load balancing products that support the flow label, in order to create an incentive
>>>>>> for users to run host stacks that set the flow label by default. Actually I think
>>>>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>>>>>> to 3-tuple if the transport header isn't the first Next Header.
>>>>>>
>>>>>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>>>>>
>>>>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>>>>
>>>>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
>>>>> time now. Support was added in Linux to send non-zero flow labels by
>>>>> default, Android will pick those up the next time they rebase (I still
>>>>> don't know what the status is in Windows). In reality, setting the
>>>>> flow label on the host is near zero cost and as long as network
>>>>> devices are choking on them (we don't have any evidence of that)
>>>>> there's no reason why we can't get to widespread usage in a relatively
>>>>> short period of time.
>>>>
>>>> Windows 7 doesn't set any value by default, and I can't find a netshell
>>>> command to switch it on. (I assume a TCP app can set it through the socket
>>>> interface, but that's beside the point.)
>>>
>>> FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS
>>> they would set the FL to zero, and once established it would be set to
>>> non-zero.. not sure if this changed.
>>>
>>> In some scenarios (think SYN-cookies) this behavior might be difficult
>>> to avoid.
>>
>> right, if you want a flow label that is itself not derived from some
>> deterministic transform you kind of have to keep track of what it is
>> once you set it.
>
> That's exactly why a stateless hash is the way to go, but certainly it
> should be applied from the SYN packet onwards (in both directions).
> I guess we should have specified that in RFC 6437.
>
I didn't see any requirement in RFC6437 that the flow label must be
persistent for the lifetime of a flow (e.g. TCP connection). In fact,
we implemented a facility that will recompute the flow label for a
failing connection (random value assigned) in hopes of getting a
different route through ECMP. This is a nice feature in IPv6 since we
can't change the four tuple for an existing connection to get that
same effect in IPv4. If intermediate devices drop packets because the
flow label doesn't match what they think it should be this will be a
problem...

Tom


>    Brian
>
>>
>> syn cookies causes a non-zero amount of breakage so it tends to be used
>> sparingly but it remains an extremely useful tool under duress.
>>
>>> Thanks!
>>>
>>> Cheers,
>>>
>>
>>


From nobody Wed Feb 17 09:16:44 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACD01A1B5A for ; Wed, 17 Feb 2016 07:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq3plI8w5OLq for ; Wed, 17 Feb 2016 07:22:07 -0800 (PST)
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 99E191A1AF0 for ; Wed, 17 Feb 2016 07:22:07 -0800 (PST)
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 u1HFM5NZ006580; Wed, 17 Feb 2016 16:22:05 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82BE32080B7; Wed, 17 Feb 2016 16:30:32 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D9CA208059; Wed, 17 Feb 2016 16:30:32 +0100 (CET)
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 u1HFM5d5008462; Wed, 17 Feb 2016 16:22:05 +0100
To: holger.metschulat@telekom.de, v6ops@ietf.org
References:  <5587EFDD.6030807@gmail.com>    <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com>
From: Alexandru Petrescu 
Message-ID: <56C4901D.3080701@gmail.com>
Date: Wed, 17 Feb 2016 16:22:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Wed, 17 Feb 2016 09:16:43 -0800
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 15:22:14 -0000

Le 29/06/2015 14:51, holger.metschulat@telekom.de a écrit :
> Hi,
>
>> Android is a linux based os, I dont see why it wouldnt support
>> dhcp-pd?
>
>> My linux based non-Android machines do dhcp-pd ok.
>
> Have you tried to run DHCP-PD via IPv6-capable USB dongles?

Hi,

I just tried DHCPv6 in an M2M module (sierra's airprime) which can be
considered to be a USB dongle.  It can not execute any of the 3 DHCPv6
implementations, so no it does not run PD.

Alex

> The ones that I know of don't forward DHCPv6 requests to the network.
> So even if your OS supports it, it's most likely that you modem (or
> its chipset) does not support it.
>


From nobody Wed Feb 17 11:56:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B7D1A882F for ; Wed, 17 Feb 2016 11:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-BiDusTieNQ for ; Wed, 17 Feb 2016 11:56:45 -0800 (PST)
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 291921A8A51 for ; Wed, 17 Feb 2016 11:56:45 -0800 (PST)
Received: by mail-vk0-x22b.google.com with SMTP id e185so24774341vkb.1 for ; Wed, 17 Feb 2016 11:56:45 -0800 (PST)
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:content-type; bh=7woHfGsYc3ZzFo0Ek40dlgHbhwckI+2JMz8ODBu8wUk=; b=xVKK2kQEQlbtJNV1egRo8jAf8OUZtwKG69W3KAZZuLXozSebsYo0uGPINW+2D2/a6z WrpTY66h9CtwfOIjBT3FA2NvIm72iNh9Y/Kp0NiimMn8JZQsqBckq5VK3GSytGDzDp3J ZkoBwJfR38ntg5U1HcZg+GwdEgUnA306w4DdWROdshVG4goPgN9kg0BIzY0UBWSvWnxW E4jHtnk/wLlGk/BuFxEo4Ka4/WYk5TpMV5PGFtH2cQzJ6VKWazBZoSggWmsI37NgBuuA bEwUf2NILPaApbqV0bj4dVHGEFJOUtlQzePGirEhkSOiyCoanfHEQfSHn2Sz7P7Xf7cl 7+aw==
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-type; bh=7woHfGsYc3ZzFo0Ek40dlgHbhwckI+2JMz8ODBu8wUk=; b=JopB1QLlKwHQfJqC7G0UykOKOffRahZ1B30XK5uTgwWtWoSkWi7gHfaLy6PBJfhgKe N+yY4MNx9PKu52xNaao7m3GNrJhWJ3HAg1XjXQXeG/UuGkOuwAbwy6pLfvwxO5Cs/MTs 1mhfhqx8GprRea42aUMHU/Af5dZHDNRhwzMFFtXlGXgACZK/XDwPVJ5qhL6NbwCufg95 VbPwImhAKiPKn5NnYXD/2G5DavYvD0+CFVDHw4/3c2GhzzVpYlXeFdU2xneM7tWydrUU FKGBRkL+6rFrm7jEI2Wb+vxuD1CD7dLl7RNqWHd5GTm4kTrPtLD6qlaj+JBnL+f4glto HqGg==
X-Gm-Message-State: AG10YOQmU8JtzsR0+HIugs+p3M1cS+IS7IKJLvGoxEQA9u7jX63vRlhghIsUI0BtfntGHOWeuQF3x0KMiSom8g==
MIME-Version: 1.0
X-Received: by 10.31.162.20 with SMTP id l20mr2583147vke.137.1455739004147; Wed, 17 Feb 2016 11:56:44 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Wed, 17 Feb 2016 11:56:43 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Wed, 17 Feb 2016 11:56:43 -0800 (PST)
In-Reply-To: <56C490DE.8000406@gmail.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>
Date: Thu, 18 Feb 2016 06:56:43 +1100
Message-ID: 
From: Mark Smith 
To: Alexandre Petrescu 
Content-Type: multipart/alternative; boundary=001a1143f2ac3a5cda052bfca657
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 19:56:47 -0000

--001a1143f2ac3a5cda052bfca657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 18 Feb 2016 2:26 AM, "Alexandre Petrescu" 
wrote:
>
> Hi,
>
> I have a comment on this RFC7278.
>
> The comment comes from the observation that the operator also uses an
address from the 64share prefix (a global address).
>

Are you sure about that? It was my understanding that the unconventional
thing about a 3GPP setup was that all traffic to all addresses within the
/64 was (blindly) forwarded to the UE, even if the UE uses one or more of
those addresses on the end of the link. I think that is only possible
because the link is a point to point one.

(Presumably the UE has a discard route for the /64 to prevent loops for
non-existent addresses.)

> As such that address too should not be used in the 'LAN'.
>
> This may lead to several textual modifications to the document.  For
example:
>>
>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.
>
>
> This is wrongly stated, because the UE does not own that prefix, so it
can't say "its IPv6 addresses".  That prefix is belonging to a link not to
the UE, because the operator also makes an address out of it.
>
> Alex
>
> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org a =C3=A9crit :
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>>
>>          RFC 7278
>>
>>          Title:      Extending an IPv6 /64 Prefix from
>>                      a Third Generation Partnership Project (3GPP)
>>                      Mobile Interface to a LAN Link
>>          Author:     C. Byrne,
>>                      D. Drown,
>>                      A. Vizdal
>>          Status:     Informational
>>          Stream:     IETF
>>          Date:       June 2014
>>          Mailbox:    cameron.byrne@t-mobile.com,
>>                      dan@drown.org,
>>                      ales.vizdal@t-mobile.cz
>>          Pages:      10
>>          Characters: 19965
>>          Updates/Obsoletes/SeeAlso:   None
>>
>>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>
>>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>>
>> This document describes requirements for extending an IPv6 /64 prefix
>> from a User Equipment Third Generation Partnership Project (3GPP)
>> radio interface to a LAN link and describes two implementation
>> examples.
>>
>> This document is a product of the IPv6 Operations Working Group of the
IETF.
>>
>>
>> INFORMATIONAL: This memo provides information for the Internet community=
.
>> It does not specify an Internet standard of any kind. Distribution of
>> this memo is unlimited.
>>
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>    http://www.ietf.org/mailman/listinfo/ietf-announce
>>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>
>> For searching the RFC series, see http://www.rfc-editor.org/search
>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>>
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>>
>>
>> The RFC Editor Team
>> Association Management Solutions, LLC
>>
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a1143f2ac3a5cda052bfca657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 18 Feb 2016 2:26 AM, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:=


>

> Hi,

>

> I have a comment on this RFC7278.

>

> The comment comes from the observation that the operator also uses an =
address from the 64share prefix (a global address).

>


Are you sure about that? It was my understanding that the un=
conventional thing about a 3GPP setup was that all traffic to all addresses=
 within the /64 was (blindly) forwarded to the UE, even if the UE uses one =
or more of those addresses on the end of the link. I think that is only pos=
sible because the link is a point to point one.


(Presumably the UE has a discard route for the /64 to preven=
t loops for non-existent addresses.)


> As such that address too should not be used in the '=
;LAN'.

>

> This may lead to several textual modifications to the document.=C2=A0 =
For example:

>>

>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.=


>

>

> This is wrongly stated, because the UE does not own that prefix, so it=
 can't say "its IPv6 addresses".=C2=A0 That prefix is belongi=
ng to a link not to the UE, because the operator also makes an address out =
of it.

>

> Alex

>

> Le 26/06/2014 22:55, rfc-=
editor@rfc-editor.org a =C3=A9crit :

>>

>> A new Request for Comments is now available in online RFC librarie=
s.

>>

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 7278

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 Exten=
ding an IPv6 /64 Prefix from

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0a Third Generation Partnership Project (3GPP)

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Mobile Interface to a LAN Link

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author:=C2=A0 =C2=A0 =C2=A0C. By=
rne,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0D. Drown,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0A. Vizdal

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status:=C2=A0 =C2=A0 =C2=A0Infor=
mational

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream:=C2=A0 =C2=A0 =C2=A0IETF<=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
June 2014

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mailbox:=C2=A0 =C2=A0 cameron.byrne@t-mobile.com,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0dan@drown.org,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ales.vizdal@t-mobile.c=
z

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2=A0 10
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Characters: 19965

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Updates/Obsoletes/SeeAlso:=C2=A0=
 =C2=A0None

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I-D Tag:=C2=A0 =C2=A0 draft-ietf=
-v6ops-64share-10.txt

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
http://www.rfc-editor=
.org/rfc/rfc7278.txt

>>

>> This document describes requirements for extending an IPv6 /64 pre=
fix

>> from a User Equipment Third Generation Partnership Project (3GPP)<=
br>
>> radio interface to a LAN link and describes two implementation

>> examples.

>>

>> This document is a product of the IPv6 Operations Working Group of=
 the IETF.

>>

>>

>> INFORMATIONAL: This memo provides information for the Internet com=
munity.

>> It does not specify an Internet standard of any kind. Distribution=
 of

>> this memo is unlimited.

>>

>> This announcement is sent to the IETF-Announce and rfc-dist lists.=


>> To subscribe or unsubscribe, see

>> =C2=A0 =C2=A0http://www.ietf.org/mailman/listinfo/ietf-announce

>> =C2=A0 =C2=A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<=
br>
>>

>> For searching the RFC series, see http://www.rfc-editor.org/search

>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html

>>

>> Requests for special distribution should be addressed to either th=
e

>> author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless

>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.

>>

>>

>> The RFC Editor Team

>> Association Management Solutions, LLC

>>

>>

>>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--001a1143f2ac3a5cda052bfca657--


From nobody Wed Feb 17 14:42:59 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55621B2D71 for ; Wed, 17 Feb 2016 14:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcecG2iZO2u2 for ; Wed, 17 Feb 2016 14:42:50 -0800 (PST)
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 46E551B2A5D for ; Wed, 17 Feb 2016 14:42:35 -0800 (PST)
Received: by mail-pa0-x229.google.com with SMTP id fl4so18742658pad.0 for ; Wed, 17 Feb 2016 14:42:35 -0800 (PST)
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-type :content-transfer-encoding; bh=XpnUFbMFgx+CjUa+OrEbhYgib1jTmgnu9D3ivIznMRI=; b=lP1QTkjMJlI/jsWz/Kf/saIBlSBbWC0xsejaDafzUB4HhDPKNRfhSot8PWwd5illZw lZHSf9DKXavltkgF4fCknKQExK08jnRKR1KIbkTq8TRwS7gS/HKXkQJwR1mKXhdAmrg2 UotcBico894jhRREa45HBYPow7VwhBkNiAbvaRfCzwaatBRsY/0M5BfBJ5D9laZpmXys FmzsIG2Jsiwcr7219/ED1OlnK+kMKGJN8WxbGYWwYH6qYEeuEHtnvHAXLwr6RcYUS6IB wfOliYpFmTTcwyPp1lQ8QE+IPfTn+mlA6quv7RdHTRtCbxA/MxCGZbviEHeoSmu3yRlS 3PeQ==
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-type :content-transfer-encoding; bh=XpnUFbMFgx+CjUa+OrEbhYgib1jTmgnu9D3ivIznMRI=; b=PVIPPrdZ6WsodUlx4v1+9MAtUPkA9VzTn5R6fMGuIdqxQaEaQzi0e80KSb43cCljSU 8mJfq838GEtiC9iJW5RBN2ATNUQbOxxcN9cOIBQbJ6kWOQpRxdJGTJBYB2tujQU7KuAU /vTncJuc2uquLSeq/1VIy4DqdtkmsU0MM/NvF+Rmn2C6B0wNjFr/zEmwj8moj4XSgU6a 5Yic7+Ts8lxrcWA8iA6GsSxq+/DUr6+LsksAoHDzpkbCC4dQu9Ac7j2JdV4nzUQs0bzW FivcQl+3DutabcaITq99YInf6eHvEMP4gFEDu6/6ySV6CFycgssYfVgp1+0+NIoDdbEu IkTg==
X-Gm-Message-State: AG10YOQM/IalNVLZEQlnAaZD9oB71pgfAGP32TZIP4ynmrRDlWN7X/81uE25EpqqFzqOcQ==
X-Received: by 10.67.6.72 with SMTP id cs8mr5658067pad.138.1455748954949; Wed, 17 Feb 2016 14:42:34 -0800 (PST)
Received: from ?IPv6:2406:e007:4de7:1:28cc:dc4c:9703:6781? ([2406:e007:4de7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s21sm5051913pfi.29.2016.02.17.14.42.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 14:42:33 -0800 (PST)
To: Tom Herbert 
References: <20160204214639.14168.48254.idtracker@ietfa.amsl.com> <56B4D2B2.4020206@isi.edu> <56B4D3E8.7050706@foobar.org> <56B4D539.4010007@isi.edu> <56B4F1A6.7080402@foobar.org>  <56B668C3.8090009@foobar.org>  <56B67671.3010409@foobar.org>  <56B742AC.7010307@foobar.org>  <56B7B919.8090001@foobar.org> <56B83BB9.7040704@isi.edu> <56B8EA3F.2070505@gmail.com> <1A0F6D8E-33F2-4821-872A-F11EF408CE38@employees.org> <56BA38FC.9020306@gmail.com>  <56BBF425.5070107@gmail.com> <56C303EC.7040004@si6networks.com>  <56C378FD.7060903@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C4F75E.8010601@gmail.com>
Date: Thu, 18 Feb 2016 11:42:38 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Fernando Gont , v6ops list 
Subject: Re: [v6ops] Flow label settings [was IPv6 EHs Packet Drops]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 22:42:57 -0000

On 18/02/2016 05:45, Tom Herbert wrote:
> On Tue, Feb 16, 2016 at 11:31 AM, Brian E Carpenter
>  wrote:
>> On 17/02/2016 04:10, joel jaeggli wrote:
>>> On 2/16/16 3:11 AM, Fernando Gont wrote:
>>>> On 02/10/2016 11:38 PM, Brian E Carpenter wrote:
>>>>> On 10/02/2016 10:41, Tom Herbert wrote:
>>>>>> On Tue, Feb 9, 2016 at 8:07 PM, Brian E Carpenter
>>>>>>  wrote:
>>>>>>> Ole,
>>>>>>>
>>>>>>> On 09/02/2016 21:20, otroan@employees.org wrote:
>>>>>>>>> ...
>>>>>>>>>> what's the ratio of flow label = 0 to set flow labels in your network?
>>>>>>>>>> anyone studied this over time?
>>>>>>>>>
>>>>>>>>> We're planning for the long term here. While I agree that this is a very
>>>>>>>>> interesting question, we shouldn't base future practice on it.
>>>>>>>>
>>>>>>>> I'm not sure what you imply by that.
>>>>>>>> if the flow label is set, then router implementations / deployments can be changed  to use the 3-tuple for ECMP instead of the 5-tuple.
>>>>>>>
>>>>>>> Because of the chicken/egg problem, we need operators to require ECMP/LAG and server
>>>>>>> load balancing products that support the flow label, in order to create an incentive
>>>>>>> for users to run host stacks that set the flow label by default. Actually I think
>>>>>>> the best thing is to use the 6-tuple (5-tuple plus flow label), and drop back
>>>>>>> to 3-tuple if the transport header isn't the first Next Header.
>>>>>>>
>>>>>>>> if generally flow label = 0, then we could at least identify implementations that needs to be fixed so that we at some point can change.
>>>>>>>
>>>>>>> Windows, Linux, OS X, iOS and Android would be a good start.
>>>>>>
>>>>>> AFAIK IOS (and FreeBSD) has been sending non-zero flow labels for some
>>>>>> time now. Support was added in Linux to send non-zero flow labels by
>>>>>> default, Android will pick those up the next time they rebase (I still
>>>>>> don't know what the status is in Windows). In reality, setting the
>>>>>> flow label on the host is near zero cost and as long as network
>>>>>> devices are choking on them (we don't have any evidence of that)
>>>>>> there's no reason why we can't get to widespread usage in a relatively
>>>>>> short period of time.
>>>>>
>>>>> Windows 7 doesn't set any value by default, and I can't find a netshell
>>>>> command to switch it on. (I assume a TCP app can set it through the socket
>>>>> interface, but that's beside the point.)
>>>>
>>>> FWIW, I seem to recall some BSDs had a bug in which during the TCP 3WHS
>>>> they would set the FL to zero, and once established it would be set to
>>>> non-zero.. not sure if this changed.
>>>>
>>>> In some scenarios (think SYN-cookies) this behavior might be difficult
>>>> to avoid.
>>>
>>> right, if you want a flow label that is itself not derived from some
>>> deterministic transform you kind of have to keep track of what it is
>>> once you set it.
>>
>> That's exactly why a stateless hash is the way to go, but certainly it
>> should be applied from the SYN packet onwards (in both directions).
>> I guess we should have specified that in RFC 6437.
>>
> I didn't see any requirement in RFC6437 that the flow label must be
> persistent for the lifetime of a flow (e.g. TCP connection). 

No, nor is it forbidden to use the same flow labels for two
consecutive flows that are really part of the same application
session. But I think we should have said to mark the *first*
packet, precisely so that it will take the same path as its
followers.

> In fact,
> we implemented a facility that will recompute the flow label for a
> failing connection (random value assigned) in hopes of getting a
> different route through ECMP. This is a nice feature in IPv6 since we
> can't change the four tuple for an existing connection to get that
> same effect in IPv4. If intermediate devices drop packets because the
> flow label doesn't match what they think it should be this will be a
> problem...

Agreed.

   Brian
> 
> Tom
> 
> 
>>    Brian
>>
>>>
>>> syn cookies causes a non-zero amount of breakage so it tends to be used
>>> sparingly but it remains an extremely useful tool under duress.
>>>
>>>> Thanks!
>>>>
>>>> Cheers,
>>>>
>>>
>>>
> 


From nobody Wed Feb 17 15:31:44 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296231A7014 for ; Wed, 17 Feb 2016 15:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.107
X-Spam-Level: 
X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnIF4hB-HJK7 for ; Wed, 17 Feb 2016 15:31:38 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D8AF51A6FB8 for ; Wed, 17 Feb 2016 15:31:36 -0800 (PST)
Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u1HNUYi8003599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2016 15:30:35 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Owen DeLong 
In-Reply-To: <20160216.085120.74703683.sthaug@nethelp.no>
Date: Wed, 17 Feb 2016 15:30:33 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no>
To: sthaug@nethelp.no
X-Mailer: Apple Mail (2.3112)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 17 Feb 2016 15:30:35 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 23:31:44 -0000

> On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:
>=20
>> I believe we should not even suggest that it might be OK to allocate
>> manually. This draft isn't a BCP so we can use normal English, for
>> example:
>>=20
>> o Prefix generation: prefixes must be randomly generated according
>>  to the algorithms defined in [RFC4193]. There are on-line tools
>>  available to do this interactively, if not performed automatically
>>  by the CPE. Manual assignment of easy-to-remember prefixes must
>>  never be done because of the high risk of collision, recreating
>>  the problems of [RFC1918].
>=20
> Assume I want to number my lab using ULA. There's no way I'm going to
> be using randomly generated addresses - I want to have an *address
> plan*, and predictable addresses acording to a suitable pattern, just
> as I would do with regular IPv6 addresses.

You=E2=80=99re supposed to randomly select a /48 from fc00::/7

You=E2=80=99re not required to number randomly within the /48.

If you need multiple /48s, then you should select multiple /48s at
random.

Read RFC4193 for further clarification.

> Which means I'd probably ignore the above sentence of never doing
> manual assignment.

Perhaps clarification that it is only the top 41 bits of the prefix that
are randomized would help?

Perhaps not. I=E2=80=99m still trying to wrap my head around a case =
where ULA is
somehow more useful than GUA and failing.

> Yes, I understand what you're trying to do here - however, there are
> situations where this *will* be ignored.

Then it should be as clear as possible to people that choose to do so =
that
they are pointing a loaded gun at their own foot and they should =
exercise
caution in pulling the trigger.

Owen


From tom.coffeen@coffeen.net  Wed Feb 17 15:52:16 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB91A00E8 for ; Wed, 17 Feb 2016 15:52:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpgca2SvMjXR for ; Wed, 17 Feb 2016 15:52:10 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 E323D1A03E3 for ; Wed, 17 Feb 2016 15:52:09 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id g6so1638193igt.1 for ; Wed, 17 Feb 2016 15:52:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coffeen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Q76xVhwKIgjE7coE8ZqcBuI5qpFBCIu/vkzE4UrKHas=; b=WO90vlxdbDs08aMFvTm0bCg+HS8DJZYBZ43WOZxl3KukI8/NylSt2f6n+7BI+3kyn9 w4+AA1KaDkgDg0LiWoXvy7ZsNSncsSai8H/b4ykSsbEILUFNacwBpFgpF99r8kR1xyvM LHKDSegsLzF6SfQjH6DndWAIX7tvHAmy9VsKlX3pItbF9uy/oXQA/1qyQI3c8nUyktrI R0BUh1Vt0gi0pfzslJxML6BfN07G9Fr2dlEwNmoHoQNC7qI6x8QN6JCmlgtS3tTrwa9M qkwBocy+ClmdNYvec6VNs3zGDSej4f0aAVcqkCqv0Ln8iFEpj0Bog2oqVOlsMLM6S9f9 oX0g==
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=Q76xVhwKIgjE7coE8ZqcBuI5qpFBCIu/vkzE4UrKHas=; b=PdAwn9KwV86ndwHoRFCkG0Ieu8d36PzVLdu5G4U+oc5iy32OQPA/bgsK+9jRHjQgkG uMtrRawqXh+kcGWqwMzI86Ndkm7NkXolFbk0qF7SjWK+Dwr8XI/+q0vNarYy8vwzyo9J V+0xM5fcpBvCcq7PsCSdBqNOyuwNTx7DcdbAiKZ+8aAhZ0doeHFCG3Mo551q6XlPfxze bDMgIjkpCBVJ7yPcpI2Kj6w3oGomgwzD/QPWryf589YDzainMFRhcBTenPvAUeAwTlcF ElOTZMlTxK6Ig/BIrlBq235W3hoh0GrDkhJ1aIRY8BIUEE5Rs63D8Kt/Gt/NmrJLmF8u 6kFw==
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=Q76xVhwKIgjE7coE8ZqcBuI5qpFBCIu/vkzE4UrKHas=; b=HolO+ZKpR2ubcqApzLR0DeidIYQ0U7jh7rZIbm9EODGum+MBcy0f6cQDZYWDUsrKOG lOT3OXFki1oV53JdbLVMqMzgsXBb8h7kLR2SLuG0GLI6uR6WKxvZUOTY0yvTlGmb4lwK 3fO0XKPXdpHZuShHFclZPr32syBBizuZczbAWisW/luZeRBj11uzNqrDwJKhs2FD7Arf XGR2EH9aoKfqJCY+KObiBpuKDSEObdFdNDG/PfbKY8zF7UsaB9PvbhX0WPbel3KsX7EM nk1ytG94aeUrdiqr/CypCazZCSft0GFj6fzTTee2LsPrBFa76EgwVDjkJcRHQBzHNoBe br1Q==
X-Gm-Message-State: AG10YORJinhiOAwX7TuhggEzgcC66bPoTcnpWRmsCdqH1bajM0tms2+Itt7FIqrnKWcgFn7ZAlUYOup/8YKSOw==
MIME-Version: 1.0
X-Received: by 10.50.143.41 with SMTP id sb9mr245904igb.69.1455753129045; Wed, 17 Feb 2016 15:52:09 -0800 (PST)
Sender: tom.coffeen@coffeen.net
Received: by 10.36.81.139 with HTTP; Wed, 17 Feb 2016 15:52:08 -0800 (PST)
In-Reply-To: <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com>
Date: Wed, 17 Feb 2016 15:52:08 -0800
X-Google-Sender-Auth: 1h8v0uVxgyllRfeCeOFDYKr4eeI
Message-ID: 
From: Tom Coffeen 
To: Owen DeLong 
Content-Type: multipart/alternative; boundary=001a1134b9fe23538b052bfff021
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Feb 2016 23:59:01 -0000

--001a1134b9fe23538b052bfff021
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong  wrote:

>
> > On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:
> >
> >> I believe we should not even suggest that it might be OK to allocate
> >> manually. This draft isn't a BCP so we can use normal English, for
> >> example:
> >>
> >> o Prefix generation: prefixes must be randomly generated according
> >>  to the algorithms defined in [RFC4193]. There are on-line tools
> >>  available to do this interactively, if not performed automatically
> >>  by the CPE. Manual assignment of easy-to-remember prefixes must
> >>  never be done because of the high risk of collision, recreating
> >>  the problems of [RFC1918].
> >
> > Assume I want to number my lab using ULA. There's no way I'm going to
> > be using randomly generated addresses - I want to have an *address
> > plan*, and predictable addresses acording to a suitable pattern, just
> > as I would do with regular IPv6 addresses.
>
> You=E2=80=99re supposed to randomly select a /48 from fc00::/7
>

My understanding from RFC4193 is that the L bit (8th MSB) is not yet
defined (i.e., not "locally defined") when set to 0. Should this impact at
all one's confidence in allocating /48s from fc00::/8?

Tom

--001a1134b9fe23538b052bfff021
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong <owen@delong.c=
om> wrote:


> On Feb 15, 2016, at 23:51 , sthau=
g@nethelp.no wrote:

>

>> I believe we should not even suggest that it might be OK to alloca=
te

>> manually. This draft isn't a BCP so we can use normal English,=
 for

>> example:

>>

>> o Prefix generation: prefixes must be randomly generated according=


>>=C2=A0 to the algorithms defined in [RFC4193]. There are on-line to=
ols

>>=C2=A0 available to do this interactively, if not performed automat=
ically

>>=C2=A0 by the CPE. Manual assignment of easy-to-remember prefixes m=
ust

>>=C2=A0 never be done because of the high risk of collision, recreat=
ing

>>=C2=A0 the problems of [RFC1918].

>

> Assume I want to number my lab using ULA. There's no way I'm g=
oing to

> be using randomly generated addresses - I want to have an *address

> plan*, and predictable addresses acording to a suitable pattern=
, just

> as I would do with regular IPv6 addresses.



You=E2=80=99re supposed to randomly select a /48 from fc00::/7

My understandi=
ng from RFC4193 is that the L bit (8th MSB) is not yet defined (i.e., not &=
quot;locally defined") when set to 0. Should this impact at all one=
9;s confidence in allocating /48s from fc00::/8?

Tom




--001a1134b9fe23538b052bfff021--


From nobody Wed Feb 17 16:19:13 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889B81B2E6C for ; Wed, 17 Feb 2016 16:19:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFbhbYJbcrfC for ; Wed, 17 Feb 2016 16:19:05 -0800 (PST)
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 4FBAE1B2C24 for ; Wed, 17 Feb 2016 16:19:05 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id q63so20291021pfb.0 for ; Wed, 17 Feb 2016 16:19:05 -0800 (PST)
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-type :content-transfer-encoding; bh=vbe9i1tg7zb6mWnxTqUvh9OQC6Xx4ICxYUfOt1yHY3I=; b=ihqK1G1PQBMBPvpFVUDRnry8bSy4P9Fdvj2vTY+HrFaqff39DajKS8eKYjWjFvRtUz xRqTEWIxvBKdyOJYxi9ENgtO/6rwPwcQvrW2hOwAKVjLKKvfV9zDfmxD8S6bKI2SIDlg JqBQJHGr8k7/cE/6snufysPdeNdT8hO4jqvyBe3Q4sPHVfzCLFVKFmB6X/S5xNx6gqfH i4TRiV/ZvyGvVrjbHRq/NaCAga9O7rwgvs1EZs1a7EICyADJXeVk8IHG2VGcp36/5LPc zJL23/a70e/AfRATogvjmdYHZJcl9PIN/5DqErS1m7Z8A/cQy2r66Y94FqJZriouTa90 tlQQ==
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-type :content-transfer-encoding; bh=vbe9i1tg7zb6mWnxTqUvh9OQC6Xx4ICxYUfOt1yHY3I=; b=D/JOdWIeFN7nJHgR9k6MSHt9PhSi7kDKCTDKojWNaKhBO8MK18NZTfCXI25VRj6rJ9 Gc/VcQT/EhIKU5XLPhQmv3MxOvSmwWpvyfQZPAOi4vOE1XTaIazvObHTYcjWrbFFWZS/ Ulw0c0+Qu3eewCwqAbh3BIjRAjyV2gQBS+rsrlExBv5QlLU63peb0DmzisDHLm6iKtcB iSHdR2j0TGDFloFEeUOU0GDYfpJaiwvAmIP+6jV7jhnUD0cVTFb0MNbOsX9NX8N8n3GW bQC6XJtF5wzwUFbeu8lRhxar8W0gc8khlXsEA6EWNwG9428BAzhPDjRlMZMqVcJ9cIpQ G70A==
X-Gm-Message-State: AG10YOTR7CnMYuCnifjLyffvMsykEWeV+vEtEjBzGVU0cgWvdNB4ABAI7m4705FbpHh79A==
X-Received: by 10.98.16.198 with SMTP id 67mr6195158pfq.21.1455754744948; Wed, 17 Feb 2016 16:19:04 -0800 (PST)
Received: from ?IPv6:2406:e007:4de7:1:28cc:dc4c:9703:6781? ([2406:e007:4de7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h89sm5266568pfj.52.2016.02.17.16.19.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 16:19:03 -0800 (PST)
To: Tom Coffeen , Owen DeLong 
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56C50DFC.7050908@gmail.com>
Date: Thu, 18 Feb 2016 13:19:08 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 00:19:11 -0000

On 18/02/2016 12:52, Tom Coffeen wrote:
> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong  wrote:
>=20
>>
>>> On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:
>>>
>>>> I believe we should not even suggest that it might be OK to allocate=

>>>> manually. This draft isn't a BCP so we can use normal English, for
>>>> example:
>>>>
>>>> o Prefix generation: prefixes must be randomly generated according
>>>>  to the algorithms defined in [RFC4193]. There are on-line tools
>>>>  available to do this interactively, if not performed automatically
>>>>  by the CPE. Manual assignment of easy-to-remember prefixes must
>>>>  never be done because of the high risk of collision, recreating
>>>>  the problems of [RFC1918].
>>>
>>> Assume I want to number my lab using ULA. There's no way I'm going to=

>>> be using randomly generated addresses - I want to have an *address
>>> plan*, and predictable addresses acording to a suitable pattern, just=

>>> as I would do with regular IPv6 addresses.
>>
>> You=E2=80=99re supposed to randomly select a /48 from fc00::/7
>>
>=20
> My understanding from RFC4193 is that the L bit (8th MSB) is not yet
> defined (i.e., not "locally defined") when set to 0. Should this impact=
 at
> all one's confidence in allocating /48s from fc00::/8?

You should only allocate in fd00::/8. fc00::/8 is reserved for future use=
=2E
I think this detail should be added to the IANA registry, which only
mentions fc00::/7 .

   Brian


From nobody Wed Feb 17 16:26:41 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA571A1AFC for ; Wed, 17 Feb 2016 16:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.106
X-Spam-Level: 
X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v3l0hCnMbia for ; Wed, 17 Feb 2016 16:26:32 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 74C3F1AC3E8 for ; Wed, 17 Feb 2016 16:26:32 -0800 (PST)
Received: from [IPv6:2620::930:0:ba09:8aff:feb9:f57f] ([IPv6:2620:0:930:0:ba09:8aff:feb9:f57f]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u1I0PTue015309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2016 16:25:30 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_AECE813B-F7DD-471B-9F42-8A3DA34EB3E3"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Owen DeLong 
In-Reply-To: 
Date: Wed, 17 Feb 2016 16:25:29 -0800
Message-Id: 
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com> 
To: Tom Coffeen 
X-Mailer: Apple Mail (2.3112)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 17 Feb 2016 16:25:30 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 00:26:39 -0000

--Apple-Mail=_AECE813B-F7DD-471B-9F42-8A3DA34EB3E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Correct=E2=80=A6 Technically it should be from fd00::/8, but since =
fc00::/8 has been rendered into an undefined state as a result of I-D =
expiration without consensus of one of three I-Ds in a 3-part harmony of =
I-Ds, and since ULA to begin with is pretty much YAFBS (Yet Another Form =
of Bogon Space), I=E2=80=99m not sure that little technicality has much =
meaning in the real world.

Owen

> On Feb 17, 2016, at 15:52 , Tom Coffeen  wrote:
>=20
> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong > wrote:
>=20
> > On Feb 15, 2016, at 23:51 , sthaug@nethelp.no =
 wrote:
> >
> >> I believe we should not even suggest that it might be OK to =
allocate
> >> manually. This draft isn't a BCP so we can use normal English, for
> >> example:
> >>
> >> o Prefix generation: prefixes must be randomly generated according
> >>  to the algorithms defined in [RFC4193]. There are on-line tools
> >>  available to do this interactively, if not performed automatically
> >>  by the CPE. Manual assignment of easy-to-remember prefixes must
> >>  never be done because of the high risk of collision, recreating
> >>  the problems of [RFC1918].
> >
> > Assume I want to number my lab using ULA. There's no way I'm going =
to
> > be using randomly generated addresses - I want to have an *address
> > plan*, and predictable addresses acording to a suitable pattern, =
just
> > as I would do with regular IPv6 addresses.
>=20
> You=E2=80=99re supposed to randomly select a /48 from fc00::/7
>=20
> My understanding from RFC4193 is that the L bit (8th MSB) is not yet =
defined (i.e., not "locally defined") when set to 0. Should this impact =
at all one's confidence in allocating /48s from fc00::/8?
>=20
> Tom


--Apple-Mail=_AECE813B-F7DD-471B-9F42-8A3DA34EB3E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Correct=E2=80=A6 Technically it should be from fd00::/8, but =
since fc00::/8 has been rendered into an undefined state as a result of =
I-D expiration without consensus of one of three I-Ds in a 3-part =
harmony of I-Ds, and since ULA to begin with is pretty much YAFBS (Yet =
Another Form of Bogon Space), I=E2=80=99m not sure that little =
technicality has much meaning in the real world.

Owen

On =
Feb 17, 2016, at 15:52 , Tom Coffeen <tom.coffeen@gmail.com> wrote:

On Wed, Feb 17, 2016 at 3:30 =
PM, Owen DeLong <owen@delong.com> wrote:

> On Feb =
15, 2016, at 23:51 , sthaug@nethelp.no wrote:
>
>> I believe we should not even suggest that it might =
be OK to allocate
>> manually. This draft isn't a =
BCP so we can use normal English, for
>> example:
>>
>> o Prefix generation: prefixes =
must be randomly generated according
>>  to the =
algorithms defined in [RFC4193]. There are on-line tools
>>  available to do this interactively, if not =
performed automatically
>>  by the CPE. Manual =
assignment of easy-to-remember prefixes must
>>  =
never be done because of the high risk of collision, recreating
>>  the problems of [RFC1918].
>
> Assume I want to number my lab using =
ULA. There's no way I'm going to
> be using randomly =
generated addresses - I want to have an *address
>=
 plan*, and predictable addresses acording to a suitable pattern, =
just
> as I would do with regular IPv6 =
addresses.

You=E2=80=99re supposed =
to randomly select a /48 from fc00::/7

My understanding from RFC4193 is that the L bit (8th =
MSB) is not yet defined (i.e., not "locally defined") when set to 0. =
Should this impact at all one's confidence in allocating /48s from =
fc00::/8?

Tom

=

--Apple-Mail=_AECE813B-F7DD-471B-9F42-8A3DA34EB3E3--


From nobody Wed Feb 17 16:35:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2A1B3000 for ; Wed, 17 Feb 2016 16:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4x1fIlwS9Bj for ; Wed, 17 Feb 2016 16:35:16 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBAE1B3006 for ; Wed, 17 Feb 2016 16:35:16 -0800 (PST)
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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 97D093493BB; Thu, 18 Feb 2016 00:35:06 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8DC52160047; Thu, 18 Feb 2016 00:35:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7CCD116005B; Thu, 18 Feb 2016 00:35:06 +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 ak9HwQFlh7PM; Thu, 18 Feb 2016 00:35:06 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 343F5160047; Thu, 18 Feb 2016 00:35:06 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 18E73428C484; Thu, 18 Feb 2016 11:35:04 +1100 (EST)
To: Tom Coffeen 
From: Mark Andrews 
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com> 
In-reply-to: Your message of "Wed, 17 Feb 2016 15:52:08 -0800." 
Date: Thu, 18 Feb 2016 11:35:03 +1100
Message-Id: <20160218003504.18E73428C484@rock.dv.isc.org>
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 00:35:22 -0000

In message 
, Tom Coffeen writes:
> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong  wrote:
>
> >
> > > On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:
> > >
> > >> I believe we should not even suggest that it might be OK to allocate
> > >> manually. This draft isn't a BCP so we can use normal English, for
> > >> example:
> > >>
> > >> o Prefix generation: prefixes must be randomly generated according
> > >>  to the algorithms defined in [RFC4193]. There are on-line tools
> > >>  available to do this interactively, if not performed automatically
> > >>  by the CPE. Manual assignment of easy-to-remember prefixes must
> > >>  never be done because of the high risk of collision, recreating
> > >>  the problems of [RFC1918].
> > >
> > > Assume I want to number my lab using ULA. There's no way I'm going to
> > > be using randomly generated addresses - I want to have an *address
> > > plan*, and predictable addresses acording to a suitable pattern, just
> > > as I would do with regular IPv6 addresses.
> >
> > You’re supposed to randomly select a /48 from fc00::/7
>
> My understanding from RFC4193 is that the L bit (8th MSB) is not yet
> defined (i.e., not "locally defined") when set to 0. Should this impact at
> all one's confidence in allocating /48s from fc00::/8?

fc00::/8 is reserved - DO NOT USE
fd00::/8 is where you should be generating your prefixes in.

If you need to simulate a /32 then generate bits 9..32 randomly and
prefix with 11111101.  Repeat if you are simulating more than one
ISP.

There is never a valid case for not generating the high bits randomly.
You don't get "nice" upper bits from RIR's unless you are very lucky.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Feb 17 16:52:20 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BCC1A88ED for ; Wed, 17 Feb 2016 16:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxqBH-SkQ67L for ; Wed, 17 Feb 2016 16:52:12 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 CE9FA1A00C6 for ; Wed, 17 Feb 2016 16:52:11 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id g6so2494340igt.1 for ; Wed, 17 Feb 2016 16:52:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coffeen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=JrfN1M7dNl/+SOR1pppYV+iGmGZD3Kgz9cHz3H02waI=; b=CPgrYM4RVjMMPSNH8vppKuxLLxoF/plX56/t46BiNnv0gYNGBvq2MUsawA2rmnGtVt yI9s1f0Pc7U7RlB6kX6RJHO8yPgQSBFIxmdiToxyXyq60RqqH1hHf6TBoQRsONgSAvp1 wIbFXFYMZyyfFSIvHLBKQuy4RsZiXJU9bBvXytRlYqJDPzWQYvJyg9JTRXW1za6xz1KF EnIj/cGEVzIkd1PGycva/t80wyoNDW/XR+2eOwz5iNSYMeqjJi/BarqIRfhgB8Pvp6Il Qpvnk9KOB8StFLfolWVcZ1ug2NC0Zpt2UN7PhQ+Fc9tQtfNfMc1Ij+NhClk/QjDcj+jv 9qJA==
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=JrfN1M7dNl/+SOR1pppYV+iGmGZD3Kgz9cHz3H02waI=; b=XO8EOCkAamJ+aMlgPgd1QYA1QnBbxsiP1bxCXuTCUowLvysrhEomFbVINLpWXLTsr/ 2YtYO6KZ9RWGThmkvc/vs6Pu7MEnjx5AzZiH1iygDLIZ4l/qga9jIP2JjAiuT60Jd7kT PkWEZpMpJdhpWJDuzNyRFLkSlHp9cFFnrbG0Nzt09/ZIvfHP4YA4zVTJlWSbwAGPaUGm bDrZWp0h/7QUB7yAEZ7s6hoyy0FKi7rZvhPnvPai4aUeQgpxA1PhmZMwd/XwbwKMe7TY ElBb141D3lKs47dZsTenPi+g+HNvBrCQTwONg0mmv/gzwiM9VfE+29Cl9py3/ei2QI7g /cnA==
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=JrfN1M7dNl/+SOR1pppYV+iGmGZD3Kgz9cHz3H02waI=; b=Ww3SHYCG6sI7GLadwk4feYiBIi9coAvZGE+bKic2kyPbDuHjWlTVOvafLNVoh7QEC0 hrTPIgMcgSUnppjpBSwJ4fC0ozpCLvgvmTP38BTBOQTCaavBx5eqOMJoXdHRKtLrNKZv h7NkR2A8FuLo4FXVKteVd2bcjxYxlVP+jAEfXMuAUd7RSBD/yz7I7ly8rgBfhEORdSaH Hz/nHhcLLPQoLkLIlRzP5PW9eAUonWdp/N9QKGx3UGqwgsW6YF8RsLaMqIO7A8RiLIVe Zvkz0yYk35EstAuGFsAe/DDRWyt/jrB0niRbZ9uL7d8pXg9yMg3CiSN0j6E3R6p2/63i 9msQ==
X-Gm-Message-State: AG10YOQ/BjcRTrTAx5gC66tJGx98vcniHT3VKeOGyvv0kX4D+6tk4arjfOZZWtNY6me8HXoSihOmDRoCfkSqSg==
MIME-Version: 1.0
X-Received: by 10.50.79.228 with SMTP id m4mr467785igx.45.1455756731197; Wed, 17 Feb 2016 16:52:11 -0800 (PST)
Sender: tom.coffeen@coffeen.net
Received: by 10.36.81.139 with HTTP; Wed, 17 Feb 2016 16:52:11 -0800 (PST)
In-Reply-To: <20160218003504.18E73428C484@rock.dv.isc.org>
References: <1CBB66E1-5AF4-4AF2-805E-201576347FB6@ecs.soton.ac.uk>  <56C26B89.3020304@gmail.com> <20160216.085120.74703683.sthaug@nethelp.no> <78D3B0A8-CCBE-4997-B07A-3818E7B04C44@delong.com>  <20160218003504.18E73428C484@rock.dv.isc.org>
Date: Wed, 17 Feb 2016 16:52:11 -0800
X-Google-Sender-Auth: xXbbnDZhMiw9rSnyE0MNq52lVGE
Message-ID: 
From: Tom Coffeen 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=089e013a1f16d7ce9e052c00c6ca
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 00:52:19 -0000

--089e013a1f16d7ce9e052c00c6ca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2016 at 4:35 PM, Mark Andrews  wrote:

>
> In message <
> CAA9TgZmhqGROzByMy7+PXrA7Kdt2qUGfycEN_a7sJdY774azDw@mail.gmail.com>
> , Tom Coffeen writes:
> > On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong  wrote:
> >
> > >
> > > > On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:
> > > >
> > > >> I believe we should not even suggest that it might be OK to alloca=
te
> > > >> manually. This draft isn't a BCP so we can use normal English, for
> > > >> example:
> > > >>
> > > >> o Prefix generation: prefixes must be randomly generated according
> > > >>  to the algorithms defined in [RFC4193]. There are on-line tools
> > > >>  available to do this interactively, if not performed automaticall=
y
> > > >>  by the CPE. Manual assignment of easy-to-remember prefixes must
> > > >>  never be done because of the high risk of collision, recreating
> > > >>  the problems of [RFC1918].
> > > >
> > > > Assume I want to number my lab using ULA. There's no way I'm going =
to
> > > > be using randomly generated addresses - I want to have an *address
> > > > plan*, and predictable addresses acording to a suitable pattern, ju=
st
> > > > as I would do with regular IPv6 addresses.
> > >
> > > You=E2=80=99re supposed to randomly select a /48 from fc00::/7
> >
> > My understanding from RFC4193 is that the L bit (8th MSB) is not yet
> > defined (i.e., not "locally defined") when set to 0. Should this impact
> at
> > all one's confidence in allocating /48s from fc00::/8?
>
> fc00::/8 is reserved - DO NOT USE
> fd00::/8 is where you should be generating your prefixes in.
>
> If you need to simulate a /32 then generate bits 9..32 randomly and
> prefix with 11111101.  Repeat if you are simulating more than one
> ISP.
>
> There is never a valid case for not generating the high bits randomly.
> You don't get "nice" upper bits from RIR's unless you are very lucky.
>

Thanks. The consensus tracks with my prior understanding (and should
prevent any unintended confusion with fc00::/7 mentioned as a source for
ULA /48s).

Also FWIW, I'm with Bing that, when using a ULA /48, 16 bits should be
enough "headroom" for a sufficiently flexible intrasite address plan.

Tom

--089e013a1f16d7ce9e052c00c6ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Feb 17, 2016 at 4:35 PM, Mark Andrews <marka@isc.org<=
/a>> wrote:


In message <CAA9TgZmhqGROzByMy7+PXrA7Kdt2qUGfycEN_a7sJdY774=
azDw@mail.gmail.com>

, Tom Coffeen writes:

> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong <owen@delong.com> wrote:

>

> >

> > > On Feb 15, 2016, at 23:51 , sthaug@nethelp.no wrote:

> > >

> > >> I believe we should not even suggest that it might be OK=
 to allocate

> > >> manually. This draft isn't a BCP so we can use norma=
l English, for

> > >> example:

> > >>

> > >> o Prefix generation: prefixes must be randomly generated=
 according

> > >>=C2=A0 to the algorithms defined in [RFC4193]. There are =
on-line tools

> > >>=C2=A0 available to do this interactively, if not perform=
ed automatically

> > >>=C2=A0 by the CPE. Manual assignment of easy-to-remember =
prefixes must

> > >>=C2=A0 never be done because of the high risk of collisio=
n, recreating

> > >>=C2=A0 the problems of [RFC1918].

> > >

> > > Assume I want to number my lab using ULA. There's no way=
 I'm going to

> > > be using randomly generated addresses - I want to have an *a=
ddress

> > > plan*, and predictable addresses acording to a suitable patt=
ern, just

> > > as I would do with regular IPv6 addresses.

> >

> > You=E2=80=99re supposed to randomly select a /48 from fc00::/7
>

> My understanding from RFC4193 is that the L bit (8th MSB) is not yet
> defined (i.e., not "locally defined") when set to 0. Should =
this impact at

> all one's confidence in allocating /48s from fc00::/8?



fc00::/8 is reserved - DO NOT USE

fd00::/8 is where you should be generating your prefixes in.



If you need to simulate a /32 then generate bits 9..32 randomly and

prefix with 11111101.=C2=A0 Repeat if you are simulating more than one

ISP.



There is never a valid case for not generating the high bits randomly.

You don't get "nice" upper bits from RIR's unless you are=
 very lucky.

Thanks. The consensus trac=
ks with my prior understanding (and should prevent any unintended confusion=
 with fc00::/7 mentioned as a source for ULA /48s).

Also FWIW, I'm with Bing that, when using a ULA /48, 16 bits should b=
e enough "headroom" for a sufficiently flexible intrasite address=
 plan.

Tom =C2=A0=C2=A0
=C2=A0



--089e013a1f16d7ce9e052c00c6ca--


From nobody Wed Feb 17 19:32:03 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A1B1A0AC8; Wed, 17 Feb 2016 19:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.908
X-Spam-Level: 
X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMElTlWctn0Z; Wed, 17 Feb 2016 19:31:59 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C271A00CC; Wed, 17 Feb 2016 19:31:59 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 6FF63180013; Wed, 17 Feb 2016 19:31:44 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160218033144.6FF63180013@rfc-editor.org>
Date: Wed, 17 Feb 2016 19:31:44 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org
Subject: [v6ops] RFC 7755 on SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 03:32:00 -0000

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

        
        RFC 7755

        Title:      SIIT-DC: Stateless IP/ICMP Translation for 
                    IPv6 Data Center Environments 
        Author:     T. Anderson
        Status:     Informational
        Stream:     IETF
        Date:       February 2016
        Mailbox:    tore@redpill-linpro.com
        Pages:      24
        Characters: 54648
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-v6ops-siit-dc-03.txt

        URL:        https://www.rfc-editor.org/info/rfc7755

        DOI:        http://dx.doi.org/10.17487/RFC7755

This document describes the use of the Stateless IP/ICMP Translation
Algorithm (SIIT) in an IPv6 Internet Data Center (IDC).  In this
deployment model, traffic from legacy IPv4-only clients on the
Internet is translated to IPv6 upon reaching the IDC operator's
network infrastructure.  From that point on, it may be treated the
same as traffic from native IPv6 end users.  The IPv6 endpoints may
be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses.
This facilitates a single-stack IPv6-only network infrastructure, as
well as efficient utilization of public IPv4 addresses.

The primary audience is IDC operators who are deploying IPv6, running
out of available IPv4 addresses, and/or feeling that dual stack
causes undesirable operational complexity.

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


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

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

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Feb 17 19:32:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568C1ACE32; Wed, 17 Feb 2016 19:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.908
X-Spam-Level: 
X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaJ95wxxoEma; Wed, 17 Feb 2016 19:32:17 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9951AD333; Wed, 17 Feb 2016 19:32:16 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 30973180472; Wed, 17 Feb 2016 19:32:02 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160218033202.30973180472@rfc-editor.org>
Date: Wed, 17 Feb 2016 19:32:02 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org
Subject: [v6ops] RFC 7756 on Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 03:32:22 -0000

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

        
        RFC 7756

        Title:      Stateless IP/ICMP Translation for IPv6 
                    Internet Data Center Environments (SIIT-DC): Dual 
                    Translation Mode 
        Author:     T. Anderson, S. Steffann
        Status:     Informational
        Stream:     IETF
        Date:       February 2016
        Mailbox:    tore@redpill-linpro.com, 
                    sander@steffann.nl
        Pages:      17
        Characters: 39291
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-v6ops-siit-dc-2xlat-02.txt

        URL:        https://www.rfc-editor.org/info/rfc7756

        DOI:        http://dx.doi.org/10.17487/RFC7756

This document describes an extension of the Stateless IP/ICMP
Translation for IPv6 Internet Data Center Environments (SIIT-DC)
architecture, which allows applications, protocols, or nodes that are
incompatible with IPv6 and/or Network Address Translation to operate
correctly with SIIT-DC.  This is accomplished by introducing a new
component called an SIIT-DC Edge Relay, which reverses the
translations made by an SIIT-DC Border Relay.  The application and/or
node is thus provided with seemingly native IPv4 connectivity that
provides end-to-end address transparency.

The reader is expected to be familiar with the SIIT-DC architecture
described in RFC 7755.

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


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

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

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Feb 17 19:32:42 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793111B2FC7; Wed, 17 Feb 2016 19:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.908
X-Spam-Level: 
X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXA_q6JXXrxM; Wed, 17 Feb 2016 19:32:32 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7263B1A8AF9; Wed, 17 Feb 2016 19:32:32 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id C72AC180472; Wed, 17 Feb 2016 19:32:17 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160218033217.C72AC180472@rfc-editor.org>
Date: Wed, 17 Feb 2016 19:32:17 -0800 (PST)
Archived-At: 
Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org
Subject: [v6ops] RFC 7757 on Explicit Address Mappings for Stateless IP/ICMP Translation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 03:32:35 -0000

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

        
        RFC 7757

        Title:      Explicit Address Mappings for Stateless 
                    IP/ICMP Translation 
        Author:     T. Anderson, A. Leiva Popper
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2016
        Mailbox:    tore@redpill-linpro.com, 
                    ydahhrk@gmail.com
        Pages:      19
        Characters: 40938
        Updates:    RFC 6145

        I-D Tag:    draft-ietf-v6ops-siit-eam-03.txt

        URL:        https://www.rfc-editor.org/info/rfc7757

        DOI:        http://dx.doi.org/10.17487/RFC7757

This document extends the Stateless IP/ICMP Translation Algorithm
(SIIT) with an Explicit Address Mapping (EAM) algorithm and formally
updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP
translation between arbitrary (non-IPv4-translatable) IPv6 endpoints
and IPv4.

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

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

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

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

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


The RFC Editor Team
Association Management Solutions, LLC



From nobody Thu Feb 18 00:40:53 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BA61B35E3 for ; Thu, 18 Feb 2016 00:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNvD8Pd1SRVp for ; Thu, 18 Feb 2016 00:40:48 -0800 (PST)
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 7E2081A92BD for ; Thu, 18 Feb 2016 00:40:48 -0800 (PST)
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 u1I8ek0I021266; Thu, 18 Feb 2016 09:40:46 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D20B2034DD; Thu, 18 Feb 2016 09:49:14 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3112D203E08; Thu, 18 Feb 2016 09:49:14 +0100 (CET)
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 u1I8ej5w028832; Thu, 18 Feb 2016 09:40:45 +0100
To: Mark Smith 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C5838D.2020808@gmail.com>
Date: Thu, 18 Feb 2016 09:40:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 08:40:51 -0000

Le 17/02/2016 20:56, Mark Smith a ĂŠcrit :
>
> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
> >
>  wrote:
>>
>> Hi,
>>
>> I have a comment on this RFC7278.
>>
>> The comment comes from the observation that the operator also uses
>>  an
> address from the 64share prefix (a global address).
>>
>
> Are you sure about that?

YEs.  In the UE the address of the default router is an address prefixed
by the same prefix as the prefix that the UE believes is for self (the
64share prefix).

The default router address is not a link-local address (it's a GUA),
although it could have been LL in theory.

And this time, different from my earlier experiments, the 64share
happens on the module - i.e. there is no intermediary modem like a
cellular USB dongle or something which would do things not in control,
like proxy ND or proxy DHCP.

> It was my understanding that the unconventional thing about a 3GPP
> setup was that all traffic to all addresses within the /64 was
> (blindly) forwarded to the UE, even if the UE uses one or more of
> those addresses on the end of the link. I think that is only
> possible because the link is a point to point one.

YEs, that is the case - all addresses in the prefix are forwarded to the
UE.  But I doubt the operator forwards to UE the packets addressed to
the default router.  This is something I can try and report.

(it would be strange that the packets addressed of the default router
  be forwarded to the UE, but one never knows with the ppp links).

> (Presumably the UE has a discard route for the /64 to prevent loops
> for non-existent addresses.)

YEs.  W/o 64share the UE installs a route for the /64 on its cellular
interface (a "*" route on which UE does ND).  Then when doing 64share
the UE must remove that route from the cellular interface and install it
on its other interface (USBnet in my case).  I guess this is what you
mean by discard route.

However, it must maintain on its celluar interface the default route (a
/128 host-based route).

Alex

>> As such that address too should not be used in the 'LAN'.
>>
>> This may lead to several textual modifications to the document.
>> For
> example:
>>>
>>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN
>>> link.
>>
>>
>> This is wrongly stated, because the UE does not own that prefix,
>> so
>>
> it can't say "its IPv6 addresses".  That prefix is belonging to a
> link not to the UE, because the operator also makes an address out of
> it.
>>
>> Alex
>>
>> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org
>  a ĂŠcrit :
>>>
>>> A new Request for Comments is now available in online RFC
>>> libraries.
>>>
>>>
>>> RFC 7278
>>>
>>> Title:      Extending an IPv6 /64 Prefix from a Third Generation
>>>  Partnership Project (3GPP) Mobile Interface to a LAN Link
>>> Author: C. Byrne, D. Drown, A. Vizdal Status:     Informational
>>> Stream: IETF Date:       June 2014 Mailbox:
>>> cameron.byrne@t-mobile.com
> ,
>>> dan@drown.org , ales.vizdal@t-mobile.cz
>>>  Pages:      10 Characters:
>>> 19965 Updates/Obsoletes/SeeAlso:   None
>>>
>>> I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>>
>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt
>>>
>>> This document describes requirements for extending an IPv6 /64
>>> prefix from a User Equipment Third Generation Partnership Project
>>> (3GPP) radio interface to a LAN link and describes two
>>> implementation examples.
>>>
>>> This document is a product of the IPv6 Operations Working Group
>>> of
> the IETF.
>>>
>>>
>>> INFORMATIONAL: This memo provides information for the Internet
> community.
>>> It does not specify an Internet standard of any kind.
>>> Distribution of this memo is unlimited.
>>>
>>> This announcement is sent to the IETF-Announce and rfc-dist
>>> lists. To subscribe or unsubscribe, see
>>> http://www.ietf.org/mailman/listinfo/ietf-announce
>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>
>>> For searching the RFC series, see
>>> http://www.rfc-editor.org/search For downloading RFCs, see
>>> http://www.rfc-editor.org/rfc.html
>>>
>>> Requests for special distribution should be addressed to either
>>> the author of the RFC in question, or to
>>> rfc-editor@rfc-editor.org
> .  Unless
>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>> unlimited distribution.
>>>
>>>
>>> The RFC Editor Team Association Management Solutions, LLC
>>>
>>>
>>>
>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org 
>> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Feb 18 01:13:35 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10201B3BE0 for ; Thu, 18 Feb 2016 01:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.385
X-Spam-Level: 
X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1GqJK1mi7Zy for ; Thu, 18 Feb 2016 01:13:33 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 11ABC1B3BE2 for ; Thu, 18 Feb 2016 01:13:23 -0800 (PST)
Received: by mail-ig0-x22a.google.com with SMTP id hb3so8178298igb.0 for ; Thu, 18 Feb 2016 01:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3ZChXN9exyzrYrLS0jrXbcBQpL8XAdQQXxoO5oUf/fs=; b=pipFCoqvWurn6PjPVXKgN/l+bnGVzxQxYwVfUiPmR/lFaZfmXaVwFPkU6JoQCexcBW rKEuJZeBpgRejYeIwA2Ge1bbFrat3NVX/NnU45PLdl/gek6ow+wxqvm1JxnJf1oOyOZ9 EFLAFoXwGlfcA3N4MgOzH4kTAsytl98jC1h4IPCANuXgg6EPv2BrFvfqG5htKzBebD62 22NX4SwiIL0ou2cclCPmLI+XSHyhcjqLpIEvdFRpyt5gLx2MVu2t6pC9g7rAWiNcrUbK fmZvhqfdiwt2M9xrVXsWqVYoRvdWDlaQQm0CssxmYIkD178/3feM0aR8ptEu0MsjzTdr UKlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3ZChXN9exyzrYrLS0jrXbcBQpL8XAdQQXxoO5oUf/fs=; b=UuIiFzSGirqbSTwzwJzg95ReSV7GjQNyASHbkdNOWllFaUbjVU4OcQ+A6EKTAYJlQ7 7eOE0bDxK/vepEy3vLuLhzNwNn0Eum1Ep4LiXy1CU2bTg7bh45O0raTd9XwMyGfx5+zx rmJfwmcu1rPyPn44rb7iwP2Pu7YYNaKJauyTlqaQqd9iLuU0FpPyApVuFCoKhIDkrD38 pW+N2w7h0qLvk+tdD5hy+AGNPytpMk8AAQGVYrnSEdG7qWitKJoHjY7hXAvFATbR+xPB uqBoOU8OsitfpXhps2LU5oeHGM1L9iKLxosesH96v9VzewL5N71k0gDl7qEH/QOmsWEc dDmQ==
X-Gm-Message-State: AG10YOStwlNKHkQ+YreecpzXjKnDPf02N8EMGKUyRXnrJwRgYUIaOuL8hGHtX1JKUP/3hNCL42Ax+z3x+Qt2IKnJ
X-Received: by 10.50.43.228 with SMTP id z4mr2100391igl.33.1455786802397; Thu, 18 Feb 2016 01:13:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.69.163 with HTTP; Thu, 18 Feb 2016 01:13:02 -0800 (PST)
In-Reply-To: <56C5838D.2020808@gmail.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com>
From: Erik Kline 
Date: Thu, 18 Feb 2016 18:13:02 +0900
Message-ID: 
To: Alexandre Petrescu 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 09:13:34 -0000

> The default router address is not a link-local address (it's a GUA),
> although it could have been LL in theory.

According to whom/what?

I have Android device on my desk with route like this:

    ::/0 -> fe80::e06f:31f4:feb2:53d6 rmnet_data0


From nobody Thu Feb 18 01:51:00 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E221B36E5 for ; Thu, 18 Feb 2016 01:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOKXXlzLJk3N for ; Thu, 18 Feb 2016 01:50:56 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 DB90E1B352C for ; Thu, 18 Feb 2016 01:50:55 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id e6so39296224vkh.2 for ; Thu, 18 Feb 2016 01:50:55 -0800 (PST)
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:content-type; bh=wkh7wfGXDQdAEGEMojMysK9Li3CbBbzIWOO9szXWXXw=; b=xEqXcs1+tgT5YXl6OxO3UCJ1bRQTLuVOtPojZfZAdHR8g8oCP6vl72/CRE/X/FHKZ+ Z1puVHPtW7EPwnrQSuQF7Z5lSyRwAtqNRydH7uKO2ZpTx0XtMl9XgQxlBKrIe3Ii9Km/ wphZbFAmg3AaLUIb9lyxxBWxB7YMJ5CXhqTHIIHgxi+KA9JTUenZoPgsPdkiH5w6Xh1Y yCEe43WPj8HhV21YiEeLVKUb6eop2HISsNyUnn6hPaVMWqXLoH0I8wJM8WS0YFlefdfj GZgomVppZCplwYuIhN6S8/FvG4d2goAtQZJDCzCCW9E1DyJA27PIiL5ZmdIen035kYiG vV9g==
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-type; bh=wkh7wfGXDQdAEGEMojMysK9Li3CbBbzIWOO9szXWXXw=; b=DYTGy78gobG+H2OdlnAehP0O5lXIwsFKbc3IJQcYbZadhKrJoLY5slOP71qK9DG4dO jCR3hZrEDrQ+cvMUh/QnFmt4LmNCXbi1Lo/CkNcG7bykmagkbJWGb3C4hmVR7B7UqaXE dvcL9zwZhHpb1z+3JKCgRHoX4q8nBXTnsSABnAdNeLCvPfMRlf0T3L2sqXcQ9eOMj9t4 L2ilRHMTYQ9xqxcJ7ABkv8l+uzkJMfXi+sE27kK8K2V19hb8S6vmelFqsmAnSJsnKp+I 6jog5US6HxQby2qTu85iRao1Ci4WCAGlFJ2iJERWSx4jQE3P2vRDDzRlGlWcCyp2ykx1 VWiw==
X-Gm-Message-State: AG10YOSCCvwgNmJdRod2uzROzBqPwqxcn+Hlhe+6zwoO9D8Lvkw+K7NpxzMb7MT/LmhTr1PR9K2Mz9oTshSAQQ==
MIME-Version: 1.0
X-Received: by 10.31.54.75 with SMTP id d72mr5174205vka.30.1455789054963; Thu, 18 Feb 2016 01:50:54 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Thu, 18 Feb 2016 01:50:54 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Thu, 18 Feb 2016 01:50:54 -0800 (PST)
In-Reply-To: <56C5838D.2020808@gmail.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com>
Date: Thu, 18 Feb 2016 20:50:54 +1100
Message-ID: 
From: Mark Smith 
To: Alexandre Petrescu 
Content-Type: multipart/alternative; boundary=001a11430a1e7d3448052c084dec
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 09:50:59 -0000

--001a11430a1e7d3448052c084dec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 18 Feb 2016 7:40 PM, "Alexandre Petrescu" 
wrote:
>
>
>
> Le 17/02/2016 20:56, Mark Smith a =C3=A9crit :
>>
>>
>> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
>> >
>>
>>  wrote:
>>>
>>>
>>> Hi,
>>>
>>> I have a comment on this RFC7278.
>>>
>>> The comment comes from the observation that the operator also uses
>>>  an
>>
>> address from the 64share prefix (a global address).
>>>
>>>
>>
>> Are you sure about that?
>
>
> YEs.  In the UE the address of the default router is an address prefixed
> by the same prefix as the prefix that the UE believes is for self (the
> 64share prefix).
>
> The default router address is not a link-local address (it's a GUA),
> although it could have been LL in theory.
>

And in practice. Route next hops are supposed to be LLs except in some BGP
cases.

Share64 is based on the premise that the whole /64 is routed to the UE. I
don't know a lot about the 3GPP specs, but I presume that is what they say
is to happen.

I think the fundamental issue is that the 3GPP people decided to treat a
smartphone as special, and came up with their own ways of doing IPv6 on
them, rather than just treating the phone as nothing more than a host with
a point to point link to the network, and then just writing an IPv6 over
3GPP link RFC, and therefore supporting standard IPv6 methods for ND, RAs,
DHCPV6-PD etc. over that 3GPP link.

So whatever appears in share64 is a work around to the non-conventional
model they chose. It's going to have caveats and limitations because it
isn't conventional. If somebody does something even more unconventional
that 3GPP specs for IPv6, like a GUA router addresses rather than an LL
(which they'd have if they were using RAs, because that is what the RA RFC
says must be used) then share64 probably won't work either.


> And this time, different from my earlier experiments, the 64share
> happens on the module - i.e. there is no intermediary modem like a
> cellular USB dongle or something which would do things not in control,
> like proxy ND or proxy DHCP.
>
>
>> It was my understanding that the unconventional thing about a 3GPP
>> setup was that all traffic to all addresses within the /64 was
>> (blindly) forwarded to the UE, even if the UE uses one or more of
>> those addresses on the end of the link. I think that is only
>> possible because the link is a point to point one.
>
>
> YEs, that is the case - all addresses in the prefix are forwarded to the
> UE.  But I doubt the operator forwards to UE the packets addressed to
> the default router.  This is something I can try and report.
>
> (it would be strange that the packets addressed of the default router
>  be forwarded to the UE, but one never knows with the ppp links).
>
>
>> (Presumably the UE has a discard route for the /64 to prevent loops
>> for non-existent addresses.)
>
>
> YEs.  W/o 64share the UE installs a route for the /64 on its cellular
> interface (a "*" route on which UE does ND).  Then when doing 64share
> the UE must remove that route from the cellular interface and install it
> on its other interface (USBnet in my case).  I guess this is what you
> mean by discard route.
>
> However, it must maintain on its celluar interface the default route (a
> /128 host-based route).
>
> Alex
>
>>> As such that address too should not be used in the 'LAN'.
>>>
>>> This may lead to several textual modifications to the document.
>>> For
>>
>> example:
>>>>
>>>>
>>>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN
>>>> link.
>>>
>>>
>>>
>>> This is wrongly stated, because the UE does not own that prefix,
>>> so
>>>
>> it can't say "its IPv6 addresses".  That prefix is belonging to a
>> link not to the UE, because the operator also makes an address out of
>> it.
>>>
>>>
>>> Alex
>>>
>>> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org
>>
>>  a =C3=A9crit :
>>
>>>>
>>>> A new Request for Comments is now available in online RFC
>>>> libraries.
>>>>
>>>>
>>>> RFC 7278
>>>>
>>>> Title:      Extending an IPv6 /64 Prefix from a Third Generation
>>>>  Partnership Project (3GPP) Mobile Interface to a LAN Link
>>>> Author: C. Byrne, D. Drown, A. Vizdal Status:     Informational
>>>> Stream: IETF Date:       June 2014 Mailbox:
>>>> cameron.byrne@t-mobile.com
>>
>> ,
>>>>
>>>> dan@drown.org , ales.vizdal@t-mobile.cz
>>>>  Pages:      10 Characters:
>>>>
>>>> 19965 Updates/Obsoletes/SeeAlso:   None
>>>>
>>>> I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>>>
>>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt
>>>>
>>>> This document describes requirements for extending an IPv6 /64
>>>> prefix from a User Equipment Third Generation Partnership Project
>>>> (3GPP) radio interface to a LAN link and describes two
>>>> implementation examples.
>>>>
>>>> This document is a product of the IPv6 Operations Working Group
>>>> of
>>
>> the IETF.
>>>>
>>>>
>>>>
>>>> INFORMATIONAL: This memo provides information for the Internet
>>
>> community.
>>>>
>>>> It does not specify an Internet standard of any kind.
>>>> Distribution of this memo is unlimited.
>>>>
>>>> This announcement is sent to the IETF-Announce and rfc-dist
>>>> lists. To subscribe or unsubscribe, see
>>>> http://www.ietf.org/mailman/listinfo/ietf-announce
>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>>
>>>> For searching the RFC series, see
>>>> http://www.rfc-editor.org/search For downloading RFCs, see
>>>> http://www.rfc-editor.org/rfc.html
>>>>
>>>> Requests for special distribution should be addressed to either
>>>> the author of the RFC in question, or to
>>>> rfc-editor@rfc-editor.org
>>
>> .  Unless
>>>>
>>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>>> unlimited distribution.
>>>>
>>>>
>>>> The RFC Editor Team Association Management Solutions, LLC
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________ v6ops mailing list
>>> v6ops@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>

--001a11430a1e7d3448052c084dec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 18 Feb 2016 7:40 PM, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:=


>

>

>

> Le 17/02/2016 20:56, Mark Smith a =C3=A9crit :

>>

>>

>> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"

>> <alexandre.petr=
escu@gmail.com <mailto:alexandre.petrescu@gmail.com>>

>>

>> =C2=A0wrote:

>>>

>>>

>>> Hi,

>>>

>>> I have a comment on this RFC7278.

>>>

>>> The comment comes from the observation that the operator also =
uses

>>> =C2=A0an

>>

>> address from the 64share prefix (a global address).

>>>

>>>

>>

>> Are you sure about that?

>

>

> YEs.=C2=A0 In the UE the address of the default router is an address p=
refixed

> by the same prefix as the prefix that the UE believes is for self (the=


> 64share prefix).

>

> The default router address is not a link-local address (it's a GUA=
),

> although it could have been LL in theory.

>


And in practice. Route next hops are supposed to be LLs exce=
pt in some BGP cases.


Share64 is based on the premise that the whole /64 is routed=
 to the UE. I don't know a lot about the 3GPP specs, but I presume that=
 is what they say is to happen.


I think the fundamental issue is that the 3GPP people decide=
d to treat a smartphone as special, and came up with their own ways of doin=
g IPv6 on them, rather than just treating the phone as nothing more than a =
host with a point to point link to the network, and then just writing an IP=
v6 over 3GPP link RFC, and therefore supporting standard IPv6 methods for N=
D, RAs, DHCPV6-PD etc. over that 3GPP link.


So whatever appears in share64 is a work around to the non-c=
onventional model they chose. It's going to have caveats and limitation=
s because it isn't conventional. If somebody does something even more u=
nconventional that 3GPP specs for IPv6, like a GUA router addresses rather =
than an LL (which they'd have if they were using RAs, because that is w=
hat the RA RFC says must be used) then share64 probably won't work eith=
er.




> And this time, different from my earlier experiments, t=
he 64share

> happens on the module - i.e. there is no intermediary modem like a

> cellular USB dongle or something which would do things not in control,=


> like proxy ND or proxy DHCP.

>

>

>> It was my understanding that the unconventional thing about a 3GPP=


>> setup was that all traffic to all addresses within the /64 was

>> (blindly) forwarded to the UE, even if the UE uses one or more of<=
br>
>> those addresses on the end of the link. I think that is only

>> possible because the link is a point to point one.

>

>

> YEs, that is the case - all addresses in the prefix are forwarded to t=
he

> UE.=C2=A0 But I doubt the operator forwards to UE the packets addresse=
d to

> the default router.=C2=A0 This is something I can try and report.

>

> (it would be strange that the packets addressed of the default router<=
br>
> =C2=A0be forwarded to the UE, but one never knows with the ppp links).=


>

>

>> (Presumably the UE has a discard route for the /64 to prevent loop=
s

>> for non-existent addresses.)

>

>

> YEs.=C2=A0 W/o 64share the UE installs a route for the /64 on its cell=
ular

> interface (a "*" route on which UE does ND).=C2=A0 Then when=
 doing 64share

> the UE must remove that route from the cellular interface and install =
it

> on its other interface (USBnet in my case).=C2=A0 I guess this is what=
 you

> mean by discard route.

>

> However, it must maintain on its celluar interface the default route (=
a

> /128 host-based route).

>

> Alex

>

>>> As such that address too should not be used in the 'LAN=
9;.

>>>

>>> This may lead to several textual modifications to the document=
.

>>> For

>>

>> example:

>>>>

>>>>

>>>> R-2: The UE MUST defend all of its IPv6 addresses on the L=
AN

>>>> link.

>>>

>>>

>>>

>>> This is wrongly stated, because the UE does not own that prefi=
x,

>>> so

>>>

>> it can't say "its IPv6 addresses".=C2=A0 That prefix=
 is belonging to a

>> link not to the UE, because the operator also makes an address out=
 of

>> it.

>>>

>>>

>>> Alex

>>>

>>> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org

>>

>> <mailto:rfc-editor=
@rfc-editor.org> a =C3=A9crit :

>>

>>>>

>>>> A new Request for Comments is now available in online RFC<=
br>
>>>> libraries.

>>>>

>>>>

>>>> RFC 7278

>>>>

>>>> Title:=C2=A0 =C2=A0 =C2=A0 Extending an IPv6 /64 Prefix fr=
om a Third Generation

>>>> =C2=A0Partnership Project (3GPP) Mobile Interface to a LAN=
 Link

>>>> Author: C. Byrne, D. Drown, A. Vizdal Status:=C2=A0 =C2=A0=
 =C2=A0Informational

>>>> Stream: IETF Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0June 2014 Mai=
lbox:

>>>> cameron.byrn=
e@t-mobile.com

>>

>> <mailto:cameron.b=
yrne@t-mobile.com>,

>>>>

>>>> dan@drown.org <mai=
lto:dan@drown.org>, ales.vizdal@t-mobile.cz

>>>> <mailto:ales=
.vizdal@t-mobile.cz> Pages:=C2=A0 =C2=A0 =C2=A0 10 Characters:

>>>>

>>>> 19965 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

>>>>

>>>> I-D Tag:=C2=A0 =C2=A0 draft-ietf-v6ops-64share-10.txt

>>>>

>>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt

>>>>

>>>> This document describes requirements for extending an IPv6=
 /64

>>>> prefix from a User Equipment Third Generation Partnership =
Project

>>>> (3GPP) radio interface to a LAN link and describes two

>>>> implementation examples.

>>>>

>>>> This document is a product of the IPv6 Operations Working =
Group

>>>> of

>>

>> the IETF.

>>>>

>>>>

>>>>

>>>> INFORMATIONAL: This memo provides information for the Inte=
rnet

>>

>> community.

>>>>

>>>> It does not specify an Internet standard of any kind.

>>>> Distribution of this memo is unlimited.

>>>>

>>>> This announcement is sent to the IETF-Announce and rfc-dis=
t

>>>> lists. To subscribe or unsubscribe, see

>>>> http://www.ietf.org/mailman/listinfo/ietf-announce

>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

>>>>

>>>> For searching the RFC series, see

>>>> http://www.rf=
c-editor.org/search For downloading RFCs, see

>>>> http://www.=
rfc-editor.org/rfc.html

>>>>

>>>> Requests for special distribution should be addressed to e=
ither

>>>> the author of the RFC in question, or to

>>>> rfc-editor@rf=
c-editor.org

>>

>> <mailto:rfc-editor=
@rfc-editor.org>.=C2=A0 Unless

>>>>

>>>> specifically noted otherwise on the RFC itself, all RFCs a=
re for

>>>> unlimited distribution.

>>>>

>>>>

>>>> The RFC Editor Team Association Management Solutions, LLC<=
br>
>>>>

>>>>

>>>>

>>>

>>> _______________________________________________ v6ops mailing =
list

>>> v6ops@ietf.org <mailt=
o:v6ops@ietf.org>

>>> https:=
//www.ietf.org/mailman/listinfo/v6ops

>>

>>




--001a11430a1e7d3448052c084dec--


From nobody Thu Feb 18 03:17:25 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C501B2FBE for ; Thu, 18 Feb 2016 03:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIqQ2Ef_ud-i for ; Thu, 18 Feb 2016 03:17:23 -0800 (PST)
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 DDA781B336A for ; Thu, 18 Feb 2016 03:17:22 -0800 (PST)
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 u1IBHJWJ007387; Thu, 18 Feb 2016 12:17:19 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C90372040CB; Thu, 18 Feb 2016 12:25:47 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B18582040CA; Thu, 18 Feb 2016 12:25:47 +0100 (CET)
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 u1IBHJjD001565; Thu, 18 Feb 2016 12:17:19 +0100
To: Erik Kline 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C5A83F.7030603@gmail.com>
Date: Thu, 18 Feb 2016 12:17:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 11:17:24 -0000

Le 18/02/2016 10:13, Erik Kline a ĂŠcrit :
>> The default router address is not a link-local address (it's a GUA),
>> although it could have been LL in theory.
>
> According to whom/what?
>
> I have Android device on my desk with route like this:
>
>      ::/0 -> fe80::e06f:31f4:feb2:53d6 rmnet_data0

I have Yocto device in the lab with route like this:

        ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0

The forwarding flag is set.

If I reset forwarding then I get two default routes:

        ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0
        ::/0 -> fe80::InterfaceID               rmnet0

Alex

>


From nobody Thu Feb 18 03:22:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05851B3630 for ; Thu, 18 Feb 2016 03:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMcCQzSKqHGz for ; Thu, 18 Feb 2016 03:22:13 -0800 (PST)
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 1FE361B3582 for ; Thu, 18 Feb 2016 03:22:11 -0800 (PST)
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 u1IBM9pF030060; Thu, 18 Feb 2016 12:22:09 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0ED302040C0; Thu, 18 Feb 2016 12:30:38 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0235D20406B; Thu, 18 Feb 2016 12:30:38 +0100 (CET)
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 u1IBM9lO004642; Thu, 18 Feb 2016 12:22:09 +0100
To: Mark Smith 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C5A961.6080501@gmail.com>
Date: Thu, 18 Feb 2016 12:22:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 11:22:16 -0000

Le 18/02/2016 10:50, Mark Smith a ĂŠcrit :
>
> On 18 Feb 2016 7:40 PM, "Alexandre Petrescu"
> >
> wrote:
>>
>>
>>
>> Le 17/02/2016 20:56, Mark Smith a ĂŠcrit :
>>>
>>>
>>> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
>>> >> 
>  >>
>>>
>>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have a comment on this RFC7278.
>>>>
>>>> The comment comes from the observation that the operator also
>>>> uses an
>>>
>>> address from the 64share prefix (a global address).
>>>>
>>>>
>>>
>>> Are you sure about that?
>>
>>
>> YEs.  In the UE the address of the default router is an address
>> prefixed by the same prefix as the prefix that the UE believes is
>> for self (the 64share prefix).
>>
>> The default router address is not a link-local address (it's a
>> GUA), although it could have been LL in theory.
>>
>
> And in practice. Route next hops are supposed to be LLs except in
> some BGP cases.

I agree that route next hops are better LLs (or ULAs) in order to save
addressing space.  I think there is a draft about this.

> Share64 is based on the premise that the whole /64 is routed to the
> UE.

Yes.

> I don't know a lot about the 3GPP specs, but I presume that is what
> they say is to happen.
>
> I think the fundamental issue is that the 3GPP people decided to
> treat a smartphone as special, and came up with their own ways of
> doing IPv6 on them, rather than just treating the phone as nothing
> more than a host with a point to point link to the network, and then
> just writing an IPv6 over 3GPP link RFC, and therefore supporting
> standard IPv6 methods for ND, RAs, DHCPV6-PD etc. over that 3GPP
> link.
>
> So whatever appears in share64 is a work around to the
> non-conventional model they chose. It's going to have caveats and
> limitations because it isn't conventional. If somebody does something
> even more unconventional that 3GPP specs for IPv6, like a GUA router
> addresses rather than an LL (which they'd have if they were using
> RAs, because that is what the RA RFC says must be used) then share64
> probably won't work either.

I can agree.

It is even worse because we can't make definitive statements whether it
will work or not.  We dont know.  In some cases the random number
generators of IP-over-USB implementations may collide with the ppp
Interface ID generators on the cellular SGSN and this may lead to
disconnections of the devices behind the UE (in the moving network) or 
of the UE altogether.

Alex

>
>
>> And this time, different from my earlier experiments, the 64share
>> happens on the module - i.e. there is no intermediary modem like a
>> cellular USB dongle or something which would do things not in
>> control, like proxy ND or proxy DHCP.
>>
>>
>>> It was my understanding that the unconventional thing about a
>>> 3GPP setup was that all traffic to all addresses within the /64
>>> was (blindly) forwarded to the UE, even if the UE uses one or
>>> more of those addresses on the end of the link. I think that is
>>> only possible because the link is a point to point one.
>>
>>
>> YEs, that is the case - all addresses in the prefix are forwarded
>> to the UE.  But I doubt the operator forwards to UE the packets
>> addressed to the default router.  This is something I can try and
>> report.
>>
>> (it would be strange that the packets addressed of the default
>> router be forwarded to the UE, but one never knows with the ppp
>> links).
>>
>>
>>> (Presumably the UE has a discard route for the /64 to prevent
>>> loops for non-existent addresses.)
>>
>>
>> YEs.  W/o 64share the UE installs a route for the /64 on its
>> cellular interface (a "*" route on which UE does ND).  Then when
>> doing 64share the UE must remove that route from the cellular
>> interface and install it on its other interface (USBnet in my
>> case).  I guess this is what you mean by discard route.
>>
>> However, it must maintain on its celluar interface the default
>> route (a /128 host-based route).
>>
>> Alex
>>
>>>> As such that address too should not be used in the 'LAN'.
>>>>
>>>> This may lead to several textual modifications to the
>>>> document. For
>>>
>>> example:
>>>>>
>>>>>
>>>>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN
>>>>> link.
>>>>
>>>>
>>>>
>>>> This is wrongly stated, because the UE does not own that
>>>> prefix, so
>>>>
>>> it can't say "its IPv6 addresses".  That prefix is belonging to
>>> a link not to the UE, because the operator also makes an address
>>> out of it.
>>>>
>>>>
>>>> Alex
>>>>
>>>> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org
> 
>>>
>>>  > a ĂŠcrit :
>>>
>>>>>
>>>>> A new Request for Comments is now available in online RFC
>>>>> libraries.
>>>>>
>>>>>
>>>>> RFC 7278
>>>>>
>>>>> Title:      Extending an IPv6 /64 Prefix from a Third
>>>>> Generation Partnership Project (3GPP) Mobile Interface to a
>>>>> LAN Link Author: C. Byrne, D. Drown, A. Vizdal Status:
>>>>> Informational Stream: IETF Date:       June 2014 Mailbox:
>>>>> cameron.byrne@t-mobile.com
>>>>> 
>>>
>>> >> >,
>>>>>
>>>>> dan@drown.org   >, ales.vizdal@t-mobile.cz
> 
>>>>> >>>> >
> Pages:      10 Characters:
>>>>>
>>>>> 19965 Updates/Obsoletes/SeeAlso:   None
>>>>>
>>>>> I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>>>>
>>>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt
>>>>>
>>>>> This document describes requirements for extending an IPv6
>>>>> /64 prefix from a User Equipment Third Generation Partnership
>>>>> Project (3GPP) radio interface to a LAN link and describes
>>>>> two implementation examples.
>>>>>
>>>>> This document is a product of the IPv6 Operations Working
>>>>> Group of
>>>
>>> the IETF.
>>>>>
>>>>>
>>>>>
>>>>> INFORMATIONAL: This memo provides information for the
>>>>> Internet
>>>
>>> community.
>>>>>
>>>>> It does not specify an Internet standard of any kind.
>>>>> Distribution of this memo is unlimited.
>>>>>
>>>>> This announcement is sent to the IETF-Announce and rfc-dist
>>>>> lists. To subscribe or unsubscribe, see
>>>>> http://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>>>
>>>>> For searching the RFC series, see
>>>>> http://www.rfc-editor.org/search For downloading RFCs, see
>>>>> http://www.rfc-editor.org/rfc.html
>>>>>
>>>>> Requests for special distribution should be addressed to
>>>>> either the author of the RFC in question, or to
>>>>> rfc-editor@rfc-editor.org 
>>>
>>>  >.  Unless
>>>>>
>>>>> specifically noted otherwise on the RFC itself, all RFCs are
>>>>> for unlimited distribution.
>>>>>
>>>>>
>>>>> The RFC Editor Team Association Management Solutions, LLC
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org 
>>>>  >
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>


From nobody Thu Feb 18 05:24:32 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC181A86E0 for ; Thu, 18 Feb 2016 05:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGLjAjeuw8NF for ; Thu, 18 Feb 2016 05:24:28 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 EBDE81A87A5 for ; Thu, 18 Feb 2016 05:24:26 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 181AF62C87 for ; Thu, 18 Feb 2016 14:24:24 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9FD8D600FC for ; Thu, 18 Feb 2016 14:24:23 +0100 (CET)
Received: (qmail 78361 invoked by uid 1007); 18 Feb 2016 14:24:23 +0100
Date: Thu, 18 Feb 2016 14:24:23 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20160218132423.GI21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com>  <56C5A83F.7030603@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56C5A83F.7030603@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 13:24:30 -0000

Hi,

On Thu, Feb 18, 2016 at 12:17:19PM +0100, Alexandre Petrescu wrote:
> If I reset forwarding then I get two default routes:
> 
>         ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0
>         ::/0 -> fe80::InterfaceID               rmnet0

This very much looks like "something in your lab setup is funny"

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Thu Feb 18 06:32:22 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1340C1ABB19 for ; Thu, 18 Feb 2016 06:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuwN7nv0i7St for ; Thu, 18 Feb 2016 06:32:19 -0800 (PST)
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 33F321A904D for ; Thu, 18 Feb 2016 06:32:10 -0800 (PST)
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 u1IEW7Cv022749; Thu, 18 Feb 2016 15:32:07 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F08BD202106; Thu, 18 Feb 2016 15:40:35 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D7D2B20C048; Thu, 18 Feb 2016 15:40:35 +0100 (CET)
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 u1IEW7eF011470; Thu, 18 Feb 2016 15:32:07 +0100
To: Gert Doering 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com>  <56C5A83F.7030603@gmail.com> <20160218132423.GI21153@Space.Net>
From: Alexandre Petrescu 
Message-ID: <56C5D5E7.6070508@gmail.com>
Date: Thu, 18 Feb 2016 15:32:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160218132423.GI21153@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 14:32:21 -0000

Le 18/02/2016 14:24, Gert Doering a écrit :
> Hi,
>
> On Thu, Feb 18, 2016 at 12:17:19PM +0100, Alexandre Petrescu wrote:
>> If I reset forwarding then I get two default routes:
>>
>>          ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0
>>          ::/0 -> fe80::InterfaceID               rmnet0
>
> This very much looks like "something in your lab setup is funny"

It's funny because only one default route is necessary the other is 
superfluous.

But it's in yocto that funny, or maybe something in the RA the operator 
sends.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Thu Feb 18 07:47:14 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010531A8AAF for ; Thu, 18 Feb 2016 07:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiP0LnTGX3-Q for ; Thu, 18 Feb 2016 07:47:11 -0800 (PST)
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 19B7B1A1A87 for ; Thu, 18 Feb 2016 07:47:11 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id q63so33406952pfb.0 for ; Thu, 18 Feb 2016 07:47:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=wxpChRsXfzRSUiMWfCIY/50BWsTkAQWort0tfWl+62E=; b=uhPuxGRsipzfeV4k4bfs1GY3fP1iwcJquIRt0hyNytJ3CvvGhqpFk5Rj4zjYsSutB9 ViQ+m5n8weLF0PuhwaXKWXis/+JcJtpMGnyrHfSd9cuMGLkuMBHKtlOAYdCTAtubM7r7 smwNb5BeYlJoCyO2h18bAEvqOIcLPTPYqwPqrS+z3qU/MBZgxrxjjW40zyHMfy/i0zTS BhqgVAT8kOom1Cm8g7y8wbjlEoTrNUTxOeATMWHyOrdk0oP7a99cR6KLLp3lOEftafJs HGV/maW+5606exvkMY+5ArjPkV1Z3msfHmsIxoKzUWXs2R7DXYqjs4MnaQSZ9L4GFYwR 5XvA==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=wxpChRsXfzRSUiMWfCIY/50BWsTkAQWort0tfWl+62E=; b=dWbCpmy3916YBKOgHImKIGa+i6MLDjU94Pe7YoEH6PouOMsEehWYFyW+Qe+lG7oAF+ Bix5TcRhNRSdsfrx3WdhDU3Y+EHYP2isHjHu4qZDQcaWvgyJ8pYaXz8HkRMvThYmeLTz nICgBbp6Uq5rO3UTBiUQr2Ei1SFUr4KBQHP73BmhxfqTgxGf+JxlyxdxWx5l0MxZxn32 NiobjprARVwb/xdnFgSvCRdePJWCFvdY+WKqOJ5DhffnTdCScE41jeoXJChhK46d1mYF e+ePt4jMtTxxAy9QNHQc6GKp+18sgmSaXmeSFBygzyLsx3n6wJTYpzKDOA45mmBoHaHw pZhw==
X-Gm-Message-State: AG10YORPWpSNcjlDOcJuAiRwUXsRlv0mdLgTCRFhdRTSAga+a7gZRj29wU8zLcQBfh2B2g==
X-Received: by 10.98.74.23 with SMTP id x23mr11023677pfa.141.1455810430739; Thu, 18 Feb 2016 07:47:10 -0800 (PST)
Received: from [10.16.36.40] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id bx1sm11156350pab.33.2016.02.18.07.47.09 for  (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 07:47:10 -0800 (PST)
To: v6ops@ietf.org
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>
From: Jouni Korhonen 
Message-ID: <56C5E77C.8030801@gmail.com>
Date: Thu, 18 Feb 2016 07:47:08 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C490DE.8000406@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 15:47:13 -0000

2/17/2016, 7:25 AM, Alexandre Petrescu kirjoitti:
> Hi,
>
> I have a comment on this RFC7278.
>
> The comment comes from the observation that the operator also uses an
> address from the 64share prefix (a global address).
>
> As such that address too should not be used in the 'LAN'.
>
> This may lead to several textual modifications to the document.  For
> example:
>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.
>
> This is wrongly stated, because the UE does not own that prefix, so it
> can't say "its IPv6 addresses".  That prefix is belonging to a link not
> to the UE, because the operator also makes an address out of it.

I highly doubt it is the network side gear that acts "wrong". Get a 
capture of the traffic before it gets mangled by your USB dongle & 
driver. Those are known to do funny things.

- Jouni



>
> Alex
>
> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org a écrit :
>> A new Request for Comments is now available in online RFC libraries.
>>
>>
>>          RFC 7278
>>
>>          Title:      Extending an IPv6 /64 Prefix from
>>                      a Third Generation Partnership Project (3GPP)
>>                      Mobile Interface to a LAN Link
>>          Author:     C. Byrne,
>>                      D. Drown,
>>                      A. Vizdal
>>          Status:     Informational
>>          Stream:     IETF
>>          Date:       June 2014
>>          Mailbox:    cameron.byrne@t-mobile.com,
>>                      dan@drown.org,
>>                      ales.vizdal@t-mobile.cz
>>          Pages:      10
>>          Characters: 19965
>>          Updates/Obsoletes/SeeAlso:   None
>>
>>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>
>>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>>
>> This document describes requirements for extending an IPv6 /64 prefix
>> from a User Equipment Third Generation Partnership Project (3GPP)
>> radio interface to a LAN link and describes two implementation
>> examples.
>>
>> This document is a product of the IPv6 Operations Working Group of the
>> IETF.
>>
>>
>> INFORMATIONAL: This memo provides information for the Internet community.
>> It does not specify an Internet standard of any kind. Distribution of
>> this memo is unlimited.
>>
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>    http://www.ietf.org/mailman/listinfo/ietf-announce
>>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>
>> For searching the RFC series, see http://www.rfc-editor.org/search
>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>>
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>>
>>
>> The RFC Editor Team
>> Association Management Solutions, LLC
>>
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Feb 18 10:07:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0178F1ACE65 for ; Thu, 18 Feb 2016 10:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERoaWQgWdwOE for ; Thu, 18 Feb 2016 10:07:45 -0800 (PST)
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 9CD4F1ACD6F for ; Thu, 18 Feb 2016 10:07:44 -0800 (PST)
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 u1II7gL1021314 for ; Thu, 18 Feb 2016 19:07:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48BC0207AB0 for ; Thu, 18 Feb 2016 19:07:42 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 40CDA200E34 for ; Thu, 18 Feb 2016 19:07:42 +0100 (CET)
Received: from [132.166.84.73] ([132.166.84.73]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1II7fpm028253 for ; Thu, 18 Feb 2016 19:07:41 +0100
To: v6ops@ietf.org
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com>
From: Alexandre Petrescu 
Message-ID: <56C6086C.9000703@gmail.com>
Date: Thu, 18 Feb 2016 19:07:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C5E77C.8030801@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 18:07:47 -0000

Le 18/02/2016 16:47, Jouni Korhonen a écrit :
>
>
> 2/17/2016, 7:25 AM, Alexandre Petrescu kirjoitti:
>> Hi,
>>
>> I have a comment on this RFC7278.
>>
>> The comment comes from the observation that the operator also uses an
>> address from the 64share prefix (a global address).
>>
>> As such that address too should not be used in the 'LAN'.
>>
>> This may lead to several textual modifications to the document.  For
>> example:
>>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.
>>
>> This is wrongly stated, because the UE does not own that prefix, so it
>> can't say "its IPv6 addresses".  That prefix is belonging to a link not
>> to the UE, because the operator also makes an address out of it.
>
> I highly doubt it is the network side gear that acts "wrong". Get a
> capture of the traffic before it gets mangled by your USB dongle &
> driver. Those are known to do funny things.

As I said there is no dongle.  Or I am on the dongle if you wish.

I will get a capture soon.  What I suspect happening is the ppp software 
("cm" command) installing the LL default route and the RA installing the 
GUA default route.  But I will see more tomorrow.

Alex

Alex

>
> - Jouni
>
>
>
>>
>> Alex
>>
>> Le 26/06/2014 22:55, rfc-editor@rfc-editor.org a écrit :
>>> A new Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>          RFC 7278
>>>
>>>          Title:      Extending an IPv6 /64 Prefix from
>>>                      a Third Generation Partnership Project (3GPP)
>>>                      Mobile Interface to a LAN Link
>>>          Author:     C. Byrne,
>>>                      D. Drown,
>>>                      A. Vizdal
>>>          Status:     Informational
>>>          Stream:     IETF
>>>          Date:       June 2014
>>>          Mailbox:    cameron.byrne@t-mobile.com,
>>>                      dan@drown.org,
>>>                      ales.vizdal@t-mobile.cz
>>>          Pages:      10
>>>          Characters: 19965
>>>          Updates/Obsoletes/SeeAlso:   None
>>>
>>>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>>
>>>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>>>
>>> This document describes requirements for extending an IPv6 /64 prefix
>>> from a User Equipment Third Generation Partnership Project (3GPP)
>>> radio interface to a LAN link and describes two implementation
>>> examples.
>>>
>>> This document is a product of the IPv6 Operations Working Group of the
>>> IETF.
>>>
>>>
>>> INFORMATIONAL: This memo provides information for the Internet
>>> community.
>>> It does not specify an Internet standard of any kind. Distribution of
>>> this memo is unlimited.
>>>
>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>> To subscribe or unsubscribe, see
>>>    http://www.ietf.org/mailman/listinfo/ietf-announce
>>>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>
>>> For searching the RFC series, see http://www.rfc-editor.org/search
>>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>>>
>>> Requests for special distribution should be addressed to either the
>>> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>> unlimited distribution.
>>>
>>>
>>> The RFC Editor Team
>>> Association Management Solutions, LLC
>>>
>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Feb 18 11:03:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366B71B321F for ; Thu, 18 Feb 2016 11:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkQI50SqP4fy for ; Thu, 18 Feb 2016 11:03:23 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 E91E81B321B for ; Thu, 18 Feb 2016 11:03:22 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E590462C83 for ; Thu, 18 Feb 2016 20:03:19 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9F94C60178 for ; Thu, 18 Feb 2016 20:03:19 +0100 (CET)
Received: (qmail 97891 invoked by uid 1007); 18 Feb 2016 20:03:19 +0100
Date: Thu, 18 Feb 2016 20:03:19 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20160218190319.GO21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56C6086C.9000703@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 19:03:27 -0000

Hi,

On Thu, Feb 18, 2016 at 07:07:40PM +0100, Alexandre Petrescu wrote:
> As I said there is no dongle.  Or I am on the dongle if you wish.
> 
> I will get a capture soon.  What I suspect happening is the ppp software 
> ("cm" command) installing the LL default route and the RA installing the 
> GUA default route.  But I will see more tomorrow.

The whole concept of a "next hop" does not really make a sense in 3G
networks - a PDP is a point-to-point link which doesn't do ND, so "just
point into the tunnel" is what is happening behind the scenes.

Frontend implementations that pretend that this is not a PPP interface
but "some sort of lan interface with ND and next-hop relevance" are not
a problem of the standard.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Thu Feb 18 11:30:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9A1B3426 for ; Thu, 18 Feb 2016 11:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbN1yZwnIC7X for ; Thu, 18 Feb 2016 11:30:09 -0800 (PST)
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 1506B1B3424 for ; Thu, 18 Feb 2016 11:30:08 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id e185so54248011vkb.1 for ; Thu, 18 Feb 2016 11:30:08 -0800 (PST)
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-type; bh=yK69XJx0Zz4Nkb1VhFDWBE46wxHuqU9gVGwQDqesjCY=; b=jH4onTfSEL3mKqeKVtt/SQe2khpOw96w/AWh6mWmx9zlndA6AOxoYnkIfOACJmJAAc NzMs72plU89jIKzMBpNcQ4cNtsfTLGIfRes3viy4sBfBA/F3XeJJ3WTStMO8kiPUKtFE +BGF6y88PLLszLkeRxLEULXctGieepWDL8K827clh+D2QwrPZu5dd1i84Dde0fnxsWTf jlV3zh4TGBCbLfJnJE/GkIcjUYX5QRhR0Vt7WKi5CUuj4dI9npz5JZgcsv1TExbBTPT1 4A82TdXNnA7uRARzoBn+gl184bv2uO0mXYyjBCEflvOH0+dxQ5HYbbRZE2fI0bmOM2gu ONJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yK69XJx0Zz4Nkb1VhFDWBE46wxHuqU9gVGwQDqesjCY=; b=T+Rp2vRcLyG3Q+EAiZ31SsI2xLrAHuzoUX/gD4KhbVXbHRvCq1wBJgvW9vZ9t6oPvS 1/vGYCuG1qfYWjmMdxbdzuoWmOaYa0jgn0RZ3S+Tblqarb8x/d/bA19dM/a1sEGRVzua TTCHeKr5FkdaH6oF1yn2Mu6Jn4CQvnFX1qpzgFFcystFDHyZBwzx+TFOQkkahO0diLg2 K4Hdj6/xRHue4fdKahGjB+kiqCsRqifUb83vfSo0eGFwtIanbAr6DzGdZOPyBGCTVz3U f6mKwbdy+7kbY7r7C2FVlMcA3rdKfgwqVa13C9i6Yx7MtI8VqN6j+QXIxWvjC7igQSAx F1BQ==
X-Gm-Message-State: AG10YOQoxRPe2Qu1D9laS7GAkJebSmZdpZCoH1FeKcxs8+Q8njetEOGeYZwuq0Tx2vPxV1AUWHWxaUr4kDuDFA==
X-Received: by 10.31.48.216 with SMTP id w207mr7735548vkw.36.1455823803793; Thu, 18 Feb 2016 11:30:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Thu, 18 Feb 2016 11:29:34 -0800 (PST)
In-Reply-To: <20160218190319.GO21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>
From: Mark Smith 
Date: Fri, 19 Feb 2016 06:29:34 +1100
Message-ID: 
To: Gert Doering 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 19:30:10 -0000

On 19 February 2016 at 06:03, Gert Doering  wrote:
> Hi,
>
> On Thu, Feb 18, 2016 at 07:07:40PM +0100, Alexandre Petrescu wrote:
>> As I said there is no dongle.  Or I am on the dongle if you wish.
>>
>> I will get a capture soon.  What I suspect happening is the ppp software
>> ("cm" command) installing the LL default route and the RA installing the
>> GUA default route.  But I will see more tomorrow.
>
> The whole concept of a "next hop" does not really make a sense in 3G
> networks - a PDP is a point-to-point link which doesn't do ND, so "just
> point into the tunnel" is what is happening behind the scenes.
>


Actually, I think it does, and I also think ND is necessary on a
point-to-point link.

It is common for people to think that if address 2001:db8::0/127 is
present on one end of a link, then 2001:db8::1/127 must be present on
the other end of the link. So theoretically the address at the other
end doesn't need to be discovered, and packets for 2001:db8::1 can
just be sent down the link regardless.

Is that an assumption about 2001:db8::1/127 or an absolute and
indisputable fact?

It's an assumption because it is possible and quite valid to not have
2001:db8::1/127 configured on the other end of the think, and that is
why the assumption should be tested with ND before being relied on.

Here's why it matters. The support for /127s on P2P links (RFC6164)
was advocated as fixing the ping-pong problem, but the trouble is that
it doesn't guarantee it does, because it is based on the untested
assumption that both ends of the link will be configured with the
addresses in the /127 e.g.,

A-End:
address: 2001:db8::0
route: 2001:db8::0/127 via ptp-int

B-End:
address: (not configured)
route: 2001:db8::0/127 via ptp-int
or
route: :: via ptp-int

and you have a ping-pong problem with a /127 prefix on the link.

If ND was running on that link, the presence of 2001:db8::1 at the
B-End would be tested, and if not found, traffic for that address
would be dropped as (ICMPv6) destination not found, rather than
looping until the hop count expired.


Regards,
Mark.


> Frontend implementations that pretend that this is not a PPP interface
> but "some sort of lan interface with ND and next-hop relevance" are not
> a problem of the standard.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Feb 18 13:08:44 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D04B1B35AD for ; Thu, 18 Feb 2016 13:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U93L49WpJ7r for ; Thu, 18 Feb 2016 13:08:39 -0800 (PST)
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 EAB131B3433 for ; Thu, 18 Feb 2016 13:08:38 -0800 (PST)
Received: by mail-pa0-x22f.google.com with SMTP id yy13so37170623pab.3 for ; Thu, 18 Feb 2016 13:08:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=WltNeTO/SZW9UHFCw4keS3YnDP/X8H9bFGdC9NnUg6Y=; b=y52rIFCqAVjvmrDlBTK3mzqDGzhMYQRkyJf4HzgtPHNjsFNjY+YSVB+OLaKIwi/Aak jRwD3bHpNzDFBeP+6TEu8DhcT+KNQO0nTPSxwdyxeYdco8C+Q2ZdnlGPWQMGva3zjo4e Tq9CcMUv8CA3oT3uenIihD+X6Xd+DQ7EE9BN62n0ApInsTEkG4A3Q1AuO5v/fYnRYgM0 dUg3UTIsO/Azjg7YS6qxKGDMxQEC7SPeMQu0ZfOsPZPYeVkCAcOgN6kgujtBn6HQw76v slgVSd9AL5K861Y9Udv1MzZbFiLge9k0emAi92KkzQJR+pGT6aKE0Zf8MIHO+5tQrj8p 1Q3Q==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=WltNeTO/SZW9UHFCw4keS3YnDP/X8H9bFGdC9NnUg6Y=; b=JfBiNQxH0MX7ZcRJLemhL52lKzTrqTS5YR5ZAjn3tfJVplzpckhcVyseIh+1yYcEoy 6NAZehvbaWKOoi3ANWLVheIjvcQwfLvN83RyReHrAUp5oVS4oszSDsSgFMHP4Vo/2QQd IL7D6kJlnOGwfK3N/YwPUzh9/eTHXCTjw7D4Ap8AZKV7pBRusQ7JUY01jqmEE51aNawU 0REPzQ3zGLVSQKYab2VuoP3DlizgjrHQJTkpJy6nyyMdGbP98gROZmNG4EoSUk1fhQ/3 mea/5adFoLcdtSaPmg6mb2k+/0bGzBzDF/tvh6ND3vYz/+Uj7lHqv3zBbTSJsZVSEhmd /beg==
X-Gm-Message-State: AG10YOR38waDBWNecNsUSnmw3QjgcCCN+y5eFG2afrmDWEctwShvAvHqwHrVZGUBnx0sLg==
X-Received: by 10.66.141.142 with SMTP id ro14mr13077864pab.112.1455829718659;  Thu, 18 Feb 2016 13:08:38 -0800 (PST)
Received: from [10.16.36.40] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id p21sm12407278pfj.67.2016.02.18.13.08.37 for  (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 13:08:37 -0800 (PST)
To: v6ops@ietf.org
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com>
From: Jouni Korhonen 
Message-ID: <56C632D5.9000606@gmail.com>
Date: Thu, 18 Feb 2016 13:08:37 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C6086C.9000703@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 21:08:42 -0000

> I will get a capture soon.  What I suspect happening is the ppp software

And please get the capture from the GTP-U/C tunnel & its content that 
leaves the GGSN/PGW and also from the NAS signaling that the UE 
receives. Those tell quite a bit.

- Jouni


> ("cm" command) installing the LL default route and the RA installing the
> GUA default route.  But I will see more tomorrow.
>


From nobody Thu Feb 18 13:47:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7C1AC449 for ; Thu, 18 Feb 2016 13:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmwDvH1YhIym for ; Thu, 18 Feb 2016 13:47:21 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 024481A8A95 for ; Thu, 18 Feb 2016 13:47:20 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EF1DC62C91 for ; Thu, 18 Feb 2016 22:47:17 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A37AB62B16 for ; Thu, 18 Feb 2016 22:47:17 +0100 (CET)
Received: (qmail 4008 invoked by uid 1007); 18 Feb 2016 22:47:17 +0100
Date: Thu, 18 Feb 2016 22:47:17 +0100
From: Gert Doering 
To: Mark Smith 
Message-ID: <20160218214717.GQ21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wAI/bQb0EMvlZCHl"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 21:47:23 -0000

--wAI/bQb0EMvlZCHl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
> Actually, I think it does, and I also think ND is necessary on a
> point-to-point link.

There is not much to discover on a true point-to-point link without
a multiaccess link layer below - think SDH/SONET, think PPP=20
encapsulation.

> It is common for people to think that if address 2001:db8::0/127 is
> present on one end of a link, then 2001:db8::1/127 must be present on
> the other end of the link. So theoretically the address at the other
> end doesn't need to be discovered, and packets for 2001:db8::1 can
> just be sent down the link regardless.

A true point-to-point link does not have a "netmask" (/127) associated
with it.  It has an "this is my address", and it could have "this is
their address", or "point that range of IP addresses down the link".

Of course many operating systems require configuration of /netbits
on ptp links, so it looks like "there is a network associated with it" -
but it isn't.  It's "us" and "them", and nothing whatsoever requires
that they are part of the same network.

Especially not in IPv6 where you have fe80:: to cover negotiations=20
between both sides (like, "talk OSPF to me, baby").

> Is that an assumption about 2001:db8::1/127 or an absolute and
> indisputable fact?

It's an implementation peculiarity.

[..]
> If ND was running on that link, the presence of 2001:db8::1 at the
> B-End would be tested, and if not found, traffic for that address
> would be dropped as (ICMPv6) destination not found, rather than
> looping until the hop count expired.

If ND was running on that link, you'd have ND exhaustion attacks instead,
so not much won.  Just not looping back packets that came from the ptp link
you'd send them to is a much smarter way to handle this.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--wAI/bQb0EMvlZCHl
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVsY75d9WwGXkzn/FAQIB9Q//dPxX0WjerDUI/O7utBNYt1E9+7Yo10sE
hlrChfgxkd/Hsh6+tQIH9LYylJyP0w1sZ1i0x0fqGxhoEiSdD2r7/2+pN9uOgwLk
PuLW4s5Arml8igixRblK7ZyMtyVfsrj8jcYgZBBAGc/9e+oTfSh1nA56a0CWXCMB
SdqxSyUiTYDk8z8DsYGwHJ2Yqf0HftFsB6pP8oX+MxieeDeijih6Mi6KyzNpg60X
LMCncRG0qyO5A5dbkErG/KXFltuc7O+ORJU2w9612lBfblyMnX9SO5/KRNPvkRCQ
pHXP1cCbCecyW7m5oS4sw+Yp8q9Cee8WAZ72zyY+7t6gIaQRADapRu+hHSJIqxjA
RPFZT9V/XaBEZTMfhrNLJD5Sb6dedHxAbtkZR+SbyfmCrP5mkasS8tCGZF1GD6tU
KgfGgrjntLnfB+6z1FRzI1m5CiIq9GM1wPPgXUAY4soVFiGH+W42kDJqhfC9/jnA
eVR0aA4OwDWshxAHj7xWxM+beskuuYQkEQVNOVBUpAoTTbcB1mQKsY4+Uv9+sxuL
hHlrJiUdBbj/K52HhIaXqIYk81FSsIVnZabVa9eNsLOEO91EkBy4K2vaQ5pM/TZS
dYM0NyMaojNnW2uTM7qftBLiLUQxmwmMho9a39mOANY4m1N0U4WjCqQLY2pKHT7X
iNdW6wNScKA=
=+CxD
-----END PGP SIGNATURE-----

--wAI/bQb0EMvlZCHl--


From nobody Thu Feb 18 15:04:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD21B3756 for ; Thu, 18 Feb 2016 15:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-znZoPpaY0k for ; Thu, 18 Feb 2016 15:04:07 -0800 (PST)
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 B8C6A1B3755 for ; Thu, 18 Feb 2016 15:04:06 -0800 (PST)
Received: by mail-vk0-x233.google.com with SMTP id k196so59671405vka.0 for ; Thu, 18 Feb 2016 15:04:06 -0800 (PST)
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:content-type; bh=TreJMwbIDNdfNpF37SW8yoQ8Im4VXVmztexi1u4Z5BE=; b=adJLv/rNyJ9HirEcjiCmh94B138HIK3/Ofz4t+BFTjaVCO3EmhVY6uVu7T7Ej4sj9x mGApu2tWghvEbKgGX7iWrkESlttCY98w5Oe/L6RsfNiNL6KjucvzbGG6myxsQazL+h4m iFjZ3IGoI7DVd5UCSpEU82Nvjgg9wvGsr46qZ8GCd4+UQvsioGRL019eNexUv33rksXX GYRmVfq4qha+78iCtxINBPk3kzfLwJPpWNS0kPFWl6+gckGivTLb/Xv1pAKtUWgpDx7y gIXhiGS4pgMR5bhzrwm+ZlxtLui1qk5YPikAqqNYPLpRq1rSi8o6PK1shMNEcwU/h0zl dVtg==
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-type; bh=TreJMwbIDNdfNpF37SW8yoQ8Im4VXVmztexi1u4Z5BE=; b=H8l5IovZvAEX+J9Zf2habTSrgwX8CwSJk3o/ji5/sryN1G+d/+b2Sn7GyYlNTtFAX6 citCuxYd21M+fMwmvBTxF+ev9m8ohlG+MwelYenxpjtDBfDkUHiQ2JjdijcLQPdKY//1 0iDEKO1BJ9Nsx6zoi04Mt0Z5vqlnFh7BY9jFa5EUeI/AqxpGZ0xCyUhHvzkJO+FsA3wb WOj+xzmFYfSzUO4av5rxBtn6S3MzhQqRIpJPL0YBoSdWWPI8yyUXN44JvgpQ9O9PI04f s7/Fo9BUdUWE4Um3cYa+Ji9nua3hRUf7uIGI5jtFjcNUBKNWD0HkrJaIX2lfo99gD3wl Rqug==
X-Gm-Message-State: AG10YOQg+csHIaWoeU0ZPN5L6kPrkRkpuPulJNPek+pDoFdO9Bu4/6l0fcTilwg7szByyTdlnpUHv6IDCQCr5g==
MIME-Version: 1.0
X-Received: by 10.31.167.195 with SMTP id q186mr8123898vke.113.1455836645885;  Thu, 18 Feb 2016 15:04:05 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Thu, 18 Feb 2016 15:04:05 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Thu, 18 Feb 2016 15:04:05 -0800 (PST)
In-Reply-To: <20160218214717.GQ21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>  <20160218214717.GQ21153@Space.Net>
Date: Fri, 19 Feb 2016 10:04:05 +1100
Message-ID: 
From: Mark Smith 
To: Gert Doering 
Content-Type: multipart/alternative; boundary=001a11425fba210c76052c136246
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Feb 2016 23:04:08 -0000

--001a11425fba210c76052c136246
Content-Type: text/plain; charset=UTF-8

On 19 Feb 2016 8:47 AM, "Gert Doering"  wrote:
>
> Hi,
>
> On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
> > Actually, I think it does, and I also think ND is necessary on a
> > point-to-point link.
>
> There is not much to discover on a true point-to-point link without
> a multiaccess link layer below - think SDH/SONET, think PPP
> encapsulation.
>

Whether or not the address implied by the prefix length actually exists is
what needs to be discovered.

It is "neighbor discovery", not "neighbor link layer address discovery on
the assumption that the address always exists for links that have link
layer addresses."

> > It is common for people to think that if address 2001:db8::0/127 is
> > present on one end of a link, then 2001:db8::1/127 must be present on
> > the other end of the link. So theoretically the address at the other
> > end doesn't need to be discovered, and packets for 2001:db8::1 can
> > just be sent down the link regardless.
>
> A true point-to-point link does not have a "netmask" (/127) associated
> with it.  It has an "this is my address", and it could have "this is
> their address", or "point that range of IP addresses down the link".
>

A prefix length is a statement of the range of addresses that might by on
the link, and that is it. The only way to determine if an address is on the
link is to either actively probe for it (" discover " it), or to observe if
traffic comes from it.

Does a /64 prefix assignment guarantee all 2^64 addresses are present on
the link? Does a /120 assignment guarantee all 2^8 addresses are present on
the link? Does a /126 assignment guarantee all 2^2 addresses are present on
the link? None of them somehow guarantee that each address in the prefix is
configured on an interface attached to the link.

How does a /127 assignment make a guarantee about address presence that a
/64,
/120 or a /126 assignment doesn't, when the only difference is the prefix
length?

> Of course many operating systems require configuration of /netbits
> on ptp links, so it looks like "there is a network associated with it" -
> but it isn't.

It is the convention to sign a prefix to a p2p link and to assign addresses
to both ends from the same prefix.

  It's "us" and "them", and nothing whatsoever requires
> that they are part of the same network.
>

Certainly, I never said it was requirement.

So you configure 2001:db8::0(/128) on your end of the link, and configure a
route for 2001:db8:1::18/128 pointing out the p2p link.

I'm lazy, and on my end of the link I don't bother to configure
2001:db8:1::18(/128).

Does an error occur telling you that I haven't? Is this an invalid scenario
(ie., a link assigned more address space than there are devices configured
with the addresses)?

> Especially not in IPv6 where you have fe80:: to cover negotiations
> between both sides (like, "talk OSPF to me, baby").
>
> > Is that an assumption about 2001:db8::1/127 or an absolute and
> > indisputable fact?
>
> It's an implementation peculiarity.
>
> [..]
> > If ND was running on that link, the presence of 2001:db8::1 at the
> > B-End would be tested, and if not found, traffic for that address
> > would be dropped as (ICMPv6) destination not found, rather than
> > looping until the hop count expired.
>
> If ND was running on that link, you'd have ND exhaustion attacks instead,
> so not much won.  Just not looping back packets that came from the ptp
link
> you'd send them to is a much smarter way to handle this.
>

A /127 without ND trades one type of attack the possibility of another. ND
on a /127 mitigates both.

Regards,
Mark.

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--001a11425fba210c76052c136246
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 19 Feb 2016 8:47 AM, "Gert Doering" <gert@space.net> wrote:

>

> Hi,

>

> On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:

> > Actually, I think it does, and I also think ND is necessary on a<=
br>
> > point-to-point link.

>

> There is not much to discover on a true point-to-point link without
> a multiaccess link layer below - think SDH/SONET, think PPP

> encapsulation.

>


Whether or not the address implied by the prefix length actu=
ally exists is what needs to be discovered.


It is "neighbor discovery", not "neighbor lin=
k layer address discovery on the assumption that the address always exists =
for links that have link layer addresses."


> > It is common for people to think that if address 2=
001:db8::0/127 is

> > present on one end of a link, then 2001:db8::1/127 must be presen=
t on

> > the other end of the link. So theoretically the address at the ot=
her

> > end doesn't need to be discovered, and packets for 2001:db8::=
1 can

> > just be sent down the link regardless.

>

> A true point-to-point link does not have a "netmask" (/127) =
associated

> with it.=C2=A0 It has an "this is my address", and it could =
have "this is

> their address", or "point that range of IP addresses down th=
e link".

>


A prefix length is a statement of the range of addresses tha=
t might by on the link, and that is it. The only way to determine if an add=
ress is on the link is to either actively probe for it (" discover &qu=
ot; it), or to observe if traffic comes from it.


Does a /64 prefix assignment guarantee all 2^64 addresses ar=
e present on the link? Does a /120 assignment guarantee all 2^8 addresses a=
re present on the link? Does a /126 assignment guarantee all 2^2 addresses =
are present on the link? None of them somehow guarantee that each address i=
n the prefix is configured on an interface attached to the link.


How does a /127 assignment make a guarantee about address pr=
esence that a /64, 

/120 or a /126 assignment doesn't, when the only difference is the pref=
ix length?


> Of course many operating systems require configuration =
of /netbits

> on ptp links, so it looks like "there is a network associated wit=
h it" -

> but it isn't.


It is the convention to sign a prefix to a p2p link and to a=
ssign addresses to both ends from the same prefix.


=C2=A0 It's "us" and "them", and not=
hing whatsoever requires

> that they are part of the same network.

>


Certainly, I never said it was requirement. 


So you configure 2001:db8::0(/128) on your end of the link, =
and configure a route for 2001:db8:1::18/128 pointing out the p2p link.


I'm lazy, and on my end of the link I don't bother t=
o configure 2001:db8:1::18(/128).


Does an error occur telling you that I haven't? Is this =
an invalid scenario (ie., a link assigned more address space than there are=
 devices configured with the addresses)?


> Especially not in IPv6 where you have fe80:: to cover n=
egotiations

> between both sides (like, "talk OSPF to me, baby").

>

> > Is that an assumption about 2001:db8::1/127 or an absolute and
> > indisputable fact?

>

> It's an implementation peculiarity.

>

> [..]

> > If ND was running on that link, the presence of 2001:db8::1 at th=
e

> > B-End would be tested, and if not found, traffic for that address=


> > would be dropped as (ICMPv6) destination not found, rather than
> > looping until the hop count expired.

>

> If ND was running on that link, you'd have ND exhaustion attacks i=
nstead,

> so not much won.=C2=A0 Just not looping back packets that came from th=
e ptp link

> you'd send them to is a much smarter way to handle this.

>


A /127 without ND trades one type of attack the possibility =
of another. ND on a /127 mitigates both.


Regards,

Mark.


> Gert Doering

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster

> --

> have you enabled IPv6 on something today...?

>

> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard

> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr=
atsvors.: A. Grundner-Culemann

> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)

> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I=
dNr.: DE813185279




--001a11425fba210c76052c136246--


From nobody Fri Feb 19 01:35:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCDF1B2CF1 for ; Fri, 19 Feb 2016 01:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JqXX2eWTBmm for ; Fri, 19 Feb 2016 01:35:07 -0800 (PST)
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 09D411B2CEE for ; Fri, 19 Feb 2016 01:35:06 -0800 (PST)
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 u1J9Z4uE024754 for ; Fri, 19 Feb 2016 10:35:04 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AAAC5203ABC for ; Fri, 19 Feb 2016 10:35:05 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 98EC820268D for ; Fri, 19 Feb 2016 10:35:05 +0100 (CET)
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 u1J9Z4bE032110 for ; Fri, 19 Feb 2016 10:35:04 +0100
To: v6ops@ietf.org
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com>
From: Alexandre Petrescu 
Message-ID: <56C6E1C8.2080907@gmail.com>
Date: Fri, 19 Feb 2016 10:35:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C632D5.9000606@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 09:35:09 -0000

Le 18/02/2016 22:08, Jouni Korhonen a écrit :
>> I will get a capture soon.  What I suspect happening is the ppp software
>
> And please get the capture from the GTP-U/C tunnel & its content that
> leaves the GGSN/PGW and also from the NAS signaling that the UE
> receives. Those tell quite a bit.

That's going to be hard if not impossible.

The 64share technique relies on changes on only the UE.

Alex

>
> - Jouni
>
>
>> ("cm" command) installing the LL default route and the RA installing the
>> GUA default route.  But I will see more tomorrow.
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Fri Feb 19 01:44:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AD81A905A for ; Fri, 19 Feb 2016 01:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBR1SyWob2VV for ; Fri, 19 Feb 2016 01:44:39 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 110601A8AAC for ; Fri, 19 Feb 2016 01:44:38 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D75C662C8B for ; Fri, 19 Feb 2016 10:44:36 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6351E60701 for ; Fri, 19 Feb 2016 10:44:36 +0100 (CET)
Received: (qmail 49866 invoked by uid 1007); 19 Feb 2016 10:44:36 +0100
Date: Fri, 19 Feb 2016 10:44:36 +0100
From: Gert Doering 
To: Alexandre Petrescu 
Message-ID: <20160219094436.GT21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <56C6E1C8.2080907@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 09:44:42 -0000

Hi,

On Fri, Feb 19, 2016 at 10:35:04AM +0100, Alexandre Petrescu wrote:
> Le 18/02/2016 22:08, Jouni Korhonen a écrit :
> >> I will get a capture soon.  What I suspect happening is the ppp software
> >
> > And please get the capture from the GTP-U/C tunnel & its content that
> > leaves the GGSN/PGW and also from the NAS signaling that the UE
> > receives. Those tell quite a bit.
> 
> That's going to be hard if not impossible.
> 
> The 64share technique relies on changes on only the UE.

Your claim that it cannot work needs backing by traces.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Fri Feb 19 01:49:38 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8901B2A01 for ; Fri, 19 Feb 2016 01:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdMRhFRXtT5h for ; Fri, 19 Feb 2016 01:49:36 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 A2DB31B29F7 for ; Fri, 19 Feb 2016 01:49:35 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1663E62C93 for ; Fri, 19 Feb 2016 10:49:34 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9D5D36013B for ; Fri, 19 Feb 2016 10:49:33 +0100 (CET)
Received: (qmail 50162 invoked by uid 1007); 19 Feb 2016 10:49:33 +0100
Date: Fri, 19 Feb 2016 10:49:33 +0100
From: Gert Doering 
To: Mark Smith 
Message-ID: <20160219094933.GU21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>  <20160218214717.GQ21153@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PdAWLd+WEPmMbsbx"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 09:49:37 -0000

--PdAWLd+WEPmMbsbx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Feb 19, 2016 at 10:04:05AM +1100, Mark Smith wrote:
> On 19 Feb 2016 8:47 AM, "Gert Doering"  wrote:
> >
> > Hi,
> >
> > On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
> > > Actually, I think it does, and I also think ND is necessary on a
> > > point-to-point link.
> >
> > There is not much to discover on a true point-to-point link without
> > a multiaccess link layer below - think SDH/SONET, think PPP
> > encapsulation.
>=20
> Whether or not the address implied by the prefix length actually exists is
> what needs to be discovered.
>=20
> It is "neighbor discovery", not "neighbor link layer address discovery on
> the assumption that the address always exists for links that have link
> layer addresses."

It is not relevant.  If I point a /64 into the p2p interface (without
specifying a gateway address, because it's point-to-point: whatever I
stuff in on my side will come out at his side) I do not care whether it's
used on-link or somewhere behind the gateway.

This is a fundamental difference between "point towards a named next-hop
router on a multiaccess network" or "point into a point-to-point interface".

And in particular in the context of this discussion it is most relevant -=
=20
whatever address the network element on the other side of the PDP context=
=20
has is not relevant as it is "on the other side of a point to point link",
so "point your default route towards the ptp interface, done".

If devices choose to present this as an "ethernet-style" interface, it's
an implementer's choice - but argueing that because of this, 6share
isn't going to work is a not the correct conclusion.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--PdAWLd+WEPmMbsbx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVsblLd9WwGXkzn/FAQLM9w//YMrVNVMFlqibcAPoR0S7KQjQ3fi1SXJ/
CWbXsMrwYQaQS7+bhdBn7BXLMAA2NKWbmS4v0OMoU9F73q/YC/nMiFp7QVb6J1h/
im09V252xqrl7OPSz7P8Wys9bk5/uHfHT88qCfyUkPX7Tb4OI+VJCDlWNl2FbfE2
M3vN8BmzJOwrrEFAyfs/v31CuQ6Sl7IKuaEMl8jaF7GSLJXKxvbOPElWKf6tHri6
PKUxe9aBp5Mw0owg/PsB2wr92LLu/ICDZlm/l37l0MEer7UbboNq+Z149wh5byjN
wYcabvhft0gupKmFAtFckG8zU9v/6MxDunW9u6K8tlO90mxA14/v/7LDsfgWJbsB
deIMCVRaVgvHS7d326JwQN5/lZ77A5OZfpbCVm9szULDC1LEqzEKMy1h1xsSBwAs
PtkNTLWOdz2VORmQM8QHicmEfMybZcYGyV8/pzM82qlA0U1fj+0pJmSenNKZeMui
bYoErO9UQD/AEPdXdNabL7qJkWHysZ2/UrOlyjFzPiv9prc1lfnqBuzvXMvNvYYy
VW+CKjVtVs4lnaPv3iMn/4Pl2Os0a6cUHFNiqsqGkV8CoE0BBmPAEItwRbmFV/On
XrzAieSi1vbLYquAOdo7FlnXpyZ/kapVIY66CxYSdEzm52wBs4+W/4/T0nGpOwYR
hL926wStrcI=
=6DSl
-----END PGP SIGNATURE-----

--PdAWLd+WEPmMbsbx--


From nobody Fri Feb 19 07:54:01 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F74F1B2A82 for ; Fri, 19 Feb 2016 07:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv5mU5-yncsr for ; Fri, 19 Feb 2016 07:53:58 -0800 (PST)
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 BF5C11ACEB3 for ; Fri, 19 Feb 2016 07:53:58 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id x65so53165837pfb.1 for ; Fri, 19 Feb 2016 07:53:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=csFS4+mKn//wKdN4V3haTP8ntV0E/7xgV6WicTTtuns=; b=zN4IgOKITVb6ZGA1vVMJm7MKbaR+KXgl4GzaEl4kmVecVUlcUzGKYGGzDvs0aH6qxz 88DyVnWrxvk90IuomgYSMjk3Lph7UAq1gqpuTKOwId89Lq/n3GFN6DIjGoJAdVBajIIz m1lrGxV3I1BuYyugmncDQ0zUOZOukSg3L6AfT6PLdjnA0KEP4HgqW5Un2tNw3SQEizGy 1fIcnn9EGIgToABu+2NxZgatL1hUvCpAORmfSxbP3yNasSDHYcORHyBviVR3vWUGuucM mDrB/ZWzEq2Vym0xkhh4K766mHxfHLa9otO8D1v1a7PYZ14U51tQgxPsgo2dW/GHoKeI biYA==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=csFS4+mKn//wKdN4V3haTP8ntV0E/7xgV6WicTTtuns=; b=gVXfWSvcPfPm9CcLRsApc8c06rFGRXs7XfqLQIjZL/ssVUoD0DiPR4YIzcwPdO0VQG 0oDdt2w26B/l6RsW0iU9RaBuhv95mtYlXvCXoFWAwALS4I5FlVfMI0mFeQW/ySxR83hK if5cnpVO746nLVZSA4haXUE3C3Zn/H42T6WI66eOMoZ5dyBohaY5lZuD8b5jpzz5aqUO Y05M+hYyrAUaPfzEMxJu/CxVH3Oo1QvI2u8gvfIbLhAd8b2E8W7FZNiqHG2W5SFxb8Mc PTIXftiIPjrNjwde5zE/bd4uxVLlrFeDmjhckXlER1gMRbTe0n+WsubZMRBg1sBSCM/D tCDQ==
X-Gm-Message-State: AG10YOS0M1NHCtAw+yFS8FP5VXs8+jiFKcn6ycVwptpMSkIRu+kEgcQv7qksa2DQyja7hA==
X-Received: by 10.98.18.207 with SMTP id 76mr18849092pfs.53.1455897238467; Fri, 19 Feb 2016 07:53:58 -0800 (PST)
Received: from [10.16.36.40] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 70sm18675965pfs.78.2016.02.19.07.53.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 07:53:57 -0800 (PST)
To: Alexandre Petrescu , v6ops@ietf.org
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com>
From: Jouni Korhonen 
Message-ID: <56C73A94.6080206@gmail.com>
Date: Fri, 19 Feb 2016 07:53:56 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C6E1C8.2080907@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 15:54:00 -0000

2/19/2016, 1:35 AM, Alexandre Petrescu kirjoitti:
>
>
> Le 18/02/2016 22:08, Jouni Korhonen a écrit :
>>> I will get a capture soon.  What I suspect happening is the ppp software
>>
>> And please get the capture from the GTP-U/C tunnel & its content that
>> leaves the GGSN/PGW and also from the NAS signaling that the UE
>> receives. Those tell quite a bit.
>
> That's going to be hard if not impossible.

You need a more cooperative operator/system vendor partner ;) Anyway, 
the point being that the claims earlier in this thread are mostly 
handwaving until we actually see what goes "on wire" not what your 
application/stack/driver is made to see.

- Jouni

>
> The 64share technique relies on changes on only the UE.
>
> Alex
>
>>
>> - Jouni
>>
>>
>>> ("cm" command) installing the LL default route and the RA installing the
>>> GUA default route.  But I will see more tomorrow.
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Fri Feb 19 09:17:09 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E791B2EE3 for ; Fri, 19 Feb 2016 09:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1UBZ1Q_TV9U for ; Fri, 19 Feb 2016 09:17:06 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 8DEE81B2DAA for ; Fri, 19 Feb 2016 09:17:06 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id g6so43569903igt.1 for ; Fri, 19 Feb 2016 09:17:06 -0800 (PST)
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=AE8/de7kluy6ZmybHj9hI4JpamSUKv3Xn9n1YTkA4IA=; b=nhSKeNrh/q+UCjbujivxer/jK5U+LC55adQeEKcdxY4ca0rlwoYDY7TRBEpcnTTIdD 6h1JfKjM3U1dfCGYj/Sinq9PyUUS0AAODhB61X4+lSneWDetYtM/uqqJMa8UCiFlT4uq 1lEHOSAXExyW0y0BCGD484d+e/vjk5gYNe/qYmv+Ct+Qynzuwj1U/Q8CndY82vjJUv28 R3debV29DZHrrVpgkDMCS/nOSgpbE0G97xOmo0o8CU0XRrZHjeXM6wTBsQ/RJH9sFP+d 8qXq1M6bQPmg1O+IvA6nxiqTqwTwtiRREtQJOebksfxEMnB7CwYl6Rg/brnsP+ef7PfH gtiQ==
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=AE8/de7kluy6ZmybHj9hI4JpamSUKv3Xn9n1YTkA4IA=; b=Fi2lT3WwmO4x5a8t0OAjTOjjpjnv8yG9zJAkMG7pk8fr1bKGkKIwStGqMF15zovkvF bDX/wRmV/gYCcjnkC2BUep9Hy/JiJ4drWeN5hXyrNjXXnJaj2NC1KmiKf2ZwBUJzlO8H w2+7WMXBdjPPHsywy3jm5y0v71Y9eS9KX0nmVOt4PPuJw18fLiN/VSR6Ao0DtAb/QDVn ObFkNgaL5kgN+fRdzWHCZdcLyIK3X3Naynstm4KoqbFpQitvKCI3s1gjurLXk+j8OonL l2CdjJf1M0nY2fAlxVHShEeaaG9GvZol+yHQCOAg/LwGatPzmk7ysLdVfLKJ90E0f350 6G8g==
X-Gm-Message-State: AG10YOS33PlzTcLhYZ79vyQ/lpvEwqKa4t50rtcRf3m79p+b2At260/azsTNq4KVsseOiC2g7OQ7YpwCrTTQYQ==
MIME-Version: 1.0
X-Received: by 10.50.150.106 with SMTP id uh10mr9455535igb.41.1455902225988; Fri, 19 Feb 2016 09:17:05 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Fri, 19 Feb 2016 09:17:05 -0800 (PST)
In-Reply-To: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net> 
Date: Fri, 19 Feb 2016 09:17:05 -0800
X-Google-Sender-Auth: m2gmoHsKhUz7XknceXEsaCjO2qQ
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Mark Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 17:17:08 -0000

On Thu, Feb 18, 2016 at 11:29 AM, Mark Smith  wrote:

> Here's why it matters. The support for /127s on P2P links (RFC6164)
> was advocated as fixing the ping-pong problem, but the trouble is that
> it doesn't guarantee it does, because it is based on the untested
> assumption that both ends of the link will be configured with the
> addresses in the /127 e.g.,
>
> A-End:
> address: 2001:db8::0
> route: 2001:db8::0/127 via ptp-int
>
> B-End:
> address: (not configured)
> route: 2001:db8::0/127 via ptp-int
> or
> route: :: via ptp-int
>
> and you have a ping-pong problem with a /127 prefix on the link.

Probably off-topic in the context of this thread, but I'd like to make
a small correction: a ping-pong wouldn't happen in this case,
regardless of whether the address(es) from the /127 are actually
configured or not, or whether ND is performed in the link, as long as
the routers support Section 3.1 of RFC4443 correctly:

   One specific case in which a Destination Unreachable message is sent
   with a code 3 is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).  In such a case, the packet MUST NOT be forwarded back
   onto the arrival link.

--
JINMEI, Tatuya


From nobody Fri Feb 19 09:17:38 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483C31B32E9 for ; Fri, 19 Feb 2016 09:17:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fyS5guJ1Xxa for ; Fri, 19 Feb 2016 09:17:34 -0800 (PST)
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 0D0C51B32E4 for ; Fri, 19 Feb 2016 09:17:33 -0800 (PST)
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 u1JHHVMG021564; Fri, 19 Feb 2016 18:17:31 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EE2EC2086B5; Fri, 19 Feb 2016 18:17:32 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E2933202512; Fri, 19 Feb 2016 18:17:32 +0100 (CET)
Received: from [132.166.84.88] ([132.166.84.88]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1JHHUjK011745; Fri, 19 Feb 2016 18:17:31 +0100
To: Jouni Korhonen 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com> <56C73A94.6080206@gmail.com>
From: Alexandre Petrescu 
Message-ID: <56C74E2A.10503@gmail.com>
Date: Fri, 19 Feb 2016 18:17:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C73A94.6080206@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 17:17:36 -0000

Le 19/02/2016 16:53, Jouni Korhonen a écrit :
>
>
> 2/19/2016, 1:35 AM, Alexandre Petrescu kirjoitti:
>>
>>
>> Le 18/02/2016 22:08, Jouni Korhonen a écrit :
>>>> I will get a capture soon.  What I suspect happening is the ppp
>>>> software
>>>
>>> And please get the capture from the GTP-U/C tunnel & its content that
>>> leaves the GGSN/PGW and also from the NAS signaling that the UE
>>> receives. Those tell quite a bit.
>>
>> That's going to be hard if not impossible.
>
> You need a more cooperative operator/system vendor partner ;) Anyway,
> the point being that the claims earlier in this thread are mostly
> handwaving until we actually see what goes "on wire" not what your
> application/stack/driver is made to see.

I agree.

The RA on the wire is ok - it has the src address a LL address.  So what 
goes on the wire seems to be ok (no GUA as src address).  That address 
is the next hop of a defroute and it is ok.

On another hand, the "netmgrd" daemon on this M2M module is doing 
strange things.  Some times adds one defroute (LL), other times two 
defroutes (LL+GUA).  The kernel is not adding any defroute although it 
should.

The netmgrd software is supposedly issued in the Android world, and 
subsequently ported to a yocto OS and then re-used by legato.

yocto is an open-source linux port for ARM-5 or 6 reduced computing 
platforms, among others.

The goal here is to build what may be the smallest IPv6 pure router with 
4G and USBnet interfaces.

So whoever builds the "netmgrd" software must know that a defroute is 
only one, and typically it is a LL address.

For the packet exchange on the wire for PPP - I dont have any means to 
determine whether that is ppp protocol in the first place, it may be 
something else?  If it is ppp, maybe that link-layer exchange delivers a 
GUA instead of LL for ppp to set as default route?

If that link-layer connection establishment between the module and the 
operator delivers a GUA then it should know that nobody at IETF believes 
it right for the operator to config a GUA on the PGW in the prefix 
assigned to a UE.  BEcause if it does then the UE can not safely do 
tethering.

Alex

>
> - Jouni
>
>>
>> The 64share technique relies on changes on only the UE.
>>
>> Alex
>>
>>>
>>> - Jouni
>>>
>>>
>>>> ("cm" command) installing the LL default route and the RA installing
>>>> the
>>>> GUA default route.  But I will see more tomorrow.
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Fri Feb 19 09:25:32 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6A1B330B for ; Fri, 19 Feb 2016 09:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.383
X-Spam-Level: 
X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_22=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFatI1BlJP9t for ; Fri, 19 Feb 2016 09:25:28 -0800 (PST)
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 3B0801B330A for ; Fri, 19 Feb 2016 09:25:28 -0800 (PST)
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 u1JHPPh6023590; Fri, 19 Feb 2016 18:25:25 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5D1EF20871D; Fri, 19 Feb 2016 18:25:27 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4FC112086FC; Fri, 19 Feb 2016 18:25:27 +0100 (CET)
Received: from [132.166.84.88] ([132.166.84.88]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1JHPPKe002945; Fri, 19 Feb 2016 18:25:25 +0100
To: Gert Doering , Mark Smith 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>  <20160218214717.GQ21153@Space.Net>  <20160219094933.GU21153@Space.Net>
From: Alexandre Petrescu 
Message-ID: <56C75004.30205@gmail.com>
Date: Fri, 19 Feb 2016 18:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160219094933.GU21153@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 17:25:31 -0000

Le 19/02/2016 10:49, Gert Doering a écrit :
> Hi,
>
> On Fri, Feb 19, 2016 at 10:04:05AM +1100, Mark Smith wrote:
>> On 19 Feb 2016 8:47 AM, "Gert Doering"  wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
>>>> Actually, I think it does, and I also think ND is necessary on a
>>>> point-to-point link.
>>>
>>> There is not much to discover on a true point-to-point link without
>>> a multiaccess link layer below - think SDH/SONET, think PPP
>>> encapsulation.
>>
>> Whether or not the address implied by the prefix length actually exists is
>> what needs to be discovered.
>>
>> It is "neighbor discovery", not "neighbor link layer address discovery on
>> the assumption that the address always exists for links that have link
>> layer addresses."
>
> It is not relevant.  If I point a /64 into the p2p interface (without
> specifying a gateway address, because it's point-to-point: whatever I
> stuff in on my side will come out at his side) I do not care whether it's
> used on-link or somewhere behind the gateway.
>
> This is a fundamental difference between "point towards a named next-hop
> router on a multiaccess network" or "point into a point-to-point interface".
>
> And in particular in the context of this discussion it is most relevant -
> whatever address the network element on the other side of the PDP context
> has is not relevant as it is "on the other side of a point to point link",
> so "point your default route towards the ptp interface, done".
>
> If devices choose to present this as an "ethernet-style" interface, it's
> an implementer's choice - but argueing that because of this, 6share
> isn't going to work is a not the correct conclusion.

I think it is the correct conclusion.

Because if the operator self-assigns an address out of the prefix 
advertised to the UE then the UE must make sure noone in its tethered 
network uses that same address.  Such mechanism does not exist.

There is a real risk that someone in the tethered network uses same IP 
address as the address self-assigned on the PGW.  That address has an 
IID which appears to be random (it's not MAC-based, no ff:fe, no ::1, no 
::cafe).  The USBnet has no IEEE-guaranteed unique MAC addresses.  So 
someone on the USBnet may make a random IID (for privacy or other 
USB-specific reasons) which collide with an IID generated by PGW.  The 
same prefix on the PGW interface is used in the tethered network on USB.

When this collision happens the tethered device can not ping the 
Internet, which is a bad situation to be in.

Alex

>
> Gert Doering
>          -- NetMaster
>


From nobody Fri Feb 19 09:58:35 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D701B3345 for ; Fri, 19 Feb 2016 09:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 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, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b29mp8xcTyGN for ; Fri, 19 Feb 2016 09:58:32 -0800 (PST)
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 A8F8A1B2C56 for ; Fri, 19 Feb 2016 09:58:31 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id g62so82027665wme.0 for ; Fri, 19 Feb 2016 09:58:31 -0800 (PST)
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:content-type; bh=24RVM7odvN+ANedYj71AFXPUt1jityX+mlagDr3jJCE=; b=sT3sb1fs4vqAJuPZfQx1RERrMsax31xxnAg+QZreqTyMEJjUhihtB+eDuKKd3V63lU wFRY4QNH35Uxmi/k+h6Dt4Z81HuCP7fjVnYhQqcLd/r5Fs6nquBhCXwkVM7OfOa4kud4 yXTcazzDAqFxx6OTocZwyK2N7uHNC1X7Lh2AC68ktpiaZPslliHXLdMV+LgjF8jRv+OU bqlYakXog9+ggXCFyHFYW5/TIX1FrVgIbgOJsFPxeX2a+ZO1XVRb4+5IoWCw+bW2M9zW +3d3TlooxL58UuwIYwgIcPOAtT7zpME9Bw7J+qL0wmCDViwgDJGp2cGsj9MaTi7CDrVu lFmA==
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-type; bh=24RVM7odvN+ANedYj71AFXPUt1jityX+mlagDr3jJCE=; b=ikH0TykdqjgUlbH3hbBvejix57zWyq/LJoQquH0w277rnCM14p4PY9xDSKToPNvm3v T/Ila64eXUkecozvs4HSlcfY3SG37aPxcg5Q/OeUvRuaZxUPfRbeGIgL1rFcbv+TAc6+ V26ZNbNuFJ+dN5NNvePkzzrfA8MhZ+MVZaVvVrUPqKCHelLxI8a+beWsBBuMqTJnrRsO yNgTrD4TBNTCcbma2SMt2gjyJ0vnYEHzNliCFPJIWd9Kp53RSnI+GxDd5roX1HO58Hl/ Z609pwxnhO1GWRwqdev8evLKp38uxC+k6x26A67b30gk3kskV1EUDWrLyf7I+erLTnbh wE+w==
X-Gm-Message-State: AG10YORpNljRTyF+2S1XWAUxjk/2tEPcFh8jMJD+xvKz/zmyVv+1APL2d6NjVD6aleAqAjnxUhIxJsNBhpKj+g==
MIME-Version: 1.0
X-Received: by 10.194.78.37 with SMTP id y5mr14399413wjw.78.1455904710253; Fri, 19 Feb 2016 09:58:30 -0800 (PST)
Received: by 10.194.68.66 with HTTP; Fri, 19 Feb 2016 09:58:30 -0800 (PST)
In-Reply-To: <56C75004.30205@gmail.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>  <20160218214717.GQ21153@Space.Net>  <20160219094933.GU21153@Space.Net> <56C75004.30205@gmail.com>
Date: Fri, 19 Feb 2016 09:58:30 -0800
Message-ID: 
From: Ca By 
To: Alexandre Petrescu 
Content-Type: multipart/alternative; boundary=047d7bf0d2e414f6e9052c233bb7
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Feb 2016 17:58:33 -0000

--047d7bf0d2e414f6e9052c233bb7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 19, 2016 at 9:25 AM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 19/02/2016 10:49, Gert Doering a =C3=A9crit :
>
>> Hi,
>>
>> On Fri, Feb 19, 2016 at 10:04:05AM +1100, Mark Smith wrote:
>>
>>> On 19 Feb 2016 8:47 AM, "Gert Doering"  wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
>>>>
>>>>> Actually, I think it does, and I also think ND is necessary on a
>>>>> point-to-point link.
>>>>>
>>>>
>>>> There is not much to discover on a true point-to-point link without
>>>> a multiaccess link layer below - think SDH/SONET, think PPP
>>>> encapsulation.
>>>>
>>>
>>> Whether or not the address implied by the prefix length actually exists
>>> is
>>> what needs to be discovered.
>>>
>>> It is "neighbor discovery", not "neighbor link layer address discovery =
on
>>> the assumption that the address always exists for links that have link
>>> layer addresses."
>>>
>>
>> It is not relevant.  If I point a /64 into the p2p interface (without
>> specifying a gateway address, because it's point-to-point: whatever I
>> stuff in on my side will come out at his side) I do not care whether it'=
s
>> used on-link or somewhere behind the gateway.
>>
>> This is a fundamental difference between "point towards a named next-hop
>> router on a multiaccess network" or "point into a point-to-point
>> interface".
>>
>> And in particular in the context of this discussion it is most relevant =
-
>> whatever address the network element on the other side of the PDP contex=
t
>> has is not relevant as it is "on the other side of a point to point link=
",
>> so "point your default route towards the ptp interface, done".
>>
>> If devices choose to present this as an "ethernet-style" interface, it's
>> an implementer's choice - but argueing that because of this, 6share
>> isn't going to work is a not the correct conclusion.
>>
>
> I think it is the correct conclusion.
>
> Because if the operator self-assigns an address out of the prefix
> advertised to the UE then the UE must make sure noone in its tethered
> network uses that same address.  Such mechanism does not exist.
>
>
"operator self-assigns an address out of the prefix advertised to the UE"

The operator does not assign any address from that prefix assigned to the
UE.


There is a real risk that someone in the tethered network uses same IP
> address as the address self-assigned on the PGW.  That address has an


The PGW does not have an address on that subnet


> IID which appears to be random (it's not MAC-based, no ff:fe, no ::1, no
> ::cafe).  The USBnet has no IEEE-guaranteed unique MAC addresses.  So
> someone on the USBnet may make a random IID (for privacy or other
> USB-specific reasons) which collide with an IID generated by PGW.  The sa=
me
> prefix on the PGW interface is used in the tethered network on USB.
>
> When this collision happens the tethered device can not ping the Internet=
,
> which is a bad situation to be in.
>
> Alex
>
>
I believe you are chasing an implementation issues, not a standards issues.


CB

>
>> Gert Doering
>>          -- NetMaster
>>
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--047d7bf0d2e414f6e9052c233bb7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Feb 19, 2016 at 9:25 AM, Alexandre Petrescu &=
lt;alexan=
dre.petrescu@gmail.com> wrote:




Le 19/02/2016 10:49, Gert Doering a =C3=A9crit :



Hi,



On Fri, Feb 19, 2016 at 10:04:05AM +1100, Mark Smith wrote:



On 19 Feb 2016 8:47 AM, "Gert Doering" <gert@space.net> wrote:





Hi,



On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:



Actually, I think it does, and I also think ND is necessary on a

point-to-point link.





There is not much to discover on a true point-to-point link without

a multiaccess link layer below - think SDH/SONET, think PPP

encapsulation.





Whether or not the address implied by the prefix length actually exists is<=
br>
what needs to be discovered.



It is "neighbor discovery", not "neighbor link layer address=
 discovery on

the assumption that the address always exists for links that have link

layer addresses."





It is not relevant.=C2=A0 If I point a /64 into the p2p interface (without<=
br>
specifying a gateway address, because it's point-to-point: whatever I
stuff in on my side will come out at his side) I do not care whether it'=
;s

used on-link or somewhere behind the gateway.



This is a fundamental difference between "point towards a named next-h=
op

router on a multiaccess network" or "point into a point-to-point =
interface".



And in particular in the context of this discussion it is most relevant -
whatever address the network element on the other side of the PDP context
has is not relevant as it is "on the other side of a point to point li=
nk",

so "point your default route towards the ptp interface, done".


If devices choose to present this as an "ethernet-style" interfac=
e, it's

an implementer's choice - but argueing that because of this, 6share

isn't going to work is a not the correct conclusion.





I think it is the correct conclusion.



Because if the operator self-assigns an address out of the prefix advertise=
d to the UE then the UE must make sure noone in its tethered network uses t=
hat same address.=C2=A0 Such mechanism does not exist.



"operator self-assigns an address=
 out of the prefix advertised to the UE"

The =
operator does not assign any address from that prefix assigned to the UE.



There is a real risk that someone in the tethered network uses same IP addr=
ess as the address self-assigned on the PGW.=C2=A0 That address has an 

The PGW does not have an address on that subne=
t
=C2=A0
IID which appears to be random (it=
's not MAC-based, no ff:fe, no ::1, no ::cafe).=C2=A0 The USBnet has no=
 IEEE-guaranteed unique MAC addresses.=C2=A0 So someone on the USBnet may m=
ake a random IID (for privacy or other USB-specific reasons) which collide =
with an IID generated by PGW.=C2=A0 The same prefix on the PGW interface is=
 used in the tethered network on USB.



When this collision happens the tethered device can not ping the Internet, =
which is a bad situation to be in.



Alex



I believe you are chasing an im=
plementation issues, not a standards issues. =C2=A0

CB=C2=A0





Gert Doering

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- NetMaster







_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--047d7bf0d2e414f6e9052c233bb7--


From nobody Fri Feb 19 16:28:20 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9731B36EB for ; Fri, 19 Feb 2016 16:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmY8BkwpAsjO for ; Fri, 19 Feb 2016 16:28:17 -0800 (PST)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 4948A1B36DC for ; Fri, 19 Feb 2016 16:28:17 -0800 (PST)
Received: by mail-vk0-x236.google.com with SMTP id e6so88936659vkh.2 for ; Fri, 19 Feb 2016 16:28:17 -0800 (PST)
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 :content-type:content-transfer-encoding; bh=/doy11WPLGEdxaHHeJuCDvScpUwoXiiwaex8XSXU3Hs=; b=lX0cWT609L+OY9crQeTgAKUWZrqG5kk23UPgKjHtxZ9UuHNhY1wscb8NU9JnoW+YSV C3LFDgE2YQR/oGHHbK1cICDRmSAJt7bpOZku/Vg0CkddnwM17M37bmqR05Pvkuxec+nG LiOA03/Nubr3G/63XyH6vOJ0FZ5Q8uJS4pExBz2ZkfhTyEpnKFxw71z9x7gTpSGrY71V 4Dh2Fhz/Cux2VffdPia2VvkxpwPoedVD7ISjp114fAUel5+IvfIwav4HQyNx7UMr14uK h4LhXr/Rgk/WRERhtl57/lYUks/6pxmX07/erdLfjyVLwV+nGdth7zBWNNCQR+UKt9nL NGnQ==
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:content-type:content-transfer-encoding; bh=/doy11WPLGEdxaHHeJuCDvScpUwoXiiwaex8XSXU3Hs=; b=LllsB5cXz2ssTEcKGqMOOTCleSBLPBApI+SUJhjrmcn4C1iLJl6yaTf2LpEo1HiGGA pv8BnC7mYID/6d2PZmqFhKjy4ERnIuQLFBGmAbOwid0ivyEeh2WtjxgBjcNHWMR2Cs9j hJj1He9rQ5iFzeMGEO/Fp80senLfHq3zKr4doJfxzVDxt3l/HtWH5+so32BAp8RN/KnA Gim5W0Lz4CnMNVwPkSNpufUrkMypqDJnHQkP3O9p7nnij/AXCfWdTUr7mMBoiYfdKtWn x8V8PAHG+4uxzm/28UWCdLMbp8d1T8v5Hv6xXS+Ze0QYgvNIl+hypkbnmy21LCjaWnYo 0V/A==
X-Gm-Message-State: AG10YOQZyIsuAto3T+kMAzI6cM+hNinUX92kjEbIi7ls0Er8dIHlE7HCuvwvqgK376VpBNm+i/sXYOS/Mn/KvQ==
X-Received: by 10.31.54.75 with SMTP id d72mr13069793vka.30.1455928096386; Fri, 19 Feb 2016 16:28:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Fri, 19 Feb 2016 16:27:46 -0800 (PST)
In-Reply-To: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>   
From: Mark Smith 
Date: Sat, 20 Feb 2016 11:27:46 +1100
Message-ID: 
To: v6ops list 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [v6ops] Fwd: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 00:28:18 -0000

(Somehow it reply rather than reply all.)


---------- Forwarded message ----------
From: Mark Smith 
Date: 20 February 2016 at 10:34
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN
Link
To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 


On Feb 20, 2016 4:17 AM, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89"  wrote:
>
> On Thu, Feb 18, 2016 at 11:29 AM, Mark Smith  wro=
te:
>
> > Here's why it matters. The support for /127s on P2P links (RFC6164)
> > was advocated as fixing the ping-pong problem, but the trouble is that
> > it doesn't guarantee it does, because it is based on the untested
> > assumption that both ends of the link will be configured with the
> > addresses in the /127 e.g.,
> >
> > A-End:
> > address: 2001:db8::0
> > route: 2001:db8::0/127 via ptp-int
> >
> > B-End:
> > address: (not configured)
> > route: 2001:db8::0/127 via ptp-int
> > or
> > route: :: via ptp-int
> >
> > and you have a ping-pong problem with a /127 prefix on the link.
>
> Probably off-topic in the context of this thread, but I'd like to make
> a small correction: a ping-pong wouldn't happen in this case,
> regardless of whether the address(es) from the /127 are actually
> configured or not, or whether ND is performed in the link, as long as
> the routers support Section 3.1 of RFC4443 correctly:
>
>    One specific case in which a Destination Unreachable message is sent
>    with a code 3 is in response to a packet received by a router from a
>    point-to-point link, destined to an address within a subnet assigned
>    to that same link (other than one of the receiving router's own
>    addresses).

There is the requirement that isn't being met and that facilitates the
ping-ping pong. The receiving router does not know about the address
space on the link, as it doesn't have an address assigned to its
interface from within it, and therefore the only thing it can do is
ask the route table what to do with the packet it received, which
might mean forwarding back onto the link due to a default route.

All of these less than robust methods (i.e., /127s, or the above text)
are really just because some router vendors decided that ND wasn't
necessary on a point-to-point link, despite this text in the ND
RFC4861, which is saying that p2p links are no different to other link
types when it comes to ND:

"     point-to-point - Neighbor Discovery handles such links just like

                      multicast links.  (Multicast can be trivially

                      provided on point-to-point links, and interfaces

                      can be assigned link-local addresses.)"

Where this has crossed over into one the areas I've worked in is
providing residential IPv6 broadband over PPPoE. PPPoE is a p2p link,
so some router vendors may have decided not to implement ND on them
(or only implemented DAD, but not ND NSes for the purposes of
discovering the presence of addresses).

/127s aren't really practical because the users' CPE might not accept
the /127 mask in the RA PIO, and even if they did, for troubleshooting
purposes and to avoid imposing CPE costs for the customer, you want to
use a /64 for the PPPoE link so that they can plug a PC directly into
your service, having all 64 IID bits so that they can use e.g.,
privacy addresses.

This sort of issue needs to be watched for in the share64 scenario
too, as if the UE doesn't have a discard route for the /64 routed
towards the UE (rather than being on the link), then a ping-pong could
also happen too between the UE and the upstream gateway.

Regards,
Mark.



  In such a case, the packet MUST NOT be forwarded back
>    onto the arrival link.
>


> --
> JINMEI, Tatuya


From nobody Fri Feb 19 18:00:30 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D491B3837 for ; Fri, 19 Feb 2016 18:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ve3CNLCrvqu for ; Fri, 19 Feb 2016 18:00:27 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 0B62B1B3839 for ; Fri, 19 Feb 2016 18:00:26 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id xg9so46686507igb.1 for ; Fri, 19 Feb 2016 18:00:26 -0800 (PST)
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=yMS15plP6d8srn88f7wNTMpcBVPAoTv4iCff3+UWIiQ=; b=C1wxRBLlIq6Fehfdl8+e7wY3H35HKv3QbayQiabBuAiBS/PgaF1KjhfVQ3ShDLFWyS P7kNbGc41qb6hpPCdzjNseGBjHEAxAJl55s6745AV8ChS97fSgFkXMuQACVMUrLYALPe 13kkNOZVn+dJfT9rede/AtUOm5omv/DU5dZSiNNGdF30FfkKr0ORFoYGH5sGNceDLlng sqcHu3WaAB2n01fGuIaoLuqs7nyqmGTFCEXMCwqbpmGqWqWSovDiOvqGJ4F4/W5Z3JRa cehY5Y1D/V2gvp2JwNtDVH/I8Gx8pzFemHt1aTb7solWfiVCr5987T/AL8p83lopjmIZ cedQ==
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=yMS15plP6d8srn88f7wNTMpcBVPAoTv4iCff3+UWIiQ=; b=meNIZt7jq8fDgQ5vumTwUCK3iaxmW2QW6r0xSmHx6PUp2iAI3zk3UaA/rs/P66EA3E lYKRVc8YLIJ8dNLeeTLkObzaaeW10e1ai2kt8W0dsTa2Sd4z5CffpZdS4/Fv6hn+SxS5 Pi9LgHNi0s6abY6lHMNYKh3E1ZY/yQuCNoY7tqz60Rrgm6HJAiG8jcme14HxgSo2fuXx D6ik/S7HxJGZr54ahSt4g3yFAnvl1kiZk6e58x5ymA5c+Cbf4ZgAUQJ7I3Ld/BwZAbZM UUQwc8fh7mq1cy1nbNnGZctYkpomabrYqr3cxyerwBT/LxCWspswjsmHFnobmdaDeTP0 QUqg==
X-Gm-Message-State: AG10YOSkv3rf5RwMsH4dmkRncTf0BBpDeI+/bPT8EoHfxNSiyAFlOtkeSJCYWdRMfKydHF5ULu/BYS/Ulhhi9w==
MIME-Version: 1.0
X-Received: by 10.50.43.226 with SMTP id z2mr172409igl.78.1455933626461; Fri, 19 Feb 2016 18:00:26 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Fri, 19 Feb 2016 18:00:26 -0800 (PST)
In-Reply-To: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>    
Date: Fri, 19 Feb 2016 18:00:26 -0800
X-Google-Sender-Auth: kYGcLb6YrnQyAIMfwLV4I6IXjh4
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Mark Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Fwd: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 02:00:28 -0000

At Sat, 20 Feb 2016 11:27:46 +1100,
Mark Smith  wrote:

> > > B-End:
> > > address: (not configured)
> > > route: 2001:db8::0/127 via ptp-int
> > > or
> > > route: :: via ptp-int
> > >
> > > and you have a ping-pong problem with a /127 prefix on the link.
> >
> > Probably off-topic in the context of this thread, but I'd like to make
> > a small correction: a ping-pong wouldn't happen in this case,
> > regardless of whether the address(es) from the /127 are actually
> > configured or not, or whether ND is performed in the link, as long as
> > the routers support Section 3.1 of RFC4443 correctly:
> >
> >    One specific case in which a Destination Unreachable message is sent
> >    with a code 3 is in response to a packet received by a router from a
> >    point-to-point link, destined to an address within a subnet assigned
> >    to that same link (other than one of the receiving router's own
> >    addresses).
>
> There is the requirement that isn't being met and that facilitates the
> ping-ping pong. The receiving router does not know about the address
> space on the link, as it doesn't have an address assigned to its
> interface from within it, and therefore the only thing it can do is
> ask the route table what to do with the packet it received, which
> might mean forwarding back onto the link due to a default route.



Ah, okay, I see what you meant.  But I'd consider this case to be too
artificial:

  B-End:
  address: (not configured)
  route: 2001:db8::0/127 via ptp-int

and quite unlikely to happen in practice due to simple misoperation.

I see this can be a more likely scenario as an operational error,
though:

  B-End:
  address: (not configured)
  route: ::/0 via ptp-int

BTW, I just realized the FreeBSD implementation of it doesn't check
the condition of "destined to an address within a subnet assigned to
that same link" part:

    if (V_ip6_sendredirects && rt->rt_ifp == m->m_pkthdr.rcvif && !srcrt &&
        (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0) {
        if ((rt->rt_ifp->if_flags & IFF_POINTOPOINT) != 0) {
            /*
             * If the incoming interface is equal to the outgoing
             * one, and the link attached to the interface is
             * point-to-point, then it will be highly probable
             * that a routing loop occurs. Thus, we immediately
             * drop the packet and send an ICMPv6 error message.
             *
             * type/code is based on suggestion by Rich Draves.
             * not sure if it is the best pick.
             */
            icmp6_error(mcopy, ICMP6_DST_UNREACH,
                    ICMP6_DST_UNREACH_ADDR, 0);
            goto bad;
        }
        type = ND_REDIRECT;
    }
(see lines 427-445 of
https://github.com/freebsd/freebsd/blob/master/sys/netinet6/ip6_forward.c).

I would wonder how commercial routers (especially high-end ones for
which this protection would matter most) implement this part of the
spec.

...but I'm afraid we are now far from the original context, so I
should probably stop here or change the subject if this is deemed to
be really important.

--
JINMEI, Tatuya


From nobody Fri Feb 19 19:27:47 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E441A037A for ; Fri, 19 Feb 2016 19:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGVfR1rrb0DV for ; Fri, 19 Feb 2016 19:27:44 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 E9C941A026E for ; Fri, 19 Feb 2016 19:27:43 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id e185so90869864vkb.1 for ; Fri, 19 Feb 2016 19:27:43 -0800 (PST)
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:content-type; bh=LrNUe+KtwkCentsUXEHdUzy+AsbHlTGV0PLcbzvs26g=; b=J7xpTYubn4BdSVvFh7973fdBPSb1dkM0DneWusQFSUeWEnjy9bKQGD2zlfel6qjdZK HiJIb2iPdDZHgYi/g3REuTp2J0/M1V28HLEF8633ywou6aI6mJ95H5HDyc2CDEhy5DtN ny9WwKHnCorrAd1tAL3OAQMn2CC7PzEvVJ+4n6xNLlsL7F/ddAqgn9eZLvHQZTJUXjRo anV65Vbj2qjonVOrwBkW4NMMHjQ3zRyaHfbY4C2HjUF7YxFOylCXJAbgTxaqo/EULNPf REReWJyMFfV89JumGuJ+kCzytHtedzCot3/VzwEwDkemDuDvDNE4Cxmvnuz2TMSNhoqP OaLg==
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-type; bh=LrNUe+KtwkCentsUXEHdUzy+AsbHlTGV0PLcbzvs26g=; b=aUNrpdFJFb9vR3GZ52dBqWV/S685GjcCyWRrF0e2D/nfeCa0qt972KTbLje+sKi1SG ntC7F77vnbEOE8qYq3rIN+xZrZtPdxO4QsQoWh8ZIhR7jazlJ+sxfIBEsLpGBEYVbXtP X1NOJbhDprouazMAZ2HoyUGtwvFi9bv9T7pTPIgl0R6C/L6w3gGu5SG2O9lYCayybZfa CeuLQG5Rr/8QTiGoXY5ctWbKWskJFa+xWb43nqPoa475IQO3zy1E/hJeo8KSxSyycEIw 03N64oJYP0HyRU/ZyLtcQ8JqXDW9HxheMpBvnlvnuIEvug3CWOB/N3ULpjKqs8jma3jx ngfQ==
X-Gm-Message-State: AG10YOSWf0lDcSDyMz0Kn/Q0JmmRizbw2+40g2fLsUVM8HccWfyIOgIYEc/F01qk8pHuzLlEhzh1/slvLrqVTQ==
MIME-Version: 1.0
X-Received: by 10.31.194.10 with SMTP id s10mr14364023vkf.72.1455938862841; Fri, 19 Feb 2016 19:27:42 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Fri, 19 Feb 2016 19:27:42 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Fri, 19 Feb 2016 19:27:42 -0800 (PST)
In-Reply-To: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>     
Date: Sat, 20 Feb 2016 14:27:42 +1100
Message-ID: 
From: Mark Smith 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a114661dcbc041a052c2b2edc
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Fwd: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 03:27:46 -0000

--001a114661dcbc041a052c2b2edc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20 Feb 2016 13:00, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89"  wrote:
>
> At Sat, 20 Feb 2016 11:27:46 +1100,
> Mark Smith  wrote:
>
> > > > B-End:
> > > > address: (not configured)
> > > > route: 2001:db8::0/127 via ptp-int
> > > > or
> > > > route: :: via ptp-int
> > > >
> > > > and you have a ping-pong problem with a /127 prefix on the link.
> > >
> > > Probably off-topic in the context of this thread, but I'd like to mak=
e
> > > a small correction: a ping-pong wouldn't happen in this case,
> > > regardless of whether the address(es) from the /127 are actually
> > > configured or not, or whether ND is performed in the link, as long as
> > > the routers support Section 3.1 of RFC4443 correctly:
> > >
> > >    One specific case in which a Destination Unreachable message is
sent
> > >    with a code 3 is in response to a packet received by a router from
a
> > >    point-to-point link, destined to an address within a subnet
assigned
> > >    to that same link (other than one of the receiving router's own
> > >    addresses).
> >
> > There is the requirement that isn't being met and that facilitates the
> > ping-ping pong. The receiving router does not know about the address
> > space on the link, as it doesn't have an address assigned to its
> > interface from within it, and therefore the only thing it can do is
> > ask the route table what to do with the packet it received, which
> > might mean forwarding back onto the link due to a default route.
>
>
>
> Ah, okay, I see what you meant.  But I'd consider this case to be too
> artificial:
>
>   B-End:
>   address: (not configured)
>   route: 2001:db8::0/127 via ptp-int
>
> and quite unlikely to happen in practice due to simple misoperation.
>

Agree, it was more just to point out that a /127 route rather than a /127
address on the interface could also create this situation.

> I see this can be a more likely scenario as an operational error,
> though:
>
>   B-End:
>   address: (not configured)
>   route: ::/0 via ptp-int
>

Agree. I've found it common that if things "work", then sometimes people
aren't as rigorous about detail that doesn't seem to matter. For example,
Internet access would work with the above configuration for devices on the
B end, and that might mean people forget to configure the B end /127
address that would protect against the ping-pong attack. There is
technically nothing wrong with that configuration from an IPv6 protocol
perspective, so there won't be any error messages anywhere.

> BTW, I just realized the FreeBSD implementation of it doesn't check
> the condition of "destined to an address within a subnet assigned to
> that same link" part:
>
>     if (V_ip6_sendredirects && rt->rt_ifp =3D=3D m->m_pkthdr.rcvif && !sr=
crt
&&
>         (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) =3D=3D 0) {
>         if ((rt->rt_ifp->if_flags & IFF_POINTOPOINT) !=3D 0) {
>             /*
>              * If the incoming interface is equal to the outgoing
>              * one, and the link attached to the interface is
>              * point-to-point, then it will be highly probable
>              * that a routing loop occurs. Thus, we immediately
>              * drop the packet and send an ICMPv6 error message.
>              *
>              * type/code is based on suggestion by Rich Draves.
>              * not sure if it is the best pick.
>              */
>             icmp6_error(mcopy, ICMP6_DST_UNREACH,
>                     ICMP6_DST_UNREACH_ADDR, 0);
>             goto bad;
>         }
>         type =3D ND_REDIRECT;
>     }
> (see lines 427-445 of
> https://github.com/freebsd/freebsd/blob/master/sys/netinet6/ip6_forward.c
).
>
> I would wonder how commercial routers (especially high-end ones for
> which this protection would matter most) implement this part of the
> spec.
>
> ...but I'm afraid we are now far from the original context, so I
> should probably stop here or change the subject if this is deemed to
> be really important.
>
> --
> JINMEI, Tatuya

--001a114661dcbc041a052c2b2edc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 20 Feb 2016 13:00, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" <=
jinmei@wide.ad.jp> wrote:

>

> At Sat, 20 Feb 2016 11:27:46 +1100,

> Mark Smith <markzzzsmith@=
gmail.com> wrote:

>

> > > > B-End:

> > > > address: (not configured)

> > > > route: 2001:db8::0/127 via ptp-int

> > > > or

> > > > route: :: via ptp-int

> > > >

> > > > and you have a ping-pong problem with a /127 prefix on =
the link.

> > >

> > > Probably off-topic in the context of this thread, but I'=
d like to make

> > > a small correction: a ping-pong wouldn't happen in this =
case,

> > > regardless of whether the address(es) from the /127 are actu=
ally

> > > configured or not, or whether ND is performed in the link, a=
s long as

> > > the routers support Section 3.1 of RFC4443 correctly:

> > >

> > >=C2=A0 =C2=A0 One specific case in which a Destination Unreac=
hable message is sent

> > >=C2=A0 =C2=A0 with a code 3 is in response to a packet receiv=
ed by a router from a

> > >=C2=A0 =C2=A0 point-to-point link, destined to an address wit=
hin a subnet assigned

> > >=C2=A0 =C2=A0 to that same link (other than one of the receiv=
ing router's own

> > >=C2=A0 =C2=A0 addresses).

> >

> > There is the requirement that isn't being met and that facili=
tates the

> > ping-ping pong. The receiving router does not know about the addr=
ess

> > space on the link, as it doesn't have an address assigned to =
its

> > interface from within it, and therefore the only thing it can do =
is

> > ask the route table what to do with the packet it received, which=


> > might mean forwarding back onto the link due to a default route.<=
br>
>

>

>

> Ah, okay, I see what you meant.=C2=A0 But I'd consider this case t=
o be too

> artificial:

>

> =C2=A0 B-End:

> =C2=A0 address: (not configured)

> =C2=A0 route: 2001:db8::0/127 via ptp-int

>

> and quite unlikely to happen in practice due to simple misoperation.
>


Agree, it was more just to point out that a /127 route rathe=
r than a /127 address on the interface could also create this situation.

> I see this can be a more likely scenario as an operatio=
nal error,

> though:

>

> =C2=A0 B-End:

> =C2=A0 address: (not configured)

> =C2=A0 route: ::/0 via ptp-int

>


Agree. I've found it common that if things "work&qu=
ot;, then sometimes people aren't as rigorous about detail that doesn&#=
39;t seem to matter. For example, Internet access would work with the above=
 configuration for devices on the B end, and that might mean people forget =
to configure the B end /127 address that would protect against the ping-pon=
g attack. There is technically nothing wrong with that configuration from a=
n IPv6 protocol perspective, so there won't be any error messages anywh=
ere.


> BTW, I just realized the FreeBSD implementation of it d=
oesn't check

> the condition of "destined to an address within a subnet assigned=
 to

> that same link" part:

>

> =C2=A0 =C2=A0 if (V_ip6_sendredirects && rt->rt_ifp =3D=3D =
m->m_pkthdr.rcvif && !srcrt &&

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (rt->rt_flags & (RTF_DYNAMIC|RTF_MO=
DIFIED)) =3D=3D 0) {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((rt->rt_ifp->if_flags & IFF_=
POINTOPOINT) !=3D 0) {

> =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* If the incoming inte=
rface is equal to the outgoing

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* one, and the link at=
tached to the interface is

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* point-to-point, then=
 it will be highly probable

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* that a routing loop =
occurs. Thus, we immediately

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* drop the packet and =
send an ICMPv6 error message.

> =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* type/code is based o=
n suggestion by Rich Draves.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* not sure if it is th=
e best pick.

> =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 icmp6_error(mcopy, ICMP6_DST=
_UNREACH,

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
ICMP6_DST_UNREACH_ADDR, 0);

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto bad;

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 type =3D ND_REDIRECT;

> =C2=A0 =C2=A0 }

> (see lines 427-445 of

> https://github.com/freebsd/freebsd/blob/master/sys/netinet6=
/ip6_forward.c).

>

> I would wonder how commercial routers (especially high-end ones for
> which this protection would matter most) implement this part of the
> spec.

>

> ...but I'm afraid we are now far from the original context, so I
> should probably stop here or change the subject if this is deemed to
> be really important.

>

> --

> JINMEI, Tatuya




--001a114661dcbc041a052c2b2edc--


From nobody Fri Feb 19 23:21:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6361B38CD for ; Fri, 19 Feb 2016 23:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.957
X-Spam-Level: 
X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpnd290FT9q5 for ; Fri, 19 Feb 2016 23:21:12 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 B91EE1B38B4 for ; Fri, 19 Feb 2016 23:21:11 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 65041A2; Sat, 20 Feb 2016 08:21:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455952869; bh=iLTYTYieyVVe7cW5oc1SV0x5FUxEc6ji53bmVWGZm4I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qpCNYxPjGVx6atIG6Ds3Ob6n7iqGAEioUc2BI5mYLqbFF/vVCKBir0Xj5WKeJCvwZ 9Xz/5FAaAb+X/rUMRE3L17ruRUE/SayAGdnGC16RjWuO55UtzomR6zeUS9uTPoX9/k crOAGpPLewjfA/tlXoy9/SZcHhEcty61W1YjliUY=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 58AB4A1; Sat, 20 Feb 2016 08:21:09 +0100 (CET)
Date: Sat, 20 Feb 2016 08:21:09 +0100 (CET)
From: Mikael Abrahamsson 
To: Alexandre Petrescu 
In-Reply-To: <56C490DE.8000406@gmail.com>
Message-ID: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 07:21:14 -0000

On Wed, 17 Feb 2016, Alexandre Petrescu wrote:

> This is wrongly stated, because the UE does not own that prefix, so it 
> can't say "its IPv6 addresses".  That prefix is belonging to a link not 
> to the UE, because the operator also makes an address out of it.

Think of the GTP tunnel as a PPP link, with the entire /64 routed to it.

So yes, the UE owns the entire prefix.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sat Feb 20 02:20:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044041A88DE for ; Sat, 20 Feb 2016 02:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KSAOin8vire for ; Sat, 20 Feb 2016 02:20:33 -0800 (PST)
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 096731A88DB for ; Sat, 20 Feb 2016 02:20:32 -0800 (PST)
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 u1KAKU2I009801; Sat, 20 Feb 2016 11:20:30 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BC4D52029D8; Sat, 20 Feb 2016 11:20:32 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7045200E63; Sat, 20 Feb 2016 11:20:32 +0100 (CET)
Received: from [132.166.84.25] ([132.166.84.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1KAKTGP021443; Sat, 20 Feb 2016 11:20:29 +0100
To: Mikael Abrahamsson 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C83DED.7090501@gmail.com>
Date: Sat, 20 Feb 2016 11:20:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 10:20:35 -0000

Le 20/02/2016 08:21, Mikael Abrahamsson a écrit :
> On Wed, 17 Feb 2016, Alexandre Petrescu wrote:
>
>> This is wrongly stated, because the UE does not own that prefix, so it
>> can't say "its IPv6 addresses".  That prefix is belonging to a link
>> not to the UE, because the operator also makes an address out of it.
>
> Think of the GTP tunnel as a PPP link, with the entire /64 routed to it.
>
> So yes, the UE owns the entire prefix.

As you say, that /64 is routed to the link, or to the GTP tunnel.

An entire /64 routed to that PPP link does not stop either ends to form 
an address out of that /64.

For example, with /127 ptp links each of the two ends always forms and 
IP address out of that /127.  So that /127 is not owned entirely by the UE.

If one wants an entire /64 routed to one UE (not to a link) it would 
have to be a route with a next-hop equal an address,
not a "* dev gtp0".  In that case, yes, and only in that case, we could 
safely assume that that entire /64 is owned by the UE.

Alex

>


From nobody Sat Feb 20 02:52:25 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51521A8740 for ; Sat, 20 Feb 2016 02:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Level: 
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbsLcfs-k4dK for ; Sat, 20 Feb 2016 02:52:21 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 66A991A8729 for ; Sat, 20 Feb 2016 02:52:21 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 19B81A2; Sat, 20 Feb 2016 11:52:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1455965538; bh=+ks5wnhG/89IKYcUnds0CqCZ7HF4JLn60LhLcctpyXk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vqH7c4+oPFnhQolYmMMK7kvvGR5lMhALFY7ZYET+XfmniFXynucTwK+lvlaGbwAGi EropihnCTxzxuQSRjO/1iwCUQcud1pD5Sw7kEKaEsW4dB/rj89Ymys3Vfm9qjHIzzo RqFv4FX0l+23gEEdYu/7jJqamFuh0qBSIhkWkyRM=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0F85CA1; Sat, 20 Feb 2016 11:52:18 +0100 (CET)
Date: Sat, 20 Feb 2016 11:52:18 +0100 (CET)
From: Mikael Abrahamsson 
To: Alexandre Petrescu 
In-Reply-To: <56C83DED.7090501@gmail.com>
Message-ID: 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C83DED.7090501@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 10:52:23 -0000

On Sat, 20 Feb 2016, Alexandre Petrescu wrote:

> If one wants an entire /64 routed to one UE (not to a link) it would 
> have to be a route with a next-hop equal an address, not a "* dev gtp0". 
> In that case, yes, and only in that case, we could safely assume that 
> that entire /64 is owned by the UE.

Generally the GGSN/SPGW doesn't use any address within that /64 (not in 
the ones I have seen anyway). With IPv6 and its use of LL, there is no 
need for the SPGW to have an address within the /64. There might be a need 
for your mobile baseband device to emulate that the GGSN/SPGW would have 
an address for your host IP stack to do the right thing, but this is 
actually not how it works on the GTP layer in my experience (and I have 
actually done a non-trivial amount of GTP tracing in my days).

So you should read the 3GPP documents that controls this and point out in 
that text where it says that the SPGW/GGSN should use an address within 
the UE /64, or show GTP traces that this is the case, before saying that 
this is the way it works.

We are multiple people in here that have worked both at mobile operators 
deploying IPv6, and people with history with vendors supplying mobile data 
equipment, that have voiced our experience/views that the point you're 
raising is not based in facts. Perhaps you should give us the benefit of 
the doubt that we might be correct?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sat Feb 20 10:02:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1D1A7D81 for ; Sat, 20 Feb 2016 10:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7kzqS2YcI8S for ; Sat, 20 Feb 2016 10:02:15 -0800 (PST)
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 0EECE1A1A15 for ; Sat, 20 Feb 2016 10:02:14 -0800 (PST)
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 u1KI2Co3012993; Sat, 20 Feb 2016 19:02:12 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D8A3200C39; Sat, 20 Feb 2016 19:02:15 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0B74E202BC1; Sat, 20 Feb 2016 19:02:15 +0100 (CET)
Received: from [132.166.84.53] ([132.166.84.53]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1KI2Bg2027941; Sat, 20 Feb 2016 19:02:11 +0100
To: Mikael Abrahamsson 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C83DED.7090501@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C8AA22.8000206@gmail.com>
Date: Sat, 20 Feb 2016 19:02:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 18:02:17 -0000

Le 20/02/2016 11:52, Mikael Abrahamsson a écrit :
> On Sat, 20 Feb 2016, Alexandre Petrescu wrote:
>
>> If one wants an entire /64 routed to one UE (not to a link) it would
>> have to be a route with a next-hop equal an address, not a "* dev
>> gtp0". In that case, yes, and only in that case, we could safely
>> assume that that entire /64 is owned by the UE.
>
> Generally the GGSN/SPGW doesn't use any address within that /64 (not in
> the ones I have seen anyway). With IPv6 and its use of LL, there is no
> need for the SPGW to have an address within the /64. There might be a
> need for your mobile baseband device to emulate that the GGSN/SPGW would
> have an address for your host IP stack to do the right thing, but this
> is actually not how it works on the GTP layer in my experience (and I
> have actually done a non-trivial amount of GTP tracing in my days).
>
> So you should read the 3GPP documents that controls this and point out
> in that text where it says that the SPGW/GGSN should use an address
> within the UE /64, or show GTP traces that this is the case, before
> saying that this is the way it works.

I can agree.  I can say now there is a defroute GUA in the UE, and 
without dongle.  I can not say where it comes from.  I _suppose_ from 
the network.  May be from the netmgrd/cm behaviour but that is as hard 
to find as asking the operator to give a GGSN packet dump.

One thing I dont understand is why the network behaviour is so important 
in an RFC which actually is independent of the network: the 64share 
method is a 100% UE implementation.

> We are multiple people in here that have worked both at mobile operators
> deploying IPv6, and people with history with vendors supplying mobile
> data equipment, that have voiced our experience/views that the point
> you're raising is not based in facts. Perhaps you should give us the
> benefit of the doubt that we might be correct?

Certainly.

Alex

>


From nobody Sat Feb 20 10:04:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514361ACDD3 for ; Sat, 20 Feb 2016 10:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.383
X-Spam-Level: 
X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_22=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpwaT6CE2epK for ; Sat, 20 Feb 2016 10:04:29 -0800 (PST)
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 EEC501ACDA7 for ; Sat, 20 Feb 2016 10:04:28 -0800 (PST)
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 u1KI4QCG005134; Sat, 20 Feb 2016 19:04:26 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5425320358D; Sat, 20 Feb 2016 19:04:29 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 444D6202BC1; Sat, 20 Feb 2016 19:04:29 +0100 (CET)
Received: from [132.166.84.53] ([132.166.84.53]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1KI4PLt028674; Sat, 20 Feb 2016 19:04:25 +0100
To: Ca By 
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <20160218190319.GO21153@Space.Net>  <20160218214717.GQ21153@Space.Net>  <20160219094933.GU21153@Space.Net> <56C75004.30205@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <56C8AAA8.4010504@gmail.com>
Date: Sat, 20 Feb 2016 19:04:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Feb 2016 18:04:31 -0000

Le 19/02/2016 18:58, Ca By a ĂŠcrit :
>
>
> On Fri, Feb 19, 2016 at 9:25 AM, Alexandre Petrescu
> > wrote:
>
>
>
>     Le 19/02/2016 10:49, Gert Doering a ĂŠcrit :
>
>         Hi,
>
>         On Fri, Feb 19, 2016 at 10:04:05AM +1100, Mark Smith wrote:
>
>             On 19 Feb 2016 8:47 AM, "Gert Doering"              > wrote:
>
>
>                 Hi,
>
>                 On Fri, Feb 19, 2016 at 06:29:34AM +1100, Mark Smith wrote:
>
>                     Actually, I think it does, and I also think ND is
>                     necessary on a
>                     point-to-point link.
>
>
>                 There is not much to discover on a true point-to-point
>                 link without
>                 a multiaccess link layer below - think SDH/SONET, think PPP
>                 encapsulation.
>
>
>             Whether or not the address implied by the prefix length
>             actually exists is
>             what needs to be discovered.
>
>             It is "neighbor discovery", not "neighbor link layer address
>             discovery on
>             the assumption that the address always exists for links that
>             have link
>             layer addresses."
>
>
>         It is not relevant.  If I point a /64 into the p2p interface
>         (without
>         specifying a gateway address, because it's point-to-point:
>         whatever I
>         stuff in on my side will come out at his side) I do not care
>         whether it's
>         used on-link or somewhere behind the gateway.
>
>         This is a fundamental difference between "point towards a named
>         next-hop
>         router on a multiaccess network" or "point into a point-to-point
>         interface".
>
>         And in particular in the context of this discussion it is most
>         relevant -
>         whatever address the network element on the other side of the
>         PDP context
>         has is not relevant as it is "on the other side of a point to
>         point link",
>         so "point your default route towards the ptp interface, done".
>
>         If devices choose to present this as an "ethernet-style"
>         interface, it's
>         an implementer's choice - but argueing that because of this, 6share
>         isn't going to work is a not the correct conclusion.
>
>
>     I think it is the correct conclusion.
>
>     Because if the operator self-assigns an address out of the prefix
>     advertised to the UE then the UE must make sure noone in its
>     tethered network uses that same address.  Such mechanism does not exist.
>
>
> "operator self-assigns an address out of the prefix advertised to the UE"
>
> The operator does not assign any address from that prefix assigned to
> the UE.
>
>
>     There is a real risk that someone in the tethered network uses same
>     IP address as the address self-assigned on the PGW.  That address
>     has an
>
>
> The PGW does not have an address on that subnet
>
>     IID which appears to be random (it's not MAC-based, no ff:fe, no
>     ::1, no ::cafe).  The USBnet has no IEEE-guaranteed unique MAC
>     addresses.  So someone on the USBnet may make a random IID (for
>     privacy or other USB-specific reasons) which collide with an IID
>     generated by PGW.  The same prefix on the PGW interface is used in
>     the tethered network on USB.
>
>     When this collision happens the tethered device can not ping the
>     Internet, which is a bad situation to be in.
>
>     Alex
>
>
> I believe you are chasing an implementation issues, not a standards issues

I can agree.  This is trying to understand netmgrd/cm software on the UE 
to see where that GUA in the defroute can come from.

But I believe this is very relevant for this RFC which is a UE RFC, not 
a network RFC.

Alex

>
> CB
>
>
>         Gert Doering
>                   -- NetMaster
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org 
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>


From nobody Sat Feb 20 16:49:53 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2030B1B2CD7 for ; Sat, 20 Feb 2016 16:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGCY5xOxnTBn for ; Sat, 20 Feb 2016 16:49:50 -0800 (PST)
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 22EA21B2CD6 for ; Sat, 20 Feb 2016 16:49:50 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id e6so103531273vkh.2 for ; Sat, 20 Feb 2016 16:49:50 -0800 (PST)
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:content-type; bh=8roXtJDDWGKgr1n4EB3vDB7Ukc5lI3kAVLHkqp12Tkc=; b=WF9V4GEY+PGRwoA6SZn4q+kAYNKeyBNkqvqjRMK92I9hJh5w11cfIT0EOIWdiQpNv1 L+CJvoowpUU1GuI8TCpSHs+OY/d7rj2ZEsj578gSiyRKnWbsnHFDa3M13Eq2A42OpCFQ ebgOZH5fNBgwHmQPMEdfLZyeslj/s8Dyssftvt9rk+BJCy3rJdUIAJOc9RpLaEOS2nEY nkQr6qFdU3iIYtH3eucdOQPPpaFIpv7GGKW5rTtmV/4WY1EYAwSHANrWTK1bV4Lk3bf3 NMgTqeNFT7J3s05ZHFPhxxWNcUWodccvfDv0kSsu1oqbA95ArBYTPiDDjGyHIZZaznZM Axrg==
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-type; bh=8roXtJDDWGKgr1n4EB3vDB7Ukc5lI3kAVLHkqp12Tkc=; b=lJ5Rw+8yz2bh5DudjgZSk5ujbozyLDT54Px2aNIZ27KoA+Rag6pT/HXRL1jSdYUC0X ooboRUjRF4XkLr7/cy3qeUAFla73l0+A+WxPI0+4zxGZd+64NSJnfAc8AJxxQXU3tU3l 7GCiJTUzs23jyQeIVP41kSgNzGOn2I/sZFzmXh4vXpKXOh4k4RvP/hj51df/sFsrtZZs AljvrT7ttlWXFL53yZbe8F1BwlwOtnf27u55f4Ccc4M+qvoo7jxFO5pNE0ts9AdxBajW Ie+bGKJsgc/minnKJAYBOvJqojbZKcGhP5uKG6l4vwPq6oWYEVnXUkFQbnqevKz5itMY 7BsQ==
X-Gm-Message-State: AG10YOS3GA3QAZnyhp+Ux8vz0a3N9BsY3yhgFE/i5PV5EK6T+fSzyJOPhnf5aHJC6SlEzX4+w8KT1YdD9rMNog==
MIME-Version: 1.0
X-Received: by 10.31.128.82 with SMTP id b79mr17189154vkd.47.1456015789097; Sat, 20 Feb 2016 16:49:49 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Sat, 20 Feb 2016 16:49:48 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Sat, 20 Feb 2016 16:49:48 -0800 (PST)
In-Reply-To: <56C83DED.7090501@gmail.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C83DED.7090501@gmail.com>
Date: Sun, 21 Feb 2016 11:49:48 +1100
Message-ID: 
From: Mark Smith 
To: Alexandre Petrescu 
Content-Type: multipart/alternative; boundary=001a11429ce4e588af052c3d17a9
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 00:49:52 -0000

--001a11429ce4e588af052c3d17a9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20 Feb 2016 21:20, "Alexandre Petrescu" 
wrote:
>
>
>
> Le 20/02/2016 08:21, Mikael Abrahamsson a =C3=A9crit :
>>
>> On Wed, 17 Feb 2016, Alexandre Petrescu wrote:
>>
>>> This is wrongly stated, because the UE does not own that prefix, so it
>>> can't say "its IPv6 addresses".  That prefix is belonging to a link
>>> not to the UE, because the operator also makes an address out of it.
>>
>>
>> Think of the GTP tunnel as a PPP link, with the entire /64 routed to it.
>>
>> So yes, the UE owns the entire prefix.
>
>
> As you say, that /64 is routed to the link, or to the GTP tunnel.
>
> An entire /64 routed to that PPP link does not stop either ends to form
an address out of that /64.
>
> For example, with /127 ptp links each of the two ends always forms and IP
address out of that /127.  So that /127 is not owned entirely by the UE.
>
> If one wants an entire /64 routed to one UE (not to a link) it would have
to be a route with a next-hop equal an address,
> not a "* dev gtp0".  In that case, yes, and only in that case, we could
safely assume that that entire /64 is owned by the UE.
>

This is an example of where treating p2p links as different creates model
of operation problems.

The trouble is,

2001:db8::/64 via p2p-link

is ambiguous.

It could be saying that the address space is assigned to the p2p-link
itself, or it could be saying the address space is behind or assigned to
the device at the other end of the link.

My interpretation, based on past Cisco router experience, is that this is a
"connected" route, and therefore the address space is assigned to the link.
ARP/ND should be triggered to addresses in that space, because the last hop
for that space has been reached.

Other people who don't have my "connected" route experience would probably
interpret it as the latter, which is also logical - if you want to state
that address space is on a link, you give the device an address in the
link, so a route pointing out a p2p link is a statement that the last hop
hasn't been reached yet.

The scenario you're describing is combining both interpretations at the
same time, which creates more issues because it isn't a clear statement of
whether the address space is on the link or behind/within the device at the
end of it - it's "both".

> Alex
>
>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a11429ce4e588af052c3d17a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 20 Feb 2016 21:20, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:
>

>

>

> Le 20/02/2016 08:21, Mikael Abrahamsson a =C3=A9crit :

>>

>> On Wed, 17 Feb 2016, Alexandre Petrescu wrote:

>>

>>> This is wrongly stated, because the UE does not own that prefi=
x, so it

>>> can't say "its IPv6 addresses".=C2=A0 That prefi=
x is belonging to a link

>>> not to the UE, because the operator also makes an address out =
of it.

>>

>>

>> Think of the GTP tunnel as a PPP link, with the entire /64 routed =
to it.

>>

>> So yes, the UE owns the entire prefix.

>

>

> As you say, that /64 is routed to the link, or to the GTP tunnel.

>

> An entire /64 routed to that PPP link does not stop either ends to for=
m an address out of that /64.

>

> For example, with /127 ptp links each of the two ends always forms and=
 IP address out of that /127.=C2=A0 So that /127 is not owned entirely by t=
he UE.

>

> If one wants an entire /64 routed to one UE (not to a link) it would h=
ave to be a route with a next-hop equal an address,

> not a "* dev gtp0".=C2=A0 In that case, yes, and only in tha=
t case, we could safely assume that that entire /64 is owned by the UE.

>


This is an example of where treating p2p links as different =
creates model of operation problems.


The trouble is,


2001:db8::/64 via p2p-link


is ambiguous.


It could be saying that the address space is assigned to the=
 p2p-link itself, or it could be saying the address space is behind or assi=
gned to the device at the other end of the link.


My interpretation, based on past Cisco router experience, is=
 that this is a "connected" route, and therefore the address spac=
e is assigned to the link. ARP/ND should be triggered to addresses in that =
space, because the last hop for that space has been reached.


Other people who don't have my "connected" rou=
te experience would probably interpret it as the latter, which is also logi=
cal - if you want to state that address space is on a link, you give the de=
vice an address in the link, so a route pointing out a p2p link is a statem=
ent that the last hop hasn't been reached yet.


The scenario you're describing is combining both interpr=
etations at the same time, which creates more issues because it isn't a=
 clear statement of whether the address space is on the link or behind/with=
in the device at the end of it - it's "both".


> Alex

>

>

>>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--001a11429ce4e588af052c3d17a9--


From nobody Sun Feb 21 02:34:30 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020CD1A6F0B for ; Sun, 21 Feb 2016 02:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKvH9r0Jm33h for ; Sun, 21 Feb 2016 02:34:26 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 817CB1A6F02 for ; Sun, 21 Feb 2016 02:34:25 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 01E1662ADB for ; Sun, 21 Feb 2016 11:34:23 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BDB3B6029C for ; Sun, 21 Feb 2016 11:34:22 +0100 (CET)
Received: (qmail 42704 invoked by uid 1007); 21 Feb 2016 11:34:22 +0100
Date: Sun, 21 Feb 2016 11:34:22 +0100
From: Gert Doering 
To: Mark Smith 
Message-ID: <20160221103422.GB21153@Space.Net>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C83DED.7090501@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 10:34:29 -0000

Hi,

On Sun, Feb 21, 2016 at 11:49:48AM +1100, Mark Smith wrote:
> The trouble is,
> 
> 2001:db8::/64 via p2p-link
> 
> is ambiguous.
> 
> It could be saying that the address space is assigned to the p2p-link
> itself, or it could be saying the address space is behind or assigned to
> the device at the other end of the link.

A "link" does not have an address.  So it's either "the device on the
other end" or "something behind the device on the other end", which 
does not make a difference to the device on *this* side of the link.

"Stuff the packet into the tube, done".

> My interpretation, based on past Cisco router experience, is that this is a
> "connected" route, and therefore the address space is assigned to the link.
> ARP/ND should be triggered to addresses in that space, because the last hop
> for that space has been reached.

Well, since you are referring to Cisco, your memory is not correct - a
"connected" route in Cisco lingo is a route that is configured on the
interface

  interface pos3/7
    ipv6 address 2001:db8::1/64

while a route pointing *to* an interface is just "static"

  ipv6 route 2001:db8:2::/64 pos3/7


whether or not either of them(!) triggers ARP/ND depends on whether this
is a multiaccess network or not - on POS (SDH/SONET), PPP, X.25, ATM PVC,
point-to-point links, there is no link-layer to be resolved, and thus,
neither ARP nor ND is done.

> Other people who don't have my "connected" route experience would probably
> interpret it as the latter, which is also logical - if you want to state
> that address space is on a link, you give the device an address in the
> link, so a route pointing out a p2p link is a statement that the last hop
> hasn't been reached yet.

And this is exactly how *Cisco* devices are *doing* it, unless you 
consider an ethernet segment with a route being pointed to it 
("ipv6 route ... ethernet3") where you have to do ARP/ND due to the 
multiaccess nature of ethernet, even if it would be possible to run 
as point-to-point by telling both sides' ethernet layers ("send everything 
to ff:ff:ff:ff:ff:ff" and "receive everything that comes in") - but I 
do not know any product that actually works that way.

I'm explicitely not talking "ethernet being used as point-to-point link"
because just because there are only two stations on it, it's not magically
turning into a point-to-point media.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Sun Feb 21 11:00:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CB81A8894 for ; Sun, 21 Feb 2016 11:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.608
X-Spam-Level: 
X-Spam-Status: No, score=-112.608 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_oFxLTost_4 for ; Sun, 21 Feb 2016 11:00:10 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D3E1A888D for ; Sun, 21 Feb 2016 11:00:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=498; q=dns/txt; s=iport; t=1456081209; x=1457290809; h=date:from:message-id:to:subject; bh=KkfnhsbTkAo8k8Crg2PHfGnUe6nDK5bQ3Des1zPydpw=; b=glzYbQtUNpiWgU5AWXL+vwsPRMcwbxWntNvkfzzJnYN8KBhXY/toLkCQ /Eu+0SqVQu2EKBibx9PIbwtzhEWHR6mqWsDMBeisWB5Jp66/aAjIbzfs6 IkxAzeMEc+FEfYtjpLSMhK4B7nnLJykErS0jMsIT8jt87EafVS0ml9ru4 E=;
X-IronPort-AV: E=Sophos;i="5.22,481,1449532800"; d="scan'208";a="75494011"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2016 19:00:09 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1LJ08PK006085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Feb 2016 19:00:09 GMT
Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u1LJ08fk018882; Sun, 21 Feb 2016 11:00:08 -0800
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u1LJ08lj018846; Sun, 21 Feb 2016 11:00:08 -0800
Date: Sun, 21 Feb 2016 11:00:08 -0800
From: fred@cisco.com
Message-Id: <201602211900.u1LJ08lj018846@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] Call to action: post your drafts!
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 19:00:11 -0000

The Internet Draft repository will close for IETF 95 on March 21.  As I
find myself reminding people each meeting, the guideline the working
group has given the chairs is that they want Internet Drafts posted,
and vetted on the list - no supporting commentary, no face time. So,
if you have a mind to write a draft for discussion in six weeks, the
time to write and post the draft is now - and then forward your posting
notification to the list explaining the issue and inviting discussion.


From nobody Sun Feb 21 11:00:16 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDD91A888D for ; Sun, 21 Feb 2016 11:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -113.107
X-Spam-Level: 
X-Spam-Status: No, score=-113.107 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yptJp0brqGAY for ; Sun, 21 Feb 2016 11:00:10 -0800 (PST)
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 10DE91A887D for ; Sun, 21 Feb 2016 11:00:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=634; q=dns/txt; s=iport; t=1456081209; x=1457290809; h=date:from:message-id:to:subject:cc; bh=7JS95kDRJ8jKyrLfgzh+vHnzUE01AzIzxu0uYXvF0N0=; b=ds0kXD3SzRUFkSe6i66TJdagcJmQ2dwkxeqsXgLPh9hbuj+s5pRBydt8 cy66Z9pgf+43jAblTbY7R2orU5N/sUlVYqjsxgLnMba+beKxNUsyZhphx MP53HFZe0Vp2gKPOFOphnHxfz4A0OuMahH0RfSO6z25zKSo8dcnXnQaOK w=;
X-IronPort-AV: E=Sophos;i="5.22,481,1449532800"; d="scan'208";a="240832577"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2016 19:00:09 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1LJ08YZ032261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Feb 2016 19:00:09 GMT
Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u1LJ08wc018888; Sun, 21 Feb 2016 11:00:08 -0800
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u1LJ08MV018843; Sun, 21 Feb 2016 11:00:08 -0800
Date: Sun, 21 Feb 2016 11:00:08 -0800
From: fred@cisco.com
Message-Id: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 19:00:12 -0000

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.


From nobody Sun Feb 21 12:27:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FC51A88D6 for ; Sun, 21 Feb 2016 12:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9psQAz7pXiy for ; Sun, 21 Feb 2016 12:27:30 -0800 (PST)
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 9415F1A88BC for ; Sun, 21 Feb 2016 12:27:30 -0800 (PST)
Received: by mail-vk0-x22d.google.com with SMTP id e185so113652660vkb.1 for ; Sun, 21 Feb 2016 12:27:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:cc:content-type;  bh=v2sbSUttqMFrXJgt5L56RiyoiwqJKBWNBKUEFGdDaf0=; b=XFzSLAqICSxy1n6rDmoAWUFVJruI2pW4BetDggl+Vmdlmf2Rx5+i152RInP7dGBavi CvermSVvbPqrVrBR3WVBYXTgRwZ2er6Qorox6oq5lBweSAR1DqKPxURC8/Ll9qTE0iG9 eeGg4aOKfUUyHaV4Rlo07WcJjq/rG5IWwnXPCxowuo0ajX64+FW+r5DXcQtTDdMpJnIi s2t78610/fuIp5wb7I9HMFe2XfFu2cp/KOaFFSo73yEROjEx2LEFcXHuNOqYl7z6Qfnp QT6DyxtFji6VqRYIBZDrlKe449WJ7P+iiZFf8J8tblgjzEhsGf1/aQrBzEnUNwIqb2rr 6r/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=v2sbSUttqMFrXJgt5L56RiyoiwqJKBWNBKUEFGdDaf0=; b=WcFbEwOB6Nc8BByG7g0KVRdRKQfabrZEEVymNCADTIOv//FiFD1RY2wCapKfcpulwa 4D90goBNFAnyirrfm8Amdk/MVhn012018QJwg05ZdDHnkNI5JeCBu/UwZXTEy3LaNBEI VWG64zTupenOi/CmTD/njgV6jglbJoLxpVM2u6DpmSH31+JE7sU/K43x3tI1avooum9y aBN4i8Qt2mYrj+eYe2/uEDWnShedCecE5yBAK4SiJNSbRlQphQBT6AWV1tdWZcardOPT 8yRzzooYdanVFp7IDNkK4fL8SjXy8EcM1vIvQWyCeK97F4/PGNwvuUtbuI+a7Hyzz6d9 OEyQ==
X-Gm-Message-State: AG10YOSwndrGCD0oy5mXPQpZGD8eiMQWRrfAM5umbJt1p+g66ZspgjE5N/iwl3UWhw8+XjSoymKv2hnmDZOZHQ==
X-Received: by 10.31.194.10 with SMTP id s10mr20689140vkf.72.1456086449696; Sun, 21 Feb 2016 12:27:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Sun, 21 Feb 2016 12:27:00 -0800 (PST)
From: Mark Smith 
Date: Mon, 22 Feb 2016 07:27:00 +1100
Message-ID: 
To: Gert Doering 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 20:27:31 -0000

On 21 February 2016 at 21:34, Gert Doering  wrote:
> Hi,
>
> On Sun, Feb 21, 2016 at 11:49:48AM +1100, Mark Smith wrote:
>> The trouble is,
>>
>> 2001:db8::/64 via p2p-link
>>
>> is ambiguous.
>>
>> It could be saying that the address space is assigned to the p2p-link
>> itself, or it could be saying the address space is behind or assigned to
>> the device at the other end of the link.
>
> A "link" does not have an address.  So it's either "the device on the
> other end" or "something behind the device on the other end", which
> does not make a difference to the device on *this* side of the link.
>
> "Stuff the packet into the tube, done".
>

So, with this "Stuff the packet into the tube, done" approach on a p2p
link, what happens if the packet's destination address isn't present
on the device or behind the device at the other end?



Regards,
Mark.


From nobody Sun Feb 21 12:36:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DB61A1A33 for ; Sun, 21 Feb 2016 12:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnM1MH47hLOP for ; Sun, 21 Feb 2016 12:36:15 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 DB0EA1A0113 for ; Sun, 21 Feb 2016 12:36:14 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id c200so144315610wme.0 for ; Sun, 21 Feb 2016 12:36:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4S30vNJQV8Wvak7w9RvHc+izi219mE6Y2xhYsiJbt3w=; b=emeqcIVAs0k6Ttj2ISgy/1n7jGE5HptDDkGIpbJcH8IyEtwZtMChZbcAkU1aPDf/UF 5E16qLbQl3NnQSvQpq2ugQmzwVsGk2eqRpllDRFChCvwhQvky7d1yV+WfjTrsMVAJCsH 3pxGPtUHgrKo5PsWwBaBcNK25VLDsCDTYbNs270yfIWtixI3c+Dya+6cwzTBodug1Jtp iYa47/h/n9aLcTIEFE9n7VI6XOrnTZdopLzvQ6tdw/B4RIVTK1XDfGPrfWB6xCrKAHQE Do8LTX8iqQ1eaYCR7Z12TkqTKPntAeSIZEm46CWYvbZVdOJCVhD5LoiAcMsoG5Qa58/A ndqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4S30vNJQV8Wvak7w9RvHc+izi219mE6Y2xhYsiJbt3w=; b=mJvk0Eppg0o38bsYOCtayOHll1wk0RPBGbolbyYJcvthzDFQtp0WtYH4VgS8HoPchZ EOUM62UO3fawHnJWyc23Xr1/70ySuASfsTO8EM/6AFLSvpw9Q+bHH659G1Be9ANF0EZe eZHTGLW8l0qSLevMk9ysEL4uDKs52NWW8ssaPUXZ8JLsazWOmEe0cilko7zufz3KyIB6 RqQEx/Cgl7ahPjrguZYIGAPA6FZR68iOEyfCJdC06YttUbqHg4OpGayYYX+uzwYEydZH D7/IRvcjKDOjYAbwf7fjjYX0SIm305CuUz9fGsAjattIsPzMqqDlifPQB/QgSqwEDWkP LTnQ==
X-Gm-Message-State: AG10YOTm2qgyv1qXUj2G9dg6DjfgfQysqh72tb0NUx8yEG1yEXg6ofc0A4WCVSDF3ekIVg==
X-Received: by 10.194.22.35 with SMTP id a3mr1120238wjf.165.1456086973437; Sun, 21 Feb 2016 12:36:13 -0800 (PST)
Received: from [10.217.233.209] (BSN-142-170-80.static.siol.net. [89.142.170.80]) by smtp.gmail.com with ESMTPSA id c26sm17910373wmi.24.2016.02.21.12.36.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 12:36:11 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Ivan Pepelnjak 
X-Mailer: iPad Mail (13D15)
In-Reply-To: 
Date: Sun, 21 Feb 2016 21:36:10 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: Mark Smith 
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 20:36:16 -0000

Forwarding loop. TTL expires. Welcome to the 80s.

Sent from my iPad

> On 21 Feb 2016, at 21:27, Mark Smith  wrote:
> 
>> On 21 February 2016 at 21:34, Gert Doering  wrote:
>> Hi,
>> 
>>> On Sun, Feb 21, 2016 at 11:49:48AM +1100, Mark Smith wrote:
>>> The trouble is,
>>> 
>>> 2001:db8::/64 via p2p-link
>>> 
>>> is ambiguous.
>>> 
>>> It could be saying that the address space is assigned to the p2p-link
>>> itself, or it could be saying the address space is behind or assigned to
>>> the device at the other end of the link.
>> 
>> A "link" does not have an address.  So it's either "the device on the
>> other end" or "something behind the device on the other end", which
>> does not make a difference to the device on *this* side of the link.
>> 
>> "Stuff the packet into the tube, done".
>> 
> 
> So, with this "Stuff the packet into the tube, done" approach on a p2p
> link, what happens if the packet's destination address isn't present
> on the device or behind the device at the other end?
> 
> 
> 
> Regards,
> Mark.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Sun Feb 21 13:13:07 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33A61ACE20 for ; Sun, 21 Feb 2016 13:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXTrewW6EI1y for ; Sun, 21 Feb 2016 13:13:04 -0800 (PST)
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 B3AC61ACE11 for ; Sun, 21 Feb 2016 13:13:03 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aXbJN-0000DDC; Sun, 21 Feb 2016 22:13:01 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
In-reply-to: Your message of "Mon, 22 Feb 2016 07:27:00 +1100 ."  
Date: Sun, 21 Feb 2016 22:13:01 +0100
Archived-At: 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 21:13:06 -0000

>So, with this "Stuff the packet into the tube, done" approach on a p2p
>link, what happens if the packet's destination address isn't present
>on the device or behind the device at the other end?

If the device is a host, nothing. Hosts do not forward packets.
If the prefix is not onlink, nothing (error ICMP).
If the vendor has some experience with p2p links, the router will not send
the packet back on the same p2p link as it arrived from, so again nothing.



From nobody Sun Feb 21 13:29:53 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376EA1ACDEA for ; Sun, 21 Feb 2016 13:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8uVgkiqRIwG for ; Sun, 21 Feb 2016 13:29:50 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 138441ACD8C for ; Sun, 21 Feb 2016 13:29:49 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CBEF960733 for ; Sun, 21 Feb 2016 22:29:47 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.space.net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9025B60730 for ; Sun, 21 Feb 2016 22:29:47 +0100 (CET)
Received: (qmail 63478 invoked by uid 1007); 21 Feb 2016 22:29:47 +0100
Date: Sun, 21 Feb 2016 22:29:47 +0100
From: Gert Doering 
To: Mark Smith 
Message-ID: <20160221212947.GJ21153@Space.Net>
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bNvn4bxlrUVLu6cT"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 21:29:52 -0000

--bNvn4bxlrUVLu6cT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Feb 22, 2016 at 07:27:00AM +1100, Mark Smith wrote:
> > "Stuff the packet into the tube, done".
>=20
> So, with this "Stuff the packet into the tube, done" approach on a p2p
> link, what happens if the packet's destination address isn't present
> on the device or behind the device at the other end?

What happens if you send a packet towards your default gateway and
the destination address isn't presend "behind the device at the other
end"?

It will either be sent somewhere onward, or get dropped.

Jinmei-san pointed to the RFC that explains that it MUST be dropped if
the other end points the address back towards the same link - and for
all other purposes, there is no difference between "send down the tube"
and "send to an explicitely specified gateway on a multiaccess network".

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--bNvn4bxlrUVLu6cT
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVsosS99WwGXkzn/FAQLGNw//Yyab00ZgMAV9vpzJjeWO5Y3vciGVLW5h
JYLW9Tku7jpKa4vamfbdgafYJnKVEWNgd8NOQDCUARzV489gyIeRlkufd8YLzGT6
Z6R5GM3/CHRAeCdN/o9YRKmrd07Dic13yItliQ14DZXPAAjGyTETcwm2/BGOrG0b
MYiuD8aZjLwGuKb4AbZwlswqXk+GSjqT/wb0CkA+b/ukm15K6mrbWJ9WaTxnkcm0
ePmDSOIwnyFf6ONSY8/FF/FC+GbBPxkfB01szA0xka0GoJdSNmwzTQf5OPpfLKxd
5z89LM22iX631xIDCTsAAp5n+ccVgpoiJreyotDyfKTrNzCmWuj5Lu0tdVtuCjBj
Zf2pndH+HrqBhcdH5QkHJP8+1zURZXLfmZFFnbSkFACBLGavQ3o8l6zmPW6kygvO
3AoLyigy7gpOLHlyw7THMcDC5NXTXXqMNgDTjlOyHly708qgCyiiyshXNnSDkfTk
GtNEa8nWhwKsKqcrq4dfUXeRBDtksrTQePN22oY+yjG4gERZURcj4RqbkCoyuy6g
nEvBTgExwqd4Bj3xp0hpHUMJ3TjkasdPVG9hERPQ7Dl0L6E08wlhsOBNxVkWxZnh
wJym8vCRsdzqbcyr10Hnyet1gQJMIDFzPBBcQByUaOu/LY/8mfD55XnF3n5LAF4P
W1Rb9CRHx8E=
=erEV
-----END PGP SIGNATURE-----

--bNvn4bxlrUVLu6cT--


From nobody Sun Feb 21 13:43:26 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6B1B2B68 for ; Sun, 21 Feb 2016 13:43:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7riaPcigp9zW for ; Sun, 21 Feb 2016 13:43:24 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 1E3B21B2B25 for ; Sun, 21 Feb 2016 13:43:24 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id c3so114468571vkb.3 for ; Sun, 21 Feb 2016 13:43:24 -0800 (PST)
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:content-type; bh=4I+jRJ3+fuQGacjDiJdvE9YEyjj2+dOXUt9oTHJqxXE=; b=ZFswrnkgC1TqkWjh3/yqgODNvJ7Ofw/ctYHgt0MiSsae64F+7HMySWe7dvnvhuZJfK 02Tdl5tW+X+8lT8mPASZp8YVxWysN4nI9BfPdv+fFSy4nL1zsdk/bavApeR4iiKtlMMZ UavsNzCaVi3Pwzag7PfDG8siuqjKIR2JA1kHD+LbffL+TErQI3u3wliseR+XubFlOHLR 68zT9hlsq13YwwbDClU3T6g8GAUKVoLJ3QpqdhaHu2AJbuXz5ZQ2JEdEO3Pz1Mtu0DYj ZUaqxAsgfpQVBiJSI22dWACMVs7xacUCjzjgcosZ0MkNC2UH0UjInjyBDR6p6tvtjouf FPEw==
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-type; bh=4I+jRJ3+fuQGacjDiJdvE9YEyjj2+dOXUt9oTHJqxXE=; b=KcgN8HyF7VeZvPg5FEopPbekg+WvPck5k77VEIHqaFitjAItesl7xR33Dn5jDPF7hM V1mbwmRFt5i9YLzWCav1WDSmssli83UANa/oRWY/okySh8lvzuNUbD6wPK3Z679V3Qf7 HboEPeqY+sV48B9tdNzxkgYLY+IoHfu7ubXLuri/kgbwNGcOSoyjQegHNR3dBdnzyqMV c5nEHtrOOodMV2zGMOAJM9rvdg1rq15lDMm7J6k8DFBa9QgnuAx80ayIMJG3aGoln6Aw 3TaNA47LYb0DwXSnwXO4ugNHG6l85EJbLwNoixERwA4cJ5DKP/RQReHyjJHBxAohxJEv CF+Q==
X-Gm-Message-State: AG10YOR0pUjgjuBBjZifHBxv4Qf3CKocECgrzk5DJl4jK/qM9pxZVSxcHuhKb7zGa+3ykIa6jEnZCXsbI4DO9g==
MIME-Version: 1.0
X-Received: by 10.31.54.75 with SMTP id d72mr19828105vka.30.1456091003254; Sun, 21 Feb 2016 13:43:23 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Sun, 21 Feb 2016 13:43:23 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Sun, 21 Feb 2016 13:43:23 -0800 (PST)
In-Reply-To: <20160221212947.GJ21153@Space.Net>
References:  <20160221212947.GJ21153@Space.Net>
Date: Mon, 22 Feb 2016 08:43:23 +1100
Message-ID: 
From: Mark Smith 
To: Gert Doering 
Content-Type: multipart/alternative; boundary=001a11430a1e027fc6052c4e9b8a
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 21:43:25 -0000

--001a11430a1e027fc6052c4e9b8a
Content-Type: text/plain; charset=UTF-8

On 22 Feb 2016 8:29 AM, "Gert Doering"  wrote:
>
> Hi,
>
> On Mon, Feb 22, 2016 at 07:27:00AM +1100, Mark Smith wrote:
> > > "Stuff the packet into the tube, done".
> >
> > So, with this "Stuff the packet into the tube, done" approach on a p2p
> > link, what happens if the packet's destination address isn't present
> > on the device or behind the device at the other end?
>
> What happens if you send a packet towards your default gateway and
> the destination address isn't presend "behind the device at the other
> end"?
>
> It will either be sent somewhere onward, or get dropped.
>
> Jinmei-san pointed to the RFC that explains that it MUST be dropped if
> the other end points the address back towards the same link

"One specific case in which a Destination Unreachable message is sent with
a code 3 is in response to a packet received by a router from a
point-to-point link, destined to an address within a subnet assigned to
that same link (other than one of the receiving router's own addresses). In
such a case, the packet MUST NOT be forwarded back onto the arrival link."

What if the receiving router doesn't know about the "subnet assigned to
that same link"?

Is it a requirement that all interfaces attached to a link have addresses
from all of the prefixes on a link? What checks for that, and where will
the error message be logged?

> - and for
> all other purposes, there is no difference between "send down the tube"
> and "send to an explicitely specified gateway on a multiaccess network".
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--001a11430a1e027fc6052c4e9b8a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 22 Feb 2016 8:29 AM, "Gert Doering" <gert@space.net> wrote:

>

> Hi,

>

> On Mon, Feb 22, 2016 at 07:27:00AM +1100, Mark Smith wrote:

> > > "Stuff the packet into the tube, done".

> >

> > So, with this "Stuff the packet into the tube, done" ap=
proach on a p2p

> > link, what happens if the packet's destination address isn=
9;t present

> > on the device or behind the device at the other end?

>

> What happens if you send a packet towards your default gateway and

> the destination address isn't presend "behind the device at t=
he other

> end"?

>

> It will either be sent somewhere onward, or get dropped.

>

> Jinmei-san pointed to the RFC that explains that it MUST be dropped if=


> the other end points the address back towards the same link


"One specific case in which a Destination Unreachable m=
essage is sent with a code 3 is in response to a packet received by a route=
r from a point-to-point link, destined to an address within a subnet assign=
ed to that same link (other than one of the receiving router's own addr=
esses). In such a case, the packet MUST NOT be forwarded back onto the arri=
val link."


What if the receiving router doesn't know about the &quo=
t;subnet assigned to that same link"?


Is it a requirement that all interfaces attached to a link h=
ave addresses from all of the prefixes on a link? What checks for that, and=
 where will the error message be logged?



> - and for

> all other purposes, there is no difference between "send down the=
 tube"

> and "send to an explicitely specified gateway on a multiaccess ne=
twork".

>

> Gert Doering

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster

> --

> have you enabled IPv6 on something today...?

>

> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard

> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr=
atsvors.: A. Grundner-Culemann

> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)

> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I=
dNr.: DE813185279




--001a11430a1e027fc6052c4e9b8a--


From nobody Sun Feb 21 13:58:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E31B2DB4 for ; Sun, 21 Feb 2016 13:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.794
X-Spam-Level: 
X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyRZQDC2xAYB for ; Sun, 21 Feb 2016 13:58:38 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740961B2DA7 for ; Sun, 21 Feb 2016 13:58:38 -0800 (PST)
Received: from [2a02:fe0:c420:33c::c68] (port=43548 helo=envy.w5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aXc1T-00067T-Fy; Sun, 21 Feb 2016 22:58:35 +0100
Date: Sun, 21 Feb 2016 22:58:35 +0100
From: Tore Anderson 
To: Mark Smith 
Message-ID: <20160221225835.779c0de7@envy.w5.y.home>
In-Reply-To: 
References: 
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 21:58:41 -0000

(snip)

=C2=ABp2p links without ND=C2=BB sounds like a rather shoddy implementation=
 to
me. Even though you won't need ND to discover link-layer addreses on
p2p links, you're still going to need it for DAD, NUD, SLAAC, default
router discovery, more-specific routes discovery, RDNSS discovery, etc.
etc. etc.

=46rom what I can tell, RFC 4861 doesn't in any way exempt p2p links from
supporting ND (see excerpt below). What exactly gave people this idea?

3.2.  Supported Link Types

   Neighbor Discovery supports links with different properties.  In the
   presence of certain properties, only a subset of the ND protocol
   mechanisms are fully specified in this document:

     point-to-point - Neighbor Discovery handles such links just like
                      multicast links.  (Multicast can be trivially
                      provided on point-to-point links, and interfaces
                      can be assigned link-local addresses.)

     multicast      - Neighbor Discovery operates over multicast capable
                      links as described in this document.

Tore


From nobody Sun Feb 21 14:34:48 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C911B2FF1 for ; Sun, 21 Feb 2016 14:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKwSmqN_fgdu for ; Sun, 21 Feb 2016 14:34:45 -0800 (PST)
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 DB0E31B2FFE for ; Sun, 21 Feb 2016 14:34:42 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aXcaN-0000D2C; Sun, 21 Feb 2016 23:34:39 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <20160221225835.779c0de7@envy.w5.y.home> 
In-reply-to: Your message of "Sun, 21 Feb 2016 22:58:35 +0100 ." <20160221225835.779c0de7@envy.w5.y.home> 
Date: Sun, 21 Feb 2016 23:34:38 +0100
Archived-At: 
Cc: Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Feb 2016 22:34:47 -0000

In your letter dated Sun, 21 Feb 2016 22:58:35 +0100 you wrote:
> p2p links without ND sounds like a rather shoddy implementation to
> me. Even though you won't need ND to discover link-layer addreses
> on p2p links, you're still going to need it for DAD, NUD, SLAAC,
> default router discovery, more-specific routes discovery, RDNSS
> discovery, etc.  etc. etc.
> 
> From what I can tell, RFC 4861 doesn't in any way exempt p2p links
> from supporting ND (see excerpt below). What exactly gave people
> this idea?

So far I haven't seen any p2p link where the remote end responded 
to a neighbor solicitation. But maybe I'm just unlucky.



From nobody Sun Feb 21 22:00:45 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280B61B3530 for ; Sun, 21 Feb 2016 22:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.957
X-Spam-Level: 
X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH1YpWjNY-CN for ; Sun, 21 Feb 2016 22:00:42 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 0E41C1B352C for ; Sun, 21 Feb 2016 22:00:42 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5216DA2; Mon, 22 Feb 2016 07:00:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1456120839; bh=OPJyScltNTcov2/zwovN6ILzn0KGS1YwjkNb9x8peLw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qw86wiSVhm1JyyOMNEnLH38GfzlRelGE4d5VnlQHWKSKQpRwBE4vScBUZ7H0M2CQs Vjei8hZszTRiIiBPuuhdU0asshS8PSolt3KdqV6v++al0OE6v40EclGNYJ++juD1C6 P1p8c82n2dgHMjeqQJRyJkU66HFYig3PZUf3wPmQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 45305A1; Mon, 22 Feb 2016 07:00:39 +0100 (CET)
Date: Mon, 22 Feb 2016 07:00:39 +0100 (CET)
From: Mikael Abrahamsson 
To: Gert Doering 
In-Reply-To: <20160221212947.GJ21153@Space.Net>
Message-ID: 
References:  <20160221212947.GJ21153@Space.Net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 06:00:44 -0000

On Sun, 21 Feb 2016, Gert Doering wrote:

> Jinmei-san pointed to the RFC that explains that it MUST be dropped if 
> the other end points the address back towards the same link - and for 
> all other purposes, there is no difference between "send down the tube" 
> and "send to an explicitely specified gateway on a multiaccess network".

There is no difference here between a P2P link and broadcast media.

I've seen for instance DHCPv6-PD implementations that will not null-route 
the aggregate it receives meaning if you get a /56, you assign /64 on your 
internal interface, all the other 255 /64:s will have a nice routing loop 
ping/pong:ing between the delegating router and the DHCPv6-PD receiving 
router.

There are a lot of devices that will do the wrong thing if they're not 
configured correctly, both for p2p and broadcast media.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Feb 22 00:03:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BBC1A892F for ; Mon, 22 Feb 2016 00:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ3C9aoXlbXS for ; Mon, 22 Feb 2016 00:03:06 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC791A88E2 for ; Mon, 22 Feb 2016 00:03:06 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EBFA7D7887; Mon, 22 Feb 2016 00:03:05 -0800 (PST)
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=gyISqQs2HKjS/JxI92YmmfwGCFM=; b= Q5RrZIEYoKrYxZ/JXrQvQ9TZEJOf+x1baV0PQr6U3ZzNnF172nQp+soTn07TpT46 oktCiYgoSUJlLiBIOqt6TI/HPXNUa1cseZshN3jv39JlINz7qrVW64vznfMRbGmB xT3c57mStsO2mAreH0IPRZCFuGSoOfTtUWCyoe8+yeA=
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=WUv3hQY9pVb2rYB+yB0sLy1WhT MFPuNMfvzycTXJ+Zd3fHwT3XsJbLDox9v50xNHb5OUz9JQJYYxvGqKxOgD0445kn VTVl8jLxZDiId8G1YyKh6MC+NBScpnALJW63vqlcRKH6JaTndjglLo4VvF7DYeng zxMwiuTl8AgZuLCY0=
Received: from h.hanazo.no (unknown [195.159.234.46]) (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 BADEFD7884; Mon, 22 Feb 2016 00:03:05 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 880C01149F70; Mon, 22 Feb 2016 09:03:01 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_64D42BB7-F5D1-4179-B991-D36DC7032E89"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <20160221225835.779c0de7@envy.w5.y.home>
Date: Mon, 22 Feb 2016 09:03:00 +0100
Message-Id: <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home>
To: Tore Anderson 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 08:03:07 -0000

--Apple-Mail=_64D42BB7-F5D1-4179-B991-D36DC7032E89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> =C2=ABp2p links without ND=C2=BB sounds like a rather shoddy =
implementation to
> me. Even though you won't need ND to discover link-layer addreses on
> p2p links, you're still going to need it for DAD, NUD, SLAAC, default
> router discovery, more-specific routes discovery, RDNSS discovery, =
etc.
> etc. etc.

at least with regards to the implementations I'm familiar with, that =
means no ND address resolution. address resolution on a link without L2 =
addresses is in any case meaningless. by implication that also means we =
don't do NUD.

multi-access networks aren't around much any more, after the yellow =
cable went out of fashion. John B's draft on per host /64s, got me =
thinking that we can trivially represent an Ethernet (wired or wireless) =
as a set of point to point links. then we can largely remove dynamic =
address resolution also on Ethernet. for wireless that's quite =
attractive. anyone have the energy to join me writing it up for BA?

cheers,
Ole

--Apple-Mail=_64D42BB7-F5D1-4179-B991-D36DC7032E89
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

iQIcBAEBCgAGBQJWysC1AAoJEL7aWKiYQt921YsP/ApTBJS3SDU20Bj18Ugv0+0f
KZw/gCrt52DpOUlia7MXAkE/+1xi+o4MIy67ZIqh8OTfmjsoLhqYKFT3rLbnwjVj
Zu5zYAb7PDgpMLksXkJNZmMwwpqY4ZcgskWBgoeCRHB83I8QAXnY26ITLe0y9UDe
9mOOaUAaIVM/wk6zOnePvaaDRjhCatMVvznlpN2yPdyUtG0QEmD5tr/6L1xlZcMZ
ZZqM3yt7AHlEBs/q3fBg/aimALpGOpjkoBMixjfL4qhKSPmIsxIUEAu5Jewv9x6T
RvIqlgViB+YIVPUBeGMFpKlfDEtmtQKVX4trbGWQaafLnD5+iUgZ1KKrh5RaiGs7
EyrDkNeVpLV2YWFSQ3LVFZ1aUO5aRaOy7ONoUFWM+cmUZ0XFtgQx1Wsu5zCIiO/3
Fii3IG98oZKnRmN14mWRKAV0xXfAdJNsYf+puKm/oNOtf2bkt1GQprGSpVlms/hz
NFiTxJCV/D8/Me72YXlur2g9d2SdVD9lnYc2Ko/n5xK24o7RpPw+4R8HkItRykp+
nll/Ic0WeVFO5ek2a5mnruqzqwtAa7tvCgSyZ9PQblV0PmHxd+DUSBAr987lgkZn
wPPNpKHUfkT94T36JRxsPcE6pjUVR4jqD9U0D7O80sXtho7IRWyQKlp1ukiRNNcA
VScOqeot1a1Rmei+BN3s
=Cu4h
-----END PGP SIGNATURE-----

--Apple-Mail=_64D42BB7-F5D1-4179-B991-D36DC7032E89--


From nobody Mon Feb 22 00:08:42 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDA1A9130 for ; Mon, 22 Feb 2016 00:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOkmURmVzb54 for ; Mon, 22 Feb 2016 00:08:38 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 BA3AE1A0217 for ; Mon, 22 Feb 2016 00:08:38 -0800 (PST)
Received: by mail-oi0-x234.google.com with SMTP id m82so49992017oif.1 for ; Mon, 22 Feb 2016 00:08:38 -0800 (PST)
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-type; bh=wBgmfu0DMKbTIWUQFPQK7QE9iWqfn1MO8Lm8s/x5zIc=; b=HkvCX13R5ah5f+4xVG5dUmRksKtPqWkU/KZMRHdzFm7xYTlm2rlbdZTDmqEB+MNCim elbBmH03ZiU+KbxycAiIWZgz01MM7Cp3JmcW9fz1Z6QH7G3dw5rjqDWcsd6QqcXXi6J8 RSm5exwZggr6o/doy1zW+z3LSsOVVylQhGv5WPSJXEI7WzIeUAC0CCY6haAenP6emteZ EfxSNwi0+rlO0RJKINO4orDL48bn8jCGvoU6NV/zy5dERWLTtJQAZust8A/Up3dAzj2y rzDqkzJtbpIZ4uRgJAsS4oh++fTXCNbfJV0wFUK0jVs044SITCkiVR1Ow4Zf/VWkzZ/O 9m6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wBgmfu0DMKbTIWUQFPQK7QE9iWqfn1MO8Lm8s/x5zIc=; b=IJiTdRguef5EWO+fQ7jJlbjv1c2g6byQR3pv7p3pDte6EJUU3shfCvx9QOdgbwMNgN 6jLvpvFnY0oDQxJ86rL++JqpfjnP92mdBKa8aWssPNonpjdiInF9LHjlBTQnIrw6cOc1 Lvsq8RITVwsfSc5YWShMprm7oCRZBgzgueFiBl9a5K4XQRHajLLavJkkaCwyKQRU1Wn9 /ZYoMqbw0aI9ISZmCZQNVmno/LyUxKvrkcE+IwH/zQLr0V+EZPa6/OY2h5d/35Aj/tpp Fr9qDE+eYm3Nw0PE26WqEXG7VTPws0B9y7J1YCgIGuBAZ+8e9qyYm5ch+WbuZmbXAQgT 6EYw==
X-Gm-Message-State: AG10YOR3CZKqYzMpae5S6A8M6462REHYZLkRrKkrzXK6JieJgJStcaJ5rtzqf417l/LCJwBM23PW/xNU2U7Dlw==
X-Received: by 10.202.95.68 with SMTP id t65mr19718401oib.7.1456128518112; Mon, 22 Feb 2016 00:08:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.18.132 with HTTP; Mon, 22 Feb 2016 00:08:18 -0800 (PST)
In-Reply-To: <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
From: Ivan Pepelnjak 
Date: Mon, 22 Feb 2016 09:08:18 +0100
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=001a113cdb1411cf1a052c575780
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 08:08:40 -0000

--001a113cdb1411cf1a052c575780
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 22, 2016 at 9:03 AM,  wrote:

> > =C2=ABp2p links without ND=C2=BB sounds like a rather shoddy implementa=
tion to
> > me. Even though you won't need ND to discover link-layer addreses on
> > p2p links, you're still going to need it for DAD, NUD, SLAAC, default
> > router discovery, more-specific routes discovery, RDNSS discovery, etc.
> > etc. etc.
>
> at least with regards to the implementations I'm familiar with, that mean=
s
> no ND address resolution. address resolution on a link without L2 address=
es
> is in any case meaningless. by implication that also means we don't do NU=
D.
>
> multi-access networks aren't around much any more, after the yellow cable
> went out of fashion. John B's draft on per host /64s, got me thinking tha=
t
> we can trivially represent an Ethernet (wired or wireless) as a set of
> point to point links. then we can largely remove dynamic address resoluti=
on
> also on Ethernet. for wireless that's quite attractive. anyone have the
> energy to join me writing it up for BA?
>

Can't resist asking this question: why did we have to go through 20 years
of sidetracking and reinventing wheels to come back to the conclusions that
first-hop network device should be a router, that 64 bit addresses are long
enough and that CLNP did the right thing with host routing on the network
edge?

Cheers,
Ivan


>
> cheers,
> Ole
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--001a113cdb1411cf1a052c575780
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 22, 2016 at 9:03 AM,  <otroan@employees.org> wrote:
> =C2=ABp2p links without N=
D=C2=BB sounds like a rather shoddy implementation to

> me. Even though you won't need ND to discover link-layer addreses =
on

> p2p links, you're still going to need it for DAD, NUD, SLAAC, defa=
ult

> router discovery, more-specific routes discovery, RDNSS discovery, etc=
.

> etc. etc.



at least with regards to the implementations I'm familiar with, that me=
ans no ND address resolution. address resolution on a link without L2 addre=
sses is in any case meaningless. by implication that also means we don'=
t do NUD.



multi-access networks aren't around much any more, after the yellow cab=
le went out of fashion. John B's draft on per host /64s, got me thinkin=
g that we can trivially represent an Ethernet (wired or wireless) as a set =
of point to point links. then we can largely remove dynamic address resolut=
ion also on Ethernet. for wireless that's quite attractive. anyone have=
 the energy to join me writing it up for BA?

Can't resist asking this question: why did we have to go through =
20 years of sidetracking and reinventing wheels to come back to the conclus=
ions that first-hop network device should be a router, that 64 bit addresse=
s are long enough and that CLNP did the right thing with host routing on th=
e network edge?

Cheers,
Ivan
=
=C2=A0



cheers,

Ole


_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--001a113cdb1411cf1a052c575780--


From nobody Mon Feb 22 00:21:29 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDD91ACEE4 for ; Mon, 22 Feb 2016 00:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10X40w_F7DX7 for ; Mon, 22 Feb 2016 00:21:25 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 D40711ACEB1 for ; Mon, 22 Feb 2016 00:21:24 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A2B4062C7F for ; Mon, 22 Feb 2016 09:21:22 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.space.net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6866F6013B for ; Mon, 22 Feb 2016 09:21:22 +0100 (CET)
Received: (qmail 90746 invoked by uid 1007); 22 Feb 2016 09:21:22 +0100
Date: Mon, 22 Feb 2016 09:21:22 +0100
From: Gert Doering 
To: Tore Anderson 
Message-ID: <20160222082122.GK21153@Space.Net>
References:  <20160221225835.779c0de7@envy.w5.y.home>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eP8xGX2lG1UwfyBj"
Content-Disposition: inline
In-Reply-To: <20160221225835.779c0de7@envy.w5.y.home>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 08:21:27 -0000

--eP8xGX2lG1UwfyBj
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Feb 21, 2016 at 10:58:35PM +0100, Tore Anderson wrote:
> (snip)
>=20
> =ABp2p links without ND=BB sounds like a rather shoddy implementation to
> me. Even though you won't need ND to discover link-layer addreses on
> p2p links, you're still going to need it for DAD, NUD, SLAAC, default
> router discovery, more-specific routes discovery, RDNSS discovery, etc.
> etc. etc.
>=20
> From what I can tell, RFC 4861 doesn't in any way exempt p2p links from
> supporting ND (see excerpt below). What exactly gave people this idea?

Implementations I know do DAD and SLAAC (dunno about NUD, though).

What is not done is link-layer address discovery, because there is no=20
need to do so - and the paragraph above acknowledges this.

Mark wants implementations to do that, as far as I can discern, as he
wouldn't otherwise know whether or not the peer has a given address - and
I maintain this does not truly matter.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--eP8xGX2lG1UwfyBj
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVsrFAt9WwGXkzn/FAQIxVg//fv6KOvRGMEs+dRsFNcdHiipUE44j7Ebs
CEM9iJFmvO/YC3agkJMFOhKqEGZauShS2k8Mp5kcN+Ru7TIuH8WtO0+hvf5W5fGR
xtqMnWJs6m9lAuOxkaHnAFp10sC9RHOlsiCGxhXCcTC41Ek2inNuzmVp1NAGQOEx
Z63jjbgfB6qkW6j40GePEdtaEcctlAwLqyo4vDPZVhSwFFJwFZckgjizc2ur+SEI
zHZnGPi0d0YjxacTPElNa8rYDuZHJ4vxLWApL3zzD3xkVqsc+QAWn3JS/lTcOIk9
LNUMlE3+/L9RnB4n+0kMvLTk8PCXirX0fXBV09s0LXedGU8FU80r28W40RFR4nT4
ReKsaq7W1zADj2aR+PcB/YKLbwfyVTWjyMQlcFdiKGL1jyoWJ2HHEwsrweyGDvgR
R1Au5fmNha/jLAzOeLhAzzelo4rIFPvvTI9enr2dDj+t7wbJejYfXzzOCPrye7ck
eiMvY5ryPHCeXxycVaHXawxXOxQScHWz4UC/CzmguRLQlDj0Cj8EBCS8Fk0OdxN+
rQfDaXdeTSZtbUHZubyWU+VS3F8x37VU0gVJJxhranHbAjN/gydyMtEwyKXm/g/c
0D5iAEcEtO0M+kDvOOud0i/LIS7stKGzJCWP/V/Imuk8wLGGPtvyUZycYNnXP1e3
UHD4Gd3+5DU=
=B95h
-----END PGP SIGNATURE-----

--eP8xGX2lG1UwfyBj--


From nobody Mon Feb 22 01:25:09 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7A81B2E0B for ; Mon, 22 Feb 2016 01:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt0FrPGYVWZH for ; Mon, 22 Feb 2016 01:25:05 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C59B1B2E10 for ; Mon, 22 Feb 2016 01:25:05 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id A42C5D7887; Mon, 22 Feb 2016 01:25:03 -0800 (PST)
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=a3/Ch78w3PVVSbmrOn+N7PKln2c=; b= PKYLABvm5YTXTDqx3e0gza/QtDRA29rqPx3UCeGsAaRDG2CAbuDNB24f5xvLhNGz BH2q2O5Uzc5uq4r1cJz6U/jdjmseHKPHFsyQuX7/61UGv0SDHC53MPyDwm17vokE 1nNpYdcJQ8a7vDrVsi2T+QkIxJaF0kR9u4azAGR3UP0=
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=g5rBEF/O1v5523xEtuKdOyNPbb jRoTBqtZ43HtNyVJcEQ+E3dMU0cFJGDLN0H5P/kgzukLSxJFhTk8YZweplD9Sx7j lcCRtbAMFEaEAuZUcwuFm+Z5an9u6sWLYvl9dogPTyvLon37dM9cd3n3hTsS5hNA PWtBvgd0njCRpfvt8=
Received: from h.hanazo.no (unknown [173.38.220.46]) (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 6634AD7884; Mon, 22 Feb 2016 01:25:03 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E7857114EC92; Mon, 22 Feb 2016 10:25:00 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_6A1BAD04-7D48-4857-8E57-74794443057D"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Mon, 22 Feb 2016 10:24:59 +0100
Message-Id: <442195BD-1F54-450B-A265-03BF05638F54@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> 
To: Ivan Pepelnjak 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 09:25:07 -0000

--Apple-Mail=_6A1BAD04-7D48-4857-8E57-74794443057D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

[...]

> Can't resist asking this question: why did we have to go through 20 =
years of sidetracking and reinventing wheels to come back to the =
conclusions that first-hop network device should be a router, that 64 =
bit addresses are long enough and that CLNP did the right thing with =
host routing on the network edge?

the main problem is that we are software engineers. given a set of =
constraints we'll figure out a solution to your problem. the constraints =
have typically been "router ports are expensive" or "I already have a =
bridge here", or my application must be on the same L2 (e.g. Bonjour).

Resulting in a very complex set of layer violating features (SAVI, =
RA/DHCP guards, ND/ARP snooping, multicast/unicast rewrite, RA =
throttling...) in bridges and APs. Perhaps the pendulum is on its way =
back and we have an opportunity to set things right?

A subnet model with p2p links between router and host have none of these =
problems.

Best regards,
Ole

--Apple-Mail=_6A1BAD04-7D48-4857-8E57-74794443057D
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

iQIcBAEBCgAGBQJWytPsAAoJEL7aWKiYQt92w7AP/Rk3jCyVOD15o84hdESOPFL5
QxIe41ddmM/kZG9C8LPDNg+p5RGWK2ehy78Bul0Sk0UGSsitLVjn8BvBxP1R/ZH8
kGXbS7appy9+5oOKJt3VW13YDVd3BQH6w1m0cXxe41r4viWsYYlg3ktFNKozNZcK
6LE3rpSur7AmSKMQgIowRMeoQ0C9KLIJNYyDMK28lXFgsnYqEuq5F6K7sZZajBnX
/aS5YcspqA9koq3XYwvBjbwS8IA/srR1CdfgcrWObf6ApHhIGO4EB8CUCXWeL0Ea
P3PZYWH0q6/rkzuGH3f3Cs19lNqKRFIRFRAUTNQgzx1H9nKInVyl7NTOXv1kMf67
jVwyJfPyhVCkjS65OoaZdIPVj3guhQDwXHaQu8J/0+ydFiwU+ZXA6ojw1YMjuYQ0
zG/TbuBD7/T1SGVhU/deyzHunjZ5k1ixc0AOogF/BIWoLdRWqIcmvikAw7xe7yjb
gGpP6kf3r19934cIxHN56sT3WOiY9QGTBIun2Nm5hJfIl1YoBG69X9ScfqD+XV3I
BAQ/bSI1z8/odRIG60xfGhNkjznaMpGGwuOFGtZgc4VnMe0JLFf24XTS1YIJF7pq
o5Do6i6I8AijWKtkti5XUkK9xznhBLlKyNdaU032VaEA8HbMgUiYCdndI84KmHZM
vRbOUsdL8K1uftUCwSjR
=LXnH
-----END PGP SIGNATURE-----

--Apple-Mail=_6A1BAD04-7D48-4857-8E57-74794443057D--


From nobody Mon Feb 22 01:32:00 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E661B2E8C for ; Mon, 22 Feb 2016 01:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVD1JDBj-e0c for ; Mon, 22 Feb 2016 01:31:55 -0800 (PST)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 6BD851B2C9F for ; Mon, 22 Feb 2016 01:31:55 -0800 (PST)
Received: by mail-vk0-x235.google.com with SMTP id e6so123965671vkh.2 for ; Mon, 22 Feb 2016 01:31:55 -0800 (PST)
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-type; bh=J7rQCjo6LTsbdGa6CTlxBfnqbiW8XQLEjj52eG0jMJc=; b=bs4Geq2FsgsIrddxun92YTYvwypMrtJ/4wkRKNsG0LQCda3+1qyCjBZtiFrAvWfVpf nQfEYnn31b71OY3N6l99MrryyL6WgmHkP9mzFp86HHzpk2B4c6+loOIZ9SDqDOIvBAHw CsXQBSTpe6nHSUHOXqETA55QSRZFg+ps7n4fvUA6nq1xxHhdPZ0AAIhC9mRUJHNfcQiZ yHZ28BW+3i6nOQN0P0ddDIB1UzMSeI1rFnwSJyC/wXORrHaOFScLrE9FgG18W8bUK0Zh R23ex5eopMysNzoBTRjgvGKelt/7BzF8CBbkp+A0gGwdhohx3L950ECzPoiP4QHlI7px rEMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J7rQCjo6LTsbdGa6CTlxBfnqbiW8XQLEjj52eG0jMJc=; b=A4uX6xNgPP/DqG9xPYp3yxvhM7GRVGtIy4/8Q3UufAsU9M2QSjGHsHRIUisLyrIm0m akJ7VpFZ4cCsTjI4NGiRMWVtcF4sIGc1o/84GblpXlr1R+1RS81G2avxm+cYFrfje0fU XZIJVvzxvAP8xtV99n/yFDPBvdM5LnShiPGENvBkgSG9H8ed9W4CK8zoRurJ34fWkA2e +8dY+ax04UUoLCJs744DT8SR5cyTmwMxDfiUGZAvW2eI4S1R/PGBokE/ticvH3Eb3UBS /R1txp5QsFS0u8WGx7t54C5L91r9ihNFApnB3EtkiNaILfMpMB8ewZRFoIx4R5/lmOgy 5PRg==
X-Gm-Message-State: AG10YOQooxxw3m2bPUqcOSHLqbjZXHQZ/FAPXU43mrU7DcFnktfZJb2MKqXWDrO4SPwixACZdESX2feeFhMayA==
X-Received: by 10.31.167.195 with SMTP id q186mr21623982vke.113.1456133514497;  Mon, 22 Feb 2016 01:31:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Mon, 22 Feb 2016 01:31:25 -0800 (PST)
In-Reply-To: <20160222082122.GK21153@Space.Net>
References:  <20160221225835.779c0de7@envy.w5.y.home> <20160222082122.GK21153@Space.Net>
From: Mark Smith 
Date: Mon, 22 Feb 2016 20:31:25 +1100
Message-ID: 
To: Gert Doering 
Content-Type: multipart/alternative; boundary=001a11425fbae096b9052c588093
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 09:31:57 -0000

--001a11425fbae096b9052c588093
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 22 Feb 2016 7:21 PM, "Gert Doering"  wrote:
>
> Hi,
>
> On Sun, Feb 21, 2016 at 10:58:35PM +0100, Tore Anderson wrote:
> > (snip)
> >
> > =C2=ABp2p links without ND=C2=BB sounds like a rather shoddy implementa=
tion to
> > me. Even though you won't need ND to discover link-layer addreses on
> > p2p links, you're still going to need it for DAD, NUD, SLAAC, default
> > router discovery, more-specific routes discovery, RDNSS discovery, etc.
> > etc. etc.
> >
> > From what I can tell, RFC 4861 doesn't in any way exempt p2p links from
> > supporting ND (see excerpt below). What exactly gave people this idea?
>
> Implementations I know do DAD and SLAAC (dunno about NUD, though).
>
> What is not done is link-layer address discovery, because there is no
> need to do so - and the paragraph above acknowledges this.
>
> Mark wants implementations to do that, as far as I can discern, as he
> wouldn't otherwise know whether or not the peer has a given address - and
> I maintain this does not truly matter.
>

So one of the reasons I think it would be useful is that it is better to
not send a packet as soon as it is known the destination doesn't exist.

Probing for an addresses presence, and then tracking its continued presence
with NUD puts a router in a position to drop the packet as soon as the
packet arrives at the link where the address space exists.

Methods such as the RFC4333 text or /127 are reactionary, they're trying to
suppress the consequences of forwarding a packet for which the destination
doesn't exist, rather than discovering if the destination exists, using an
existing discovery mechanism.

There is certainly the issue of neighbor cache DoS attacks, but we cannot
avoid having to solve or mitigate them for multiaccess links, and that
method could easily be applied to p2p links, as conceptually they can be
treated as multi access links with 2 hosts, as RFC4861 does.


> Gert Doering

>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--001a11425fbae096b9052c588093
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 22 Feb 2016 7:21 PM, "Gert Doering" <gert@space.net> wrote:

>

> Hi,

>

> On Sun, Feb 21, 2016 at 10:58:35PM +0100, Tore Anderson wrote:

> > (snip)

> >

> > =C2=ABp2p links without ND=C2=BB sounds like a rather shoddy impl=
ementation to

> > me. Even though you won't need ND to discover link-layer addr=
eses on

> > p2p links, you're still going to need it for DAD, NUD, SLAAC,=
 default

> > router discovery, more-specific routes discovery, RDNSS discovery=
, etc.

> > etc. etc.

> >

> > From what I can tell, RFC 4861 doesn't in any way exempt p2p =
links from

> > supporting ND (see excerpt below). What exactly gave people this =
idea?

>

> Implementations I know do DAD and SLAAC (dunno about NUD, though).

>

> What is not done is link-layer address discovery, because there is no<=
br>
> need to do so - and the paragraph above acknowledges this.

>

> Mark wants implementations to do that, as far as I can discern, as he<=
br>
> wouldn't otherwise know whether or not the peer has a given addres=
s - and

> I maintain this does not truly matter.

>


So one of the reasons I think it would be useful is that it =
is better to not send a packet as soon as it is known the destination doesn=
't exist.


Probing for an addresses presence, and then tracking its con=
tinued presence with NUD puts a router in a position to drop the packet as =
soon as the packet arrives at the link where the address space exists. 


Methods such as the RFC4333 text or /127 are reactionary, th=
ey're trying to suppress the consequences of forwarding a packet for wh=
ich the destination doesn't exist, rather than discovering if the desti=
nation exists, using an existing discovery mechanism.


There is certainly the issue of neighbor cache DoS attacks, =
but we cannot avoid having to solve or mitigate them for multiaccess links,=
 and that method could easily be applied to p2p links, as conceptually they=
 can be treated as multi access links with 2 hosts, as RFC4861 does.

> Gert Doering

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster

> --

> have you enabled IPv6 on something today...?

>

> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard

> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr=
atsvors.: A. Grundner-Culemann

> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)

> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0USt-IdNr.: DE813185279






--001a11425fbae096b9052c588093--


From nobody Mon Feb 22 01:33:57 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419101B2E99 for ; Mon, 22 Feb 2016 01:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.957
X-Spam-Level: 
X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk3yht6pFROE for ; Mon, 22 Feb 2016 01:33:54 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 1BC0C1B2E97 for ; Mon, 22 Feb 2016 01:33:54 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 27E36A2; Mon, 22 Feb 2016 10:33:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1456133632; bh=LN1EKu2H35FbEcTa12jXlzM6NNlkyP32YryuR3a82ig=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bUJDXzoYezxqAcnX4/Z8Ab6HQvd87/i+tA/s2XZCPYTvjOkSOZbumOlFFbCVhu2Aa C/xaruqD43JyBIt1KqnG4ixRD9me8CduIC39/+XjWZaaFdbt8+tG8Jbj6bxEF/IWHG mXwWEtP1sHBdbxfT2lT6O5J/AWNaLf8NiSHpLW14=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E356A1; Mon, 22 Feb 2016 10:33:52 +0100 (CET)
Date: Mon, 22 Feb 2016 10:33:52 +0100 (CET)
From: Mikael Abrahamsson 
To: otroan@employees.org
In-Reply-To: <442195BD-1F54-450B-A265-03BF05638F54@employees.org>
Message-ID: 
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 09:33:56 -0000

On Mon, 22 Feb 2016, otroan@employees.org wrote:

> Resulting in a very complex set of layer violating features (SAVI, 
> RA/DHCP guards, ND/ARP snooping, multicast/unicast rewrite, RA 
> throttling...) in bridges and APs. Perhaps the pendulum is on its way 
> back and we have an opportunity to set things right?

Yes, I hope so. I keep advising people to not share /64 between customers. 
This is perfectly doable with a lot of equipment (for instance several 
models of L3 switches from the past 5 years), but I receive pushback 
because "it's not how we do things" (which for me is a bad reason), or 
"service discovery doesn't work" (which actually is a valid concern).

I've advised some people to use protocol based vlans to make a 
vlan-per-customer for IPv6 with its own /64 per customer, and keep IPv4 
ethertypes the same way they do things now (multiple customers per vlan, 
SAVI etc), and some never thought about this and thought it was an 
interesting idea, and some others thought it was too complicated.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Feb 22 02:07:55 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6D1B2A53 for ; Mon, 22 Feb 2016 02:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfJl5dDiPMIA for ; Mon, 22 Feb 2016 02:07:53 -0800 (PST)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 E50641ACD8D for ; Mon, 22 Feb 2016 02:07:52 -0800 (PST)
Received: by mail-vk0-x236.google.com with SMTP id k196so125934433vka.0 for ; Mon, 22 Feb 2016 02:07:52 -0800 (PST)
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-type:content-transfer-encoding; bh=oEZ8u6+RYwZMKFoqzciX3BY0Cf3pL5e++OJJDlhkaiI=; b=OFoMc7lNsUjmoPHSNo0N0dSJ34GULKnvdQYLcQiYEefJeioTSUUwup7CiQz7qgLhLv Dtpjmcbc7++ssmX9i84GELb5ZwdwAp51yGs9LKd2P1V02G6Q71WP6vljOPHQ1ov3cza2 moBLEkkoP/gsF6mCf2ReuGhf50oGJMWJsoIHwkhgYYwVRct/p13v2+YJsFcJaVOA6daM 1b9JH5uqB4TUPKNn+CsLsHbcQNdWjsoTw9j5+B3CZBkorJWKCBOGLaB3tGDa+8hTkg4/ sPqAuxzynLwL90sP7wbUECHy/rkRDUDjjscxHpGtp5wSkqSf/jakC8Ae0nachFmoSjY8 Nn9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oEZ8u6+RYwZMKFoqzciX3BY0Cf3pL5e++OJJDlhkaiI=; b=fHigAkhUFWfWLWu42YxOdIjZDXbgpu+1leS8pDE2MgtT1l7VuEeoy4u6cP7UloYdCZ 6CPApyvGiTPkKIb+XBWxsbADug9wCe5iG3B5NZXNLVjPBn/Cz8fegvxkWg+w4iPLBzxF Kmint9hixXtv+5YFN14czPCIf6rSyl187oej1WaV3CuciDv5++plPrOhLnb+/HSA3xzR uIvvhg2V+QhWTibPSnQFi4dfrALw89FoMcFnBMPctqjYkre35YllmAjDqiUl/y8vc/6A Izc/R0SphkIY+7yTGtI45YM6bhNnkZLa/457wWN7c8UUhngF6EfZHWCGfmYO2//48q4K k2XQ==
X-Gm-Message-State: AG10YOTdf99NcHo3qm1cdmnMGgMyI/bq//eeSa9k9x4yJDdokV59G39VSEEgnpVwXLexYX2tj3bqP5GfkwnvBg==
X-Received: by 10.31.58.83 with SMTP id h80mr22732113vka.149.1456135672069; Mon, 22 Feb 2016 02:07:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Mon, 22 Feb 2016 02:07:22 -0800 (PST)
In-Reply-To: <442195BD-1F54-450B-A265-03BF05638F54@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>
From: Mark Smith 
Date: Mon, 22 Feb 2016 21:07:22 +1100
Message-ID: 
To: Ole Troan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 10:07:54 -0000

On 22 February 2016 at 20:24,   wrote:
> [...]
>
>> Can't resist asking this question: why did we have to go through 20 year=
s of sidetracking and reinventing wheels to come back to the conclusions th=
at first-hop network device should be a router, that 64 bit addresses are l=
ong enough and that CLNP did the right thing with host routing on the netwo=
rk edge?
>
> the main problem is that we are software engineers. given a set of constr=
aints we'll figure out a solution to your problem. the constraints have typ=
ically been "router ports are expensive" or "I already have a bridge here",=
 or my application must be on the same L2 (e.g. Bonjour).
>
> Resulting in a very complex set of layer violating features (SAVI, RA/DHC=
P guards, ND/ARP snooping, multicast/unicast rewrite, RA throttling...) in =
bridges and APs. Perhaps the pendulum is on its way back and we have an opp=
ortunity to set things right?
>
> A subnet model with p2p links between router and host have none of these =
problems.
>

So all of this is actually one of my main motivations behind:

Indicating Link-Local Unicast Destinations are Off-Link
https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with
multiple hubs), gives us the ability to preserve the address space and
routing aggregation advantages that a multi-access link provides, with
all attached hosts sharing a single /64 prefix, while inserting a
router between each and every host, with the router also being a
traffic inspection point between all other destinations, allowing I
think much easier implementation of protections such as SAVI, RA/DHCP
guards etc. etc.

I think the two current gaps are:

- the link-local assumption of on-link, and the inability to override
that assumption

- multicast propagation so that protocols such as Bonjour continue to
operate across all of the same link attached hosts


I'm not at all against the idea of delegating prefixes to hosts.
However I think it should be an alternative option to multiple hosts
sharing a single /64, rather than a replacement. I can see some
networks might have a mix of both per-host/64 while others hosts still
share a /64, perhaps with a hub-and-spoke forwarding link-layer.

Regards,
Mark.





> Best regards,
> Ole
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Mon Feb 22 02:20:30 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A145E1B2FA7 for ; Mon, 22 Feb 2016 02:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh9Hj7gSKEbG for ; Mon, 22 Feb 2016 02:20:26 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583EE1B2FA4 for ; Mon, 22 Feb 2016 02:20:26 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 9081BD7887; Mon, 22 Feb 2016 02:20:25 -0800 (PST)
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=4a/APJdBYtetNVYZ01DBYvLk5hU=; b= jvZEwV/alg3zx2kvjiGcUrMk1va4VQIXQEZtIkrB9E4dtOhjXQQ4CwT5goMRVbAl jpYwGiTgSsG9Ji1gsZReGRz+QHFkI8m8L5zMnHu/8w+3iPK1ygKytxj/JPgEyeix JEbKA9DF5gP4kKaOLWRG+cb1KuAQYWmjZv4dvey0foQ=
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=KUYssG4Ctk6eKdwNGP4v/2TK5k VUqzLX6Y0xdrfDIbfZ6TPAx6FCcAy9YHde3KBMYlJlqwNV5AMdoi25KnDF2sl+mH MrihatvHBz/rBwZJJYoock2RhLYuRaSDNG8lYMCajrMpQcINKocWs8CqRbzqmnsU vIXF7nE2BxJnWgKBI=
Received: from h.hanazo.no (unknown [173.38.220.46]) (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 21C0FD7883; Mon, 22 Feb 2016 02:20:25 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DEF031150446; Mon, 22 Feb 2016 11:20:22 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_43BD9F3A-6F1C-4110-855F-2F6817202616"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Mon, 22 Feb 2016 11:20:22 +0100
Message-Id: <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org> 
To: Mark Smith 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 10:20:28 -0000

--Apple-Mail=_43BD9F3A-6F1C-4110-855F-2F6817202616
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> A subnet model with p2p links between router and host have none of =
these problems.
>>=20
>=20
> So all of this is actually one of my main motivations behind:
>=20
> Indicating Link-Local Unicast Destinations are Off-Link
> https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

in a p2p model link-local is constrained to the link. just like you =
expect it to be.

> Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with
> multiple hubs), gives us the ability to preserve the address space and
> routing aggregation advantages that a multi-access link provides, with
> all attached hosts sharing a single /64 prefix, while inserting a
> router between each and every host, with the router also being a
> traffic inspection point between all other destinations, allowing I
> think much easier implementation of protections such as SAVI, RA/DHCP
> guards etc. etc.
>=20
> I think the two current gaps are:
>=20
> - the link-local assumption of on-link, and the inability to override
> that assumption

that's not a gap. you most definitely do not want link-locals to work =
across links.

> - multicast propagation so that protocols such as Bonjour continue to
> operate across all of the same link attached hosts

protocols that can only operate on a single link are broken.
multicast on p2p links are trivial.

> I'm not at all against the idea of delegating prefixes to hosts.
> However I think it should be an alternative option to multiple hosts
> sharing a single /64, rather than a replacement. I can see some
> networks might have a mix of both per-host/64 while others hosts still
> share a /64, perhaps with a hub-and-spoke forwarding link-layer.

in a p2p model you can use whatever addressing model suits you.
(including single address to each endpoint on the link if you so =
desire.).

Best regards,
Ole

--Apple-Mail=_43BD9F3A-6F1C-4110-855F-2F6817202616
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

iQIcBAEBCgAGBQJWyuDmAAoJEL7aWKiYQt92SaoQAIQWtEUAnM0ASkBZSfRRQDeT
TYj4kzHvA6DrNeSV0KJ6QQT8q0Apts6ozLQWWSBPO669SJIQkNWm6UBMJ6YfpVeq
SEoMyyjKCMKNBRYrURKkOckp2Ns1PgH0iXxp/qikaTgZcoOP8FN170YY9zzeC/HH
kF4jMD1T5zHE3YB6j2mNik8vyLdrHEVbLl7cHs/Xl729U8TLYedRdJmjcD49vwlm
6s5RZF55KVAuVgVi42qPPirtUJd88RMe/sRrZ7qguP9nrAdmyJ+yk2jpFd5H56NU
6QEeyoRusP5pSqo0Sg/VIRVtytQhk2212JDdCu7GsAyDcLnGzABTrI0l/Qmq/oo5
6bcXCbvEvnbanEiDyO77asBOJ240LQO+fQ3WvFUtWzvNg/I/GspVkJ7E4Z3JXhlk
ym+lifAtACA0DjJ06kr3CXhz6Vq396xgKcXe2cOeyXrp5LqCJbKmV9qPBU1uDvbu
S/q74OyQgZTnihyrXYRCdalX6Ei0OVB92W2DFskZNtFEO0qs7pGKlxXzGIG0QKNk
A9SDbPH9Vc/mUNp03aTYOkMnG1g/XnloDoI2j+pucKtkExgVGBOq7O3OsHvtlekA
L4pSbxmO7LM14Hyr1HvgvIdy048iwQPJqulbRLx/jEXBoMcbQB1gdThDKYndozix
/P/jqmS01FeH0sfcCVwM
=HC3M
-----END PGP SIGNATURE-----

--Apple-Mail=_43BD9F3A-6F1C-4110-855F-2F6817202616--


From nobody Mon Feb 22 02:48:11 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B411B302C for ; Mon, 22 Feb 2016 02:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l37uoAQ6-MYM for ; Mon, 22 Feb 2016 02:48:09 -0800 (PST)
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 B67FE1B3025 for ; Mon, 22 Feb 2016 02:48:08 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id e185so125470808vkb.1 for ; Mon, 22 Feb 2016 02:48:08 -0800 (PST)
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-type; bh=7HjTv2IaX0IAYM63VkofeL1FLW8OyR1orEKTkFACPMA=; b=mqlmJ3vyz/GXZqXH4GlPKLQX81Il0uF09yPzF1BtzBuz8FUIPEJnH87YPcs/4GaLmX ftK2GQtqPbLOi8wfRFNU41KimopG9hFZq09arLJr6DpyAKLPWhb0E7myMubLhNxpio1Y 6lrzoKNVNfsBp8ksF40BK12e5ebt5y8RuOJHRa5IM+VQkX/T//PZuQSkvtbll8OkocXi 6qIMUUI+cuaWOGPqiEUBqw+TecWjskIxPtfOX9+b5Ew+DLsJTBWeecxMqbG/nkYRMw8t 7EHmximmJOygb0fAor3GeIND6LuR+o/PW/idXQIj8ZOlulqIU9sxD1R++ayv5upEA/xO kDSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7HjTv2IaX0IAYM63VkofeL1FLW8OyR1orEKTkFACPMA=; b=F6odAd1tTcQwUb+Iq15OKal00oKT7ordOp4oulpO9OuG8XpDVKH5cpnjFRUZ+vt/Cv xboh6gRwiGyVzY8gGjJ9TT3fQt+7G8VaI0WGTG4WvAJKJdybyMi40xTzaEVlNTCYK8wG jacNkps9lTxOjI5lgzqTGIJaU05N8r09jQ8bf8UxUWE+t9GjvgJ6D3C1iOMM1GtmVuGT DJTgCTeSXqKOPoNaEpDvu1lZZ91liLF55JZ6q3F3WX3s+o4djNxqARBosVhahmgiMJlc P/FB+Pbb/8EDi0haraWr39ER+ORK3pl4LlgNDLiYciuXzmc3A5b+dtUj8c6oe6kacevf iKIA==
X-Gm-Message-State: AG10YOSEd9th3OR6QHrhCFbvTZ81Z1FIStoYq2e8Ia+HrGyLBJMzWJQ6SIkUHVeIXg+vyKPNBtn3kSJb4vg26Q==
X-Received: by 10.31.54.75 with SMTP id d72mr21767986vka.30.1456138087799; Mon, 22 Feb 2016 02:48:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Mon, 22 Feb 2016 02:47:38 -0800 (PST)
In-Reply-To: <56BB3498.6000108@globis.net>
References:  <56B9EEBC.7030007@globis.net>  <56BB3498.6000108@globis.net>
From: Mark Smith 
Date: Mon, 22 Feb 2016 21:47:38 +1100
Message-ID: 
To: "Ray Hunter (v6ops)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 10:48:10 -0000

Hi Ray,

Sorry not to get back to you sooner.

On 11 February 2016 at 00:01, Ray Hunter (v6ops)  wrote:
>
>
> Mark Smith
> 10 Feb 2016 02:50
>
> Hi Ray,
>
> On 10 February 2016 at 00:50, Ray Hunter (v6ops)  wrote:
>
> Mark Smith wrote:
>
> 
>
> I have read this draft.
>
> Thanks very much for having a read.
>
> At first glance it looks like a smart idea, because a defending router only
> has to track perhaps a thousand entries of state versus potentially having
> to store state for billions of "incomplete" queries.
>
> A couple of questions.
>
> 1) How often/when is the MLD cache updated/ timed out?
>
>
> MLD operation is not changed, so what ever the MLD protocol timers are.
>
> ACK.
>
> My concern here is that you now have two caches interacting (mulitcast group
> membership and ND cache), and the timing of adding and deleting entries
> could cause race conditions. Some discussion of how the caches interact (or
> not) could be useful IMHO.
>
> Other than using the MLD membership list to determine if to ND NS for
> a unknown address, there isn't any interaction between the ND and MLD
> caches/memberships lists.
>
> Was there a section which seemed to imply they were interacting more
> than the ND process using the information in the MLD membership list?
> I'm happy to add a statement that they aren't interacting, just
> wondering if there is a specific section/paragraph where you think it
> might be best placed?
>
> It's more about potential race conditions.
>
> If you're using the contents of a cache that refreshes on one timer (and
> which is potentially unreliable) to perform filtering of actions in another
> cache that updates on another set of timers, there has to be some sort of
> interaction.
>
> As an example: router boots up. MLD cache is totally empty. The node on the
> LAN may have already discovered this router as its default router, and
> routing protocols may have already converged. The filter on inbound
> connections based on MLD cache should probably not be applied until the MLD
> cache is populated, and possibly a couple of update cycles completed.
>
> Another potential example: Node boots up. MLD is between refreshes and the
> router does not see a join request. Inbound connection attempt arrives.
> Router filters the connection attempt. Probably nothing to do here except
> wait for another connection attempt.
>
> Another potential example: Nodes are stressed due to an attack. Or the MLD
> polling router is stressed. MLD queries or MLD responses either are not
> sent, or go astray. MLD cache entry Source Timer times out. Node is cut off
> from external traffic by router filter. Traffic potentially subsides. Cycle
> repeats.
>

All of these are the sorts of reasons why I created the Strict and
Relaxed Mitigation Modes, after Lorenzo expressed the concern about
tying the decision to perform ND for unicast address to the success of
MLD to discover the corresponding Solicited-Node multicast groups.

> Probably a one-liner could cover the concern.
>
> "Care should be taken to check the validity of the MLD cache before applying
> filtering, to avoid using unreliable MLD cache data, or race conditions."
>

While I understand the intent, I think it isn't actually possible to
check the validity of the MLD cache, in the sense that it isn't
possible to be absolutely sure that all Solicited-Node groups have
been discovered - there is no way to know absolutely how many groups
should be discovered to know when all of them have been.

I think what might be missing from the text is an explicit statement
that when in Strict Mitigation Mode, this method causes ND to depend
on the success of MLD in discovering the corresponding Solicited-Node
multicast groups, and that when a router is performing that discovery
for the first time, e.g., after boot, ND will fail during the MLD
discovery period. I'll add some text to that effect in the next couple
of days.



> 2) Why would a router track multicast membership when potentially it could
> also just track DAD queries directly when nodes join a link?
>
> The limitation of DAD is that DAD is only performed for unicast
> addresses, not anycast addresses. I think anycasts are usually going
> to be configured to provide a highly available service or host, not
> detecting them somehow and therefore dropping ND NSes for them would
> be quite a failure!
>
> DAD is certainly something that could be used to detect normal unicast
> addresses, and I think there was a ID about using them for that a few
> years ago. You're right, there is also the issue of how at router
> starting detects existing nodes/address that have already completed
> DAD. I can't remember if I read that ID, however I thought that not
> detecting anycast addresses was a fairly significant limitation of
> that method.
>
> Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and
> Fiber access architectures.  Based on the DAD signaling, the first-hop
> router stores in a Binding Table all known IPv6 addresses used on a
> point-to-multipoint domain (e.g., VLAN)."
>
> Couldn't such a cache also be used as a mechanism for defending against
> off-link NS exhaustion attacks?
>

Yes, although I think there are a couple of drawbacks with it. From
what I remember when I looked at it a while back, it firstly relies on
a hub-and-spoke forwarding topology, so couldn't be supported on a
standard peer-to-peer link-layer, and secondly, it seems not to
support having more than one DAD proxy on the link.

Of course, it won't work with anycast addresses because there is no
DAD for them.

Regards,
Mark.


> Obviously if the router joins the link after some nodes are already on link,
> then there's a potential for nodes to have already completed DAD before the
> router boots, so maybe a poll mechanism triggered by monitoring on-link ND
> requests might be appropriate. But then again, if the nodes send any
> off-link traffic via this router at all, they'll trigger ND to the router
> directly, so it's only a problem for normally silent nodes that receive
> inbound sessions. That could be mitigated by scheduling a simple 'ping' on
> end nodes acting as servers when they add a new router to their default
> router list (with appropriate delays/back off etc.).
>
> Thanks very much,
> Mark.
>
> --
> regards,
> RayH
>
> Ray Hunter (v6ops)
> 9 Feb 2016 14:50
>
>
> Mark Smith wrote:
> I have read this draft.
>
> At first glance it looks like a smart idea, because a defending router only
> has to track perhaps a thousand entries of state versus potentially having
> to store state for billions of "incomplete" queries.
>
> A couple of questions.
>
> 1) How often/when is the MLD cache updated/ timed out?
>
> My concern here is that you now have two caches interacting (mulitcast group
> membership and ND cache), and the timing of adding and deleting entries
> could cause race conditions. Some discussion of how the caches interact (or
> not) could be useful IMHO.
>
> 2) Why would a router track multicast membership when potentially it could
> also just track DAD queries directly when nodes join a link?
>
> Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and
> Fiber access architectures.  Based on the DAD signaling, the first-hop
> router stores in a Binding Table all known IPv6 addresses used on a
> point-to-multipoint domain (e.g., VLAN)."
>
> Couldn't such a cache also be used as a mechanism for defending against
> off-link NS exhaustion attacks?
>
>
> --
> regards,
> RayH


From nobody Mon Feb 22 03:13:01 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991081B307F for ; Mon, 22 Feb 2016 03:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9FVzzKX4VWG for ; Mon, 22 Feb 2016 03:12:58 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002: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 265FB1AC3EC for ; Mon, 22 Feb 2016 03:12:58 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id h129so115794283ywb.1 for ; Mon, 22 Feb 2016 03:12:58 -0800 (PST)
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-type; bh=OiVxBJerBZelyRvWB4mGGNngUIve1XHtGI1gSGLRbr4=; b=RwfEmI5D1jAoBSS3U5KU9BzjZifzaYkIiE1NWRbnkj0sebpvyWL6P+pl7At3Pf6k40 d7hipd0RXmqEIjrQyGSOKi28/0Q8PDbeD0dMKPwXUaGL/YcpSN4qb0odeWxU1iZ06xgK 3dyW2eapfAj2m/h/oR09Hkrs9SuQFQjJRfe4qxfTiQe4AOOYBxAUDcM4+hgukM9+CypQ y9Xk1mEVk38OQLhTZNF3zr9i1rfMNbUbViuvyv21v5PiTU71yxHtSfG/HLDHcb4OxRlV wQ0+BjGkNLg+jZeuRHijhQhMsKsS7QqSsXCmXBuaEbimrRDPuc20UXgy2qjE6kIsiZ2c QR3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OiVxBJerBZelyRvWB4mGGNngUIve1XHtGI1gSGLRbr4=; b=fqq1s4kgenHFizScJdjWSRfCzPUfNHlqH2SKE676Z+P13d4UsFrd/VJ4q6kvDg2ChB 4EeqcO3XRHwsjb4oIw2dANU4Pood2AvPtMYD7q3Cj9hkNujwLr4Th2YbgbG3i7eSg0EP 1Me9jzU61fUenohQYk7EZ7mStXHyRgKEoPbtotdBiBHigj59Cz+X8NiGuzK/03sxZoEq fj/icczNg572DeYVPcB/bjivWhgmI2tFWCBeHPTFMJqXwIaf1D8bmtZvQ/1jmsEpN0TV qExGkJPDp3kp93wIxgKS9HqEV6k+/4WyQVbyg8ieoDrIEvBz9ZPwyqgPOImcZ6xYVesr 1Ysg==
X-Gm-Message-State: AG10YOQ8iQpAelM/jWUz2TNB/Rf8xH0sfayf2bM2QXFEectsZFmRr4lRjZuXIQ475Hb5uu+hFdUmovsDcCfQhg==
X-Received: by 10.13.236.136 with SMTP id v130mr13877672ywe.308.1456139577450;  Mon, 22 Feb 2016 03:12:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.207.21 with HTTP; Mon, 22 Feb 2016 03:12:27 -0800 (PST)
In-Reply-To: <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org>
From: Mark Smith 
Date: Mon, 22 Feb 2016 22:12:27 +1100
Message-ID: 
To: Ole Troan 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 11:12:59 -0000

On 22 February 2016 at 21:20,   wrote:
>>> A subnet model with p2p links between router and host have none of these problems.
>>>
>>
>> So all of this is actually one of my main motivations behind:
>>
>> Indicating Link-Local Unicast Destinations are Off-Link
>> https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt
>
> in a p2p model link-local is constrained to the link. just like you expect it to be.
>

We're not talking about the same thing then.

>> Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with
>> multiple hubs), gives us the ability to preserve the address space and
>> routing aggregation advantages that a multi-access link provides, with
>> all attached hosts sharing a single /64 prefix, while inserting a
>> router between each and every host, with the router also being a
>> traffic inspection point between all other destinations, allowing I
>> think much easier implementation of protections such as SAVI, RA/DHCP
>> guards etc. etc.
>>
>> I think the two current gaps are:
>>
>> - the link-local assumption of on-link, and the inability to override
>> that assumption
>
> that's not a gap. you most definitely do not want link-locals to work across links.
>
>> - multicast propagation so that protocols such as Bonjour continue to
>> operate across all of the same link attached hosts
>
> protocols that can only operate on a single link are broken.
> multicast on p2p links are trivial.
>
>> I'm not at all against the idea of delegating prefixes to hosts.
>> However I think it should be an alternative option to multiple hosts
>> sharing a single /64, rather than a replacement. I can see some
>> networks might have a mix of both per-host/64 while others hosts still
>> share a /64, perhaps with a hub-and-spoke forwarding link-layer.
>
> in a p2p model you can use whatever addressing model suits you.
> (including single address to each endpoint on the link if you so desire.).
>
> Best regards,
> Ole


From nobody Mon Feb 22 04:39:57 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139EF1A1B2A for ; Mon, 22 Feb 2016 04:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level: 
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNdIdQoiS61t for ; Mon, 22 Feb 2016 04:39:54 -0800 (PST)
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 31B661A1B07 for ; Mon, 22 Feb 2016 04:39:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2545; q=dns/txt; s=iport; t=1456144794; x=1457354394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kADmAjmeEoz9oswWCaNIGUjOqUr7OdisgsHwEMbVHF8=; b=bh7ZWRS/WQkI1TDsWbwzKUEooDWW6+Cu7KZm3rUMMULR3j5uoDy1atLs CJkVPHpXhHtbpI+r4jAhnqAVC209RVW14Bz/TlUsQ7K9yYQItQ+Yc5cE+ HFedFNeZG62K02KKlxJfEczg8AIT0Jc6Z9iwrg0V8evezL37zx2AP3cC7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAgA3ActW/5pdJa1egzpSbQa6SwENg?= =?us-ascii?q?WYhhWwCgTo4FAEBAQEBAQFkJ4RBAQEBAwE6PwUHBAIBCBEEAQEfCQcyFAkIAgQ?= =?us-ascii?q?BDQUIiAoIDrdEAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKTIhvBZcHAYVWiACBY?= =?us-ascii?q?4RDiFSOSAEeAQFCggMZgUhqAYcyfQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,484,1449532800"; d="scan'208";a="240950382"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2016 12:39:53 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1MCdr81021797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 12:39:53 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 22 Feb 2016 06:39:51 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Mon, 22 Feb 2016 06:39:51 -0600
From: "Hemant Singh (shemant)" 
To: "otroan@employees.org" , Mark Smith 
Thread-Topic: [v6ops] p2p links without ND
Thread-Index: AQHRbOZUmY0YgiwNmk+VNMXlq9OMlJ83cM6AgACo3wCAAAF7AIAAFW2AgAAL1wCAAAOiAP//wAiw
Date: Mon, 22 Feb 2016 12:39:51 +0000
Message-ID: <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org>
In-Reply-To: <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org>
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: [10.82.214.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 12:39:56 -0000

Note, if the p2p link uses PPP, then there is already a keep-alive, so why =
use NUD on such a link?  Additionally, if both ends of the link are routers=
, use a /127 as specified in RFC6164.    I agree with all that Ole has said=
.   Also, please look at guidance in RFC 5942 for when to issue address res=
olution and what is on- vs. off-link.=20

Hemant

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of otroan@employees.o=
rg
Sent: Monday, February 22, 2016 5:20 AM
To: Mark Smith
Cc: v6ops list; Tore Anderson
Subject: Re: [v6ops] p2p links without ND

>> A subnet model with p2p links between router and host have none of these=
 problems.
>>=20
>=20
> So all of this is actually one of my main motivations behind:
>=20
> Indicating Link-Local Unicast Destinations are Off-Link=20
> https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

in a p2p model link-local is constrained to the link. just like you expect =
it to be.

> Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with=20
> multiple hubs), gives us the ability to preserve the address space and=20
> routing aggregation advantages that a multi-access link provides, with=20
> all attached hosts sharing a single /64 prefix, while inserting a=20
> router between each and every host, with the router also being a=20
> traffic inspection point between all other destinations, allowing I=20
> think much easier implementation of protections such as SAVI, RA/DHCP=20
> guards etc. etc.
>=20
> I think the two current gaps are:
>=20
> - the link-local assumption of on-link, and the inability to override=20
> that assumption

that's not a gap. you most definitely do not want link-locals to work acros=
s links.

> - multicast propagation so that protocols such as Bonjour continue to=20
> operate across all of the same link attached hosts

protocols that can only operate on a single link are broken.
multicast on p2p links are trivial.

> I'm not at all against the idea of delegating prefixes to hosts.
> However I think it should be an alternative option to multiple hosts=20
> sharing a single /64, rather than a replacement. I can see some=20
> networks might have a mix of both per-host/64 while others hosts still=20
> share a /64, perhaps with a hub-and-spoke forwarding link-layer.

in a p2p model you can use whatever addressing model suits you.
(including single address to each endpoint on the link if you so desire.).

Best regards,
Ole


From nobody Mon Feb 22 05:37:25 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6411A913F for ; Mon, 22 Feb 2016 05:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jht5F2Q0OG97 for ; Mon, 22 Feb 2016 05:37:21 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C658D1A90DF for ; Mon, 22 Feb 2016 05:37:20 -0800 (PST)
Received: from [2a02:c0:2:4:1194:17:0:1006] (port=34042 helo=envy.w5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aXqft-0004M2-6i; Mon, 22 Feb 2016 14:37:17 +0100
Date: Mon, 22 Feb 2016 14:37:16 +0100
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20160222143716.06dd5734@envy.w5.y.home>
In-Reply-To: <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 13:37:23 -0000

* otroan@employees.org

> > =C2=ABp2p links without ND=C2=BB sounds like a rather shoddy implementa=
tion to
> > me. Even though you won't need ND to discover link-layer addreses on
> > p2p links, you're still going to need it for DAD, NUD, SLAAC,
> > default router discovery, more-specific routes discovery, RDNSS
> > discovery, etc. etc. etc. =20
>=20
> at least with regards to the implementations I'm familiar with, that
> means no ND address resolution. address resolution on a link without
> L2 addresses is in any case meaningless. by implication that also
> means we don't do NUD.

The subject of this thread says just "ND". That's much more than
address resolution. If p2p links didn't support ND full stop, then IPv6
wouldn't work in 3GPP networks as currently specified for example (they
require SLAAC).

Anyway. Address resolution might not be relevant on p2p links, but
that's not all NS/NA can be used for. The NA target link-layer _option_
is after all not mandatory on link layers that don't have addresses.

DAD is another use case that comes to mind; detecting that both sides
of the link are attempting to use, say, fe80::1, seems as useful to me
on a true p2p link as it is on an Ethernet link. But how can one do DAD
without NA?

I'll readily admit that omitting support for NA on p2p links is
unlikely to cause any major operational problems - I just haven't seen
any text in any RFC that is permitting implementers to do just that.
Unless you can point me what I've been missing, it seems rather sloppy
to me to cut that particular corner. It can't possibly be very
difficult to support, can it?

Tore


From nobody Mon Feb 22 06:35:11 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6E1B32ED for ; Mon, 22 Feb 2016 06:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BNvL1G_dUjr for ; Mon, 22 Feb 2016 06:35:07 -0800 (PST)
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 EBF861B32DF for ; Mon, 22 Feb 2016 06:35:06 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aXrZn-0000G0C; Mon, 22 Feb 2016 15:35:03 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <20160222143716.06dd5734@envy.w5.y.home> 
In-reply-to: Your message of "Mon, 22 Feb 2016 14:37:16 +0100 ." <20160222143716.06dd5734@envy.w5.y.home> 
Date: Mon, 22 Feb 2016 15:35:02 +0100
Archived-At: 
Cc: Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 14:35:09 -0000

In your letter dated Mon, 22 Feb 2016 14:37:16 +0100 you wrote:
> I'll readily admit that omitting support for NA on p2p links is
> unlikely to cause any major operational problems - I just haven't
> seen any text in any RFC that is permitting implementers to do just
> that.  Unless you can point me what I've been missing, it seems
> rather sloppy to me to cut that particular corner. It can't possibly
> be very difficult to support, can it?

Like I said, it seems to be operation practice to not do NS/NA on p2p links.

Anyone have a difference experience?


From nobody Mon Feb 22 06:38:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF94C1B335D for ; Mon, 22 Feb 2016 06:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level: 
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed5c6P98Kj2W for ; Mon, 22 Feb 2016 06:38:11 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 E4D021B3351 for ; Mon, 22 Feb 2016 06:38:10 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E730262C7F for ; Mon, 22 Feb 2016 15:38:08 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.space.net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 81C6260B93 for ; Mon, 22 Feb 2016 15:38:08 +0100 (CET)
Received: (qmail 20848 invoked by uid 1007); 22 Feb 2016 15:38:08 +0100
Date: Mon, 22 Feb 2016 15:38:08 +0100
From: Gert Doering 
To: Tore Anderson 
Message-ID: <20160222143808.GT21153@Space.Net>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <20160222143716.06dd5734@envy.w5.y.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160222143716.06dd5734@envy.w5.y.home>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 14:38:12 -0000

Hi,

On Mon, Feb 22, 2016 at 02:37:16PM +0100, Tore Anderson wrote:
> DAD is another use case that comes to mind; detecting that both sides
> of the link are attempting to use, say, fe80::1, seems as useful to me
> on a true p2p link as it is on an Ethernet link. But how can one do DAD
> without NA?

PPP does DAD (for fe80:: at least) by means of IPv6CP.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Mon Feb 22 06:48:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F7D1B33B9 for ; Mon, 22 Feb 2016 06:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.907
X-Spam-Level: 
X-Spam-Status: No, score=-13.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hJJaWQBdBdh for ; Mon, 22 Feb 2016 06:48:34 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EAE1B33B8 for ; Mon, 22 Feb 2016 06:48:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=575; q=dns/txt; s=iport; t=1456152514; x=1457362114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=meJDHVE/i6f/qxmrJRE/kIP4U2Ef9bRSpSQh6GYWAHE=; b=BkBJTTIPwasF/RodqhDGxEH14o5FpBlZMkaXJnnLOhumRHYMe+owqOQY ipF7rWmkq+lk6LGniJX+OUu7JoTJyJ0YZcmI4rogrVwNmRRQ9rEG1aMud BnsnNXaeu9RCaOuZwvqLtlbbgxs96sqroXZnjf1pF4ADs1UVPlwEIPicp Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgB1H8tW/5tdJa1egzqBPwazK4ciA?= =?us-ascii?q?Q2BZoYNAoE8OBQBAQEBAQEBZCeEQQEBAQQ6PwwEAgEIEQQBAR8JBzIUCQgCBAE?= =?us-ascii?q?NBQiIE7g5AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYpMiG8BBJcHAY1WjnqOSAEeA?= =?us-ascii?q?QFCg2RqhzN9AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,484,1449532800"; d="scan'208";a="75726048"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2016 14:48:33 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1MEmXDo014071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 14:48:33 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 22 Feb 2016 08:48:32 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Mon, 22 Feb 2016 08:48:32 -0600
From: "Hemant Singh (shemant)" 
To: Gert Doering , Tore Anderson 
Thread-Topic: [v6ops] p2p links without ND
Thread-Index: AQHRbOZUmY0YgiwNmk+VNMXlq9OMlJ83cM6AgACo3wCAAF1kAIAAEQIA//+c4mA=
Date: Mon, 22 Feb 2016 14:48:32 +0000
Message-ID: <0e93bd725b2747d4a8c63e25b5888160@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <20160222143716.06dd5734@envy.w5.y.home> <20160222143808.GT21153@Space.Net>
In-Reply-To: <20160222143808.GT21153@Space.Net>
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: [10.131.71.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 14:48:35 -0000

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering
Sent: Monday, February 22, 2016 9:38 AM
To: Tore Anderson
Cc: v6ops list
Subject: Re: [v6ops] p2p links without ND


>PPP does DAD (for fe80:: at least) by means of IPv6CP.

DAD and NS/NA are twins because soon as DAD is used, the link has on-link n=
odes and NS/NA is also used.   If the desired behavior for p2p is to not us=
e NS/NA, then each end of the p2p link should be configured to be off-link =
to each other and thus no DAD nor NS/NA is used.

Hemant


From nobody Mon Feb 22 07:00:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47CD1B3476 for ; Mon, 22 Feb 2016 07:00:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Level: 
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v8O4AxyjHoM for ; Mon, 22 Feb 2016 07:00:46 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 237D91B3470 for ; Mon, 22 Feb 2016 07:00:46 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7B96FA4; Mon, 22 Feb 2016 16:00:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1456153243; bh=gyHAEr5FOp7oAYoZJ0/G3tAm9z+1chtU4onXpRh8ey4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wNEsC3Fi7thULfZThR1bjVHSnKu5JW+9ILgAZ3g+XOHqLsK33Tj4r9C+ig1/dS1i2 q9U9FCzPEZ3TT/rZC2ForLIwmx5c7xmK1OKx6mfxhgplnYU0xRTJT/BsJqt9rvEH6E hQGgTEBdL7JjkfwjOkz5I96hU/4D0XaY/0A6dPRw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 52270A1; Mon, 22 Feb 2016 16:00:43 +0100 (CET)
Date: Mon, 22 Feb 2016 16:00:43 +0100 (CET)
From: Mikael Abrahamsson 
To: Tore Anderson 
In-Reply-To: <20160222143716.06dd5734@envy.w5.y.home>
Message-ID: 
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <20160222143716.06dd5734@envy.w5.y.home>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 15:00:47 -0000

On Mon, 22 Feb 2016, Tore Anderson wrote:

> DAD is another use case that comes to mind; detecting that both sides of 
> the link are attempting to use, say, fe80::1, seems as useful to me on a 
> true p2p link as it is on an Ethernet link. But how can one do DAD 
> without NA?

Apart from when you're looping a POS-interface and DAD kicks in and 
disables the IPv6 part of the interface. Been there, done that.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Feb 22 07:23:22 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57B1B35A6 for ; Mon, 22 Feb 2016 07:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.983
X-Spam-Level: 
X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS26ZxsyOn5p for ; Mon, 22 Feb 2016 07:23:15 -0800 (PST)
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 9DC371B35B6 for ; Mon, 22 Feb 2016 07:22:08 -0800 (PST)
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 u1MFM61a000338 for ; Mon, 22 Feb 2016 16:22:06 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2E60720D3B1 for ; Mon, 22 Feb 2016 16:22:12 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1D10B202554 for ; Mon, 22 Feb 2016 16:22:12 +0100 (CET)
Received: from [132.166.84.18] ([132.166.84.18]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1MFM6Gb019665 for ; Mon, 22 Feb 2016 16:22:06 +0100
To: v6ops@ietf.org
References:  <20160221225835.779c0de7@envy.w5.y.home> 
From: Alexandre Petrescu 
Message-ID: <56CB279D.4080702@gmail.com>
Date: Mon, 22 Feb 2016 16:22:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 15:23:21 -0000

Le 21/02/2016 23:34, Philip Homburg a écrit :
> In your letter dated Sun, 21 Feb 2016 22:58:35 +0100 you wrote:
>> p2p links without ND sounds like a rather shoddy implementation to
>> me. Even though you won't need ND to discover link-layer addreses
>> on p2p links, you're still going to need it for DAD, NUD, SLAAC,
>> default router discovery, more-specific routes discovery, RDNSS
>> discovery, etc.  etc. etc.
>>
>>  From what I can tell, RFC 4861 doesn't in any way exempt p2p links
>> from supporting ND (see excerpt below). What exactly gave people
>> this idea?
>
> So far I haven't seen any p2p link where the remote end responded
> to a neighbor solicitation. But maybe I'm just unlucky.

In some cellular links on which I work the UE does send NS and the 
router soes seem to reply with RA.  (not sure the RA is the right thing 
to answer to an NS, and there is no identifier in these two messages to 
correlate them, like in DHCP a transaction ID).

Many recent 4G USB dongles feature real MAC addresses allocated by IEEE 
and dongle manufacturer (i.e. guaranteed unique, not random as in USBnet).

Alex

>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Mon Feb 22 07:36:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6B81B36F0 for ; Mon, 22 Feb 2016 07:36:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.906
X-Spam-Level: 
X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad7gITqmp7UV for ; Mon, 22 Feb 2016 07:36:47 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F1C1A1BCB for ; Mon, 22 Feb 2016 07:36:46 -0800 (PST)
Received: from [2a02:2121:4f:f231:0:15:4490:201] (port=32884 helo=envy.w5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aXsXT-0007Po-Mz; Mon, 22 Feb 2016 16:36:43 +0100
Date: Mon, 22 Feb 2016 16:36:41 +0100
From: Tore Anderson 
To: Philip Homburg 
Message-ID: <20160222163641.2acfe973@envy.w5.y.home>
In-Reply-To: 
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <20160222143716.06dd5734@envy.w5.y.home> 
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 15:36:49 -0000

* Philip Homburg

> In your letter dated Mon, 22 Feb 2016 14:37:16 +0100 you wrote:
> > I'll readily admit that omitting support for NA on p2p links is
> > unlikely to cause any major operational problems - I just haven't
> > seen any text in any RFC that is permitting implementers to do just
> > that.  Unless you can point me what I've been missing, it seems
> > rather sloppy to me to cut that particular corner. It can't possibly
> > be very difficult to support, can it?  
> 
> Like I said, it seems to be operation practice to not do NS/NA on p2p
> links.

Well, NS and NA are different things, so I'll respond separately:

- Regarding NS: It makes perfect sense that you'd not see many NS
  packets on a p2p link, as there's not any link-layer addresses that
  need resolving. However I'd expect to see them as a result of DAD
  taking place, and I can imagine that NUD could be useful as well.

- Regarding NA: If an IPv6 node receives a valid NS on a p2p link, I do
  not see any reason why it should be ignored. To the best of my
  knowledge, no IPv6 standard states that a node is permitted to do so.
  Until I see differently, I'd say that an implementation that doesn't
  bother to answer NS with NA do not fully comply to the standards.
  Whether or not the interface is p2p or not makes no difference.

> Anyone have a difference experience?

Well, I just tested the only p2p link type I use daily, which is 3GPP
mobile broadband. My provider is Telenor - I think they're using
Ericsson GGSNs. All of my NSes to the GGSN's LLA were answered with NAs
just fine, so yes indeed, I do have a different experience than you.

That said, I am painfully aware that 3GPP modems are notorious for
doing all sorts of crazy stuff (ref. the recent RFC7278 thread) - but I
have reason to believe the NAs in this case are actually coming from
the GGSN and not being generated in the modem firmware:

First, I made sure to use a direct PPP connection to the serial device
so my Linux host saw a true p2p interface. No fake Ethernet or anything
like that.

Second, I observed the NS->NA delay: it was stable at around ~20-25 ms
while the link was idle, and jumped up to ~100-125 ms while I was
downloading some large files.

Third, the different NS->NA delays while the link was idle and loaded
corresponded perfectly to the RTTs in a ping6 session I had going to a
GUA in Telenor's network: 20-25 ms while idle, 100-125 ms under load.

Tore


From nobody Mon Feb 22 10:58:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239D91A1B15 for ; Mon, 22 Feb 2016 10:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYzfGekA4KnW for ; Mon, 22 Feb 2016 10:58:33 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 B5F121A00A0 for ; Mon, 22 Feb 2016 10:58:33 -0800 (PST)
Received: by mail-ig0-x231.google.com with SMTP id 5so88739299igt.0 for ; Mon, 22 Feb 2016 10:58:33 -0800 (PST)
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=fKjiwOBiYcUdlmbyvoTDxQM03G/4BkwidAySyaZMHv4=; b=y6mt9KC3MBe9ggBWRCGl7SIoyOEysfrS8P73yCgzHcCkh2Tr0iPhgHYufLk7sU3ReB 7TXG+2P/gClJ1gdB4Js9SiMJ0mG4p/P35DmCasDu4RV9KX1M1NZBRzieVwDC5RjnPZCA IN72M+GNBnBqYGIjedyCPZ8S6flNydEH71VhzDZa9WgdJdU5u/WbsTXYcwxueyzcnFVK TPx6R0YOriQbhbsjuU6qZUhQaIjD9bCcIb7aCh5AV0fwAFhFtdvTi3qaA6iIyrzCt+IE /KRwoHkOY6ITw12VVna3aV0w07OxPgHTNTun64HmOELC9y8Xfq/nGpiXBazbeB1PQetf /2wA==
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=fKjiwOBiYcUdlmbyvoTDxQM03G/4BkwidAySyaZMHv4=; b=DQOxwTX04MAC8unfXqKjcfuYZACmlvIFzprOeNkHEmGsxQUrED6K5tGiEsjfEmz8ks QjydA5ytfI7JFDLpeJnVgfWSlV4PsAWxNYerTAe8nmSudttlsxC9fxmzYSlLkf2WrHlh InldIHYaqmm3uzA2bPX4gfO7HQKmOE1mZufoJ93Sd8RdjNSI3SPXaonDBqIMXNzcBtUv nUbItAqjZ93+v8qogWMyYI/C7e/IQyiYmkT2CF0dnua8VkDeA26X3q89nisNAY4jncd6 109ovMXdzdouwPZtA2CiScKJ1NBQNJrnetGndiYPmbRt0f9vwElMz0+7Vodsm2CYnF5+ rHYQ==
X-Gm-Message-State: AG10YOR7FcgidrORpJN4i8RIvmfLR8gnYOmvJUkmn67nFOXD17+Wx/VimK1r92DK+NUtkFgUD7GYXrmwKLZ7xA==
MIME-Version: 1.0
X-Received: by 10.50.150.106 with SMTP id uh10mr11866004igb.41.1456167513150;  Mon, 22 Feb 2016 10:58:33 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Mon, 22 Feb 2016 10:58:32 -0800 (PST)
In-Reply-To: 
References:  <20160221212947.GJ21153@Space.Net> 
Date: Mon, 22 Feb 2016 10:58:32 -0800
X-Google-Sender-Auth: F6dwxP77DVL0tdvnfMeKksp_WZA
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Mark Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 18:58:35 -0000

At Mon, 22 Feb 2016 08:43:23 +1100,
Mark Smith  wrote:

> > What happens if you send a packet towards your default gateway and
> > the destination address isn't presend "behind the device at the other
> > end"?
> >
> > It will either be sent somewhere onward, or get dropped.
> >
> > Jinmei-san pointed to the RFC that explains that it MUST be dropped if
> > the other end points the address back towards the same link
>
> "One specific case in which a Destination Unreachable message is sent with
> a code 3 is in response to a packet received by a router from a
> point-to-point link, destined to an address within a subnet assigned to
> that same link (other than one of the receiving router's own addresses). In
> such a case, the packet MUST NOT be forwarded back onto the arrival link."
>
> What if the receiving router doesn't know about the "subnet assigned to
> that same link"?

As I said before, this doesn't matter for the BSD implementation since
it doesn't check this condition: so in this case the packet would just
be dropped and an ICMPv6 destination error would be returned.

Yes, that's not fully compliant to what the RFC says.  But I guess
other implementations may be behaving more or less similarly in
practice.  It seems to me that some other posts in this thread
(e.g. https://mailarchive.ietf.org/arch/msg/v6ops/L_MEQZ_FgPG94c4DLGzSmZ2nISM)
suggest that may actually be the more common practice.

--
JINMEI, Tatuya


From nobody Mon Feb 22 11:27:35 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2831A9141 for ; Mon, 22 Feb 2016 11:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U9I2R5eD5yd for ; Mon, 22 Feb 2016 11:27:32 -0800 (PST)
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 3146C1A6FBC for ; Mon, 22 Feb 2016 11:27:32 -0800 (PST)
Received: by mail-vk0-x22b.google.com with SMTP id c3so139637295vkb.3 for ; Mon, 22 Feb 2016 11:27:32 -0800 (PST)
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:content-type; bh=GD3jawEo/nEMOBi5kO6mlQ6KbXLyfOe0Y1eqir66w0s=; b=ENcXzQf+yc6cL+zHE9tQs/uDWllFRvlLzFHNi76eem0bOCQee33OH40Ms6hLTpda51 83RrfHKWzHpX0gyh98/HoxRfPvgMA6h7i6Z1wPzaqF13cia8trFbzFqkkHEm1UE/KYgV qW2BmYA8eBsKceCZxebBH69AVTbwrRKPlCSo1FmweRw7ACR1RjFOo+i26cdcz1iNMwnf w5G4M3MgEoEsqcVHgtG1JAg1bW7KNDnDM0YaBUGWCCma0g++jrw2WFtlOFyKQE8iyq6b 8vsByOztOmh29IajDr+3kK1tU1gqJOx+8HOJ6R8f9Ug/q7RHFzZQk40nONWXajxw0xtH PLhQ==
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-type; bh=GD3jawEo/nEMOBi5kO6mlQ6KbXLyfOe0Y1eqir66w0s=; b=cOr+GtyFSkVe3CpBbFkOP1SL3aY9eW6nnqgtSQj+YbqhYMfM1F+HS/hPpnkEvsd89G fh2nVOEzZNEGEEu4i+DbMZISphecP5cmv75322hbvkXn92Mg672BAIMCLAW6fpSO9Fz0 At8VkZUk8PBHKSNcuFlujkhmHgV5gDcoalW3ZLOylItDxION/AdEz0O5gz+qRx+3oex1 dheV1KicyEUcMbuw1lle5EYPWCVCl7bOm7WKhCfqS/Ry9cB2zhBmB/EQ6pecJ1+lKVdP iOdlCq/GWE66H2ojcL9Dszsi7DDlMxITiXwEZqdGIIfSmbJKNKOGq/3mNF7QgfQxskQz 7Twg==
X-Gm-Message-State: AG10YORNGjZGSLetJE1C66TL2jtUF1N3iI+4bXV6xDbntwx/91IILxxl7uHclpwBGOEVqr6iSeKysGdtDqqJQw==
MIME-Version: 1.0
X-Received: by 10.31.58.83 with SMTP id h80mr25073167vka.149.1456169251309; Mon, 22 Feb 2016 11:27:31 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Mon, 22 Feb 2016 11:27:31 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Mon, 22 Feb 2016 11:27:31 -0800 (PST)
In-Reply-To: <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org> <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com>
Date: Tue, 23 Feb 2016 06:27:31 +1100
Message-ID: 
From: Mark Smith 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=001a114389d4f50e7f052c60d20d
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 19:27:34 -0000

--001a114389d4f50e7f052c60d20d
Content-Type: text/plain; charset=UTF-8

On 22 Feb 2016 11:39 PM, "Hemant Singh (shemant)"  wrote:
>
> Note, if the p2p link uses PPP, then there is already a keep-alive, so
why use NUD on such a link?  Additionally, if both ends of the link are
routers, use a /127 as specified in RFC6164.

Probably can't (/127s work reliably in RAs?) and don't want to in
residential broadband over PPPoE - customer being able to plug a PC
directly on avoids forcing them to buy a router and is useful for
troubleshooting.

I've helped enable 100s of p2p /64s because of this requirement, and since
.au is a BYO CPE market, I desire automated robustness via protocols rather
than manual configuration, attention to detail and technical competence
from the person at the other end of the link.

How many of those PPPoE links are vulnerable to ping-pongs because of no ND
of the link? I don't know, but since I don't control the CPE, I can't
control it either.

ISPs can only rely on robustness measures on their end of the link. Since
/127s and RFC4333 measures are far end/customer end mitigations they're not
as good as local end ones.

I'd much rather have my end perform ND, not send the packet if there is no
address present, and deal with the ND cache DoS possibility - because on my
end I can, reliably.

>   I agree with all that Ole has said.   Also, please look at guidance in
RFC 5942 for when to issue address resolution and what is on- vs. off-link.
>
> Hemant
>
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
otroan@employees.org
> Sent: Monday, February 22, 2016 5:20 AM
> To: Mark Smith
> Cc: v6ops list; Tore Anderson
> Subject: Re: [v6ops] p2p links without ND
>
> >> A subnet model with p2p links between router and host have none of
these problems.
> >>
> >
> > So all of this is actually one of my main motivations behind:
> >
> > Indicating Link-Local Unicast Destinations are Off-Link
> > https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt
>
> in a p2p model link-local is constrained to the link. just like you
expect it to be.
>
> > Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with
> > multiple hubs), gives us the ability to preserve the address space and
> > routing aggregation advantages that a multi-access link provides, with
> > all attached hosts sharing a single /64 prefix, while inserting a
> > router between each and every host, with the router also being a
> > traffic inspection point between all other destinations, allowing I
> > think much easier implementation of protections such as SAVI, RA/DHCP
> > guards etc. etc.
> >
> > I think the two current gaps are:
> >
> > - the link-local assumption of on-link, and the inability to override
> > that assumption
>
> that's not a gap. you most definitely do not want link-locals to work
across links.
>
> > - multicast propagation so that protocols such as Bonjour continue to
> > operate across all of the same link attached hosts
>
> protocols that can only operate on a single link are broken.
> multicast on p2p links are trivial.
>
> > I'm not at all against the idea of delegating prefixes to hosts.
> > However I think it should be an alternative option to multiple hosts
> > sharing a single /64, rather than a replacement. I can see some
> > networks might have a mix of both per-host/64 while others hosts still
> > share a /64, perhaps with a hub-and-spoke forwarding link-layer.
>
> in a p2p model you can use whatever addressing model suits you.
> (including single address to each endpoint on the link if you so desire.).
>
> Best regards,
> Ole

--001a114389d4f50e7f052c60d20d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 22 Feb 2016 11:39 PM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

>

> Note, if the p2p link uses PPP, then there is already a keep-alive, so=
 why use NUD on such a link?=C2=A0 Additionally, if both ends of the link a=
re routers, use a /127 as specified in RFC6164.=C2=A0


Probably can't (/127s work reliably in RAs?) and don'=
;t want to in residential broadband over PPPoE - customer being able to plu=
g a PC directly on avoids forcing them to buy a router and is useful for tr=
oubleshooting.


I've helped enable 100s of p2p /64s because of this requ=
irement, and since .au is a BYO CPE market, I desire automated robustness v=
ia protocols rather than manual configuration, attention to detail and tech=
nical competence from the person at the other end of the link.


How many of those PPPoE links are vulnerable to ping-pongs b=
ecause of no ND of the link? I don't know, but since I don't contro=
l the CPE, I can't control it either.


ISPs can only rely on robustness measures on their end of th=
e link. Since /127s and RFC4333 measures are far end/customer end mitigatio=
ns they're not as good as local end ones.


I'd much rather have my end perform ND, not send the pac=
ket if there is no address present, and deal with the ND cache DoS possibil=
ity - because on my end I can, reliably.


> =C2=A0 I agree with all that Ole has said.=C2=A0 =C2=A0=
Also, please look at guidance in RFC 5942 for when to issue address resolut=
ion and what is on- vs. off-link.

>

> Hemant

>

> -----Original Message-----

> From: v6ops [mailto:v6ops-bo=
unces@ietf.org] On Behalf Of ot=
roan@employees.org

> Sent: Monday, February 22, 2016 5:20 AM

> To: Mark Smith

> Cc: v6ops list; Tore Anderson

> Subject: Re: [v6ops] p2p links without ND

>

> >> A subnet model with p2p links between router and host have no=
ne of these problems.

> >>

> >

> > So all of this is actually one of my main motivations behind:

> >

> > Indicating Link-Local Unicast Destinations are Off-Link

> > https://tools.ietf.org/id/draft-smith-6man-link-locals-of=
f-link-00.txt

>

> in a p2p model link-local is constrained to the link. just like you ex=
pect it to be.

>

> > Moving to a hub-and-spoke forwarding model at layer 2 (perhaps wi=
th

> > multiple hubs), gives us the ability to preserve the address spac=
e and

> > routing aggregation advantages that a multi-access link provides,=
 with

> > all attached hosts sharing a single /64 prefix, while inserting a=


> > router between each and every host, with the router also being a<=
br>
> > traffic inspection point between all other destinations, allowing=
 I

> > think much easier implementation of protections such as SAVI, RA/=
DHCP

> > guards etc. etc.

> >

> > I think the two current gaps are:

> >

> > - the link-local assumption of on-link, and the inability to over=
ride

> > that assumption

>

> that's not a gap. you most definitely do not want link-locals to w=
ork across links.

>

> > - multicast propagation so that protocols such as Bonjour continu=
e to

> > operate across all of the same link attached hosts

>

> protocols that can only operate on a single link are broken.

> multicast on p2p links are trivial.

>

> > I'm not at all against the idea of delegating prefixes to hos=
ts.

> > However I think it should be an alternative option to multiple ho=
sts

> > sharing a single /64, rather than a replacement. I can see some
> > networks might have a mix of both per-host/64 while others hosts =
still

> > share a /64, perhaps with a hub-and-spoke forwarding link-layer.<=
br>
>

> in a p2p model you can use whatever addressing model suits you.

> (including single address to each endpoint on the link if you so desir=
e.).

>

> Best regards,

> Ole




--001a114389d4f50e7f052c60d20d--


From nobody Mon Feb 22 11:43:13 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C31A00E9 for ; Mon, 22 Feb 2016 11:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level: 
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oypE3OP0SmJ9 for ; Mon, 22 Feb 2016 11:43:10 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945251A008F for ; Mon, 22 Feb 2016 11:43:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1134; q=dns/txt; s=iport; t=1456170190; x=1457379790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OGpoBZv0XnAhNa3SG/lyY1qsUdY+fuCB9EmDb9cgDT4=; b=l3QDkJjBPYgsJx6ahoMOcth1Na0/12Kx0i8G4mFGzf2Z6QnbTqpOVpnP 6gs7I/+8IBDcyADPtPFns4bm0GBZ1idjjRpcejkeFOl3voFAXXV09Bgke VqdvUIfWPmCgZTTJ7rF1pBe0SN4p4hmyvhjRh8fH+xEh9oT78jqrOzYon 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgBjZMtW/5tdJa1egzqBPwa6TgENg?= =?us-ascii?q?WaGDQIcgSg4FAEBAQEBAQFkJ4RBAQEBBCMRRRACAQgRBAEBAwIjAwICAh8RFAE?= =?us-ascii?q?ICAIEDgUIh34DEqsKigoNhEoBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4lRgjqEe?= =?us-ascii?q?4E6AQSXBwGLaoFsjnqHBYdDAR4BAUKCAxmBSGqHPH0BAQE?=
X-IronPort-AV: E=Sophos;i="5.22,485,1449532800"; d="scan'208";a="73603347"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2016 19:43:09 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1MJh9TI017813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 19:43:09 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 22 Feb 2016 13:43:09 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Mon, 22 Feb 2016 13:43:08 -0600
From: "Hemant Singh (shemant)" 
To: Mark Smith 
Thread-Topic: [v6ops] p2p links without ND
Thread-Index: AQHRbOZUmY0YgiwNmk+VNMXlq9OMlJ83cM6AgACo3wCAAAF7AIAAFW2AgAAL1wCAAAOiAP//wAiwgADY14D//56ToA==
Date: Mon, 22 Feb 2016 19:43:08 +0000
Message-ID: <44eb12cca9714424b087c97628f3d51b@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org> <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.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: [10.131.71.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: v6ops list , Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 19:43:12 -0000

DQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0gDQpTZW50
OiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDI6MjggUE0NClRvOiBIZW1hbnQgU2luZ2ggKHNo
ZW1hbnQpDQpDYzogVG9yZSBBbmRlcnNvbjsgdjZvcHMgbGlzdDsgb3Ryb2FuQGVtcGxveWVlcy5v
cmcNClN1YmplY3Q6IFJFOiBbdjZvcHNdIHAycCBsaW5rcyB3aXRob3V0IE5EDQoNCj5Qcm9iYWJs
eSBjYW4ndCAoLzEyN3Mgd29yayByZWxpYWJseSBpbiBSQXM/KSBhbmQgZG9uJ3Qgd2FudCB0byBp
biByZXNpZGVudGlhbCBicm9hZGJhbmQgb3ZlciBQUFBvRSAtIGN1c3RvbWVyIGJlaW5nIGFibGUg
dG8gcGx1ZyBhIFBDIGRpcmVjdGx5IG9uIGF2b2lkcyBmb3JjaW5nIHRoZW0gdG8gYnV5IGEgPnJv
dXRlciBhbmQgaXMgdXNlZnVsIGZvciB0cm91Ymxlc2hvb3RpbmcuDQoNCkkgaGF2ZSBhbHJlYWR5
IHNhaWQgaWYgYm90aCBlbmRzIG9mIGEgcDJwIGxpbmsgYXJlIHJvdXRlcnMsIHRoZW4gUkZDNjE2
NCBhbGxvd3MgdXNlIG9mIGEgLzEyNy4gIE9mIGNvdXJzZSwgdGhlIC8xMjcgaXMgbm90IGNvbmZp
Z3VyZWQgdXNpbmcgYSBwcmVmaXggZnJvbSB0aGUgUkEgaWYgdGhhdCBpcyB3aGF0IHlvdSBtZWFu
dCBhYm92ZS4gICBUaGUgLzEyNyBpcyBjb25maWd1cmVkIG1hbnVhbGx5IGF0IGVhY2ggZW5kIHNp
bmNlIHRoZSBTdWJuZXQtUm91dGVyIGFueWNhc3QgYWRkcmVzcyBjb25mbGljdHMgd2l0aCB0aGUg
LzEyNy4gIA0KDQpSRkM2MTY0IGRvZXMgbm90IGNvdmVyIHJvdXRlciB0byBob3N0IG9yIGhvc3Qg
dG8gaG9zdCBwMnAgbGlua3MuDQoNCkhlbWFudA0K


From nobody Mon Feb 22 11:55:00 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AEC1A01F4 for ; Mon, 22 Feb 2016 11:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cqaz2bz2r84 for ; Mon, 22 Feb 2016 11:54:56 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7C1681A036E for ; Mon, 22 Feb 2016 11:54:53 -0800 (PST)
Received: (qmail 96264 invoked from network); 22 Feb 2016 19:54:51 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Feb 2016 19:54:51 -0000
Date: Mon, 22 Feb 2016 20:54:51 +0100 (CET)
Message-Id: <20160222.205451.74698778.sthaug@nethelp.no>
To: markzzzsmith@gmail.com
From: sthaug@nethelp.no
In-Reply-To: 
References: <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org> <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com> 
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org, tore@fud.no
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 19:54:58 -0000

> ISPs can only rely on robustness measures on their end of the link. Since
> /127s and RFC4333 measures are far end/customer end mitigations they're not
> as good as local end ones.

To me a /127 is suitable for "real" p2p links (SDH/SONET and similar),
and is not really a consumer technology at all.

Some years ago I personally saw the amazing loop that could be created
with a /64 being used on an STM-256/OC-768 link between a Juniper and
a Cisco router. We quickly reconfigured to a /127. Problem solved. (For
the curious: The Gathering 2010...)

Steinar Haug, AS2116


From nobody Mon Feb 22 13:23:12 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69EC1A88EA for ; Mon, 22 Feb 2016 13:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jwC2sQ2rcnB for ; Mon, 22 Feb 2016 13:23:10 -0800 (PST)
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 349C71A88C2 for ; Mon, 22 Feb 2016 13:23:10 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id q63so98870710pfb.0 for ; Mon, 22 Feb 2016 13:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Oazc619OiPcTrWIjjvO42UDk2CzxCIB4aDrxIzpdCtI=; b=kIkMsES0VmkUCjT2hnBpR9fzp1vC2fG3OzDW3ZWKq7P3PExZJhlrTNmGLRfHKG7Y/G Uu9I5BXsYWlCbAmBN8urYVEyyUMVjmDdJL0Veua6tus2XbeF7r6UBfW/8ZmxXrm0IcVB 0Tx58qplstJi5l1U0KIWFwdQJcLQJ4aJF4lFThQYp343bO8OIp+HUgAGrrYGKHgTzRsx XwEO8FS1FgesMNI7iTQOHKQmU5VR4GFcdbRrufB3pXwfqjWtodhbaPmOPEWf7s5dYfQ8 0Wjhn8TIx3cxK60zQ4TsxC2qhGvvdXW4i/n5//UzkZBs9bQNYQ0fGGeX9v87fLeQAwTt 6OXQ==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Oazc619OiPcTrWIjjvO42UDk2CzxCIB4aDrxIzpdCtI=; b=GzLV+9wxAad4IiWyxizmGCcZXKRoOD90HcHMvoBP/+FOeUyofmRuRru6tezAxtS+iF MifOYoW4cDz2FBoTnXwvlcuVCdTBSidTf9Yj5gEygkeh3qFvmj/l/+pkwzd4pdSN6u/3 vzLyOkSOZrbumKeNnUXHQJR7j45YIvH5zTcJR2FDkSLUMG289lobH9wn4BiSN72dGuYD n8q84g0OAShLsg3FaCfxRupgNIX/LhoOztZxWbVANAiJHcO+4ylHO+9ofY+r+DjKZTcl imF8j23A0zy2UjxNrMVS/DC8M+htM0qpr29Ws1N+wuM90I1wdc2Tlx5diJ0HOpnf5iyD b5uA==
X-Gm-Message-State: AG10YORNiMNfK6D4rKwA6p89k53kKcBgh7W535VYk2CQTQkF4xo54q8mS9sL/lSVscmR9A==
X-Received: by 10.98.70.28 with SMTP id t28mr41081334pfa.110.1456176189772; Mon, 22 Feb 2016 13:23:09 -0800 (PST)
Received: from [10.16.65.100] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id d65sm38924335pfb.74.2016.02.22.13.23.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 13:23:08 -0800 (PST)
To: otroan@employees.org
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
From: Jouni Korhonen 
Message-ID: <56CB7C3C.9090506@gmail.com>
Date: Mon, 22 Feb 2016 13:23:08 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 21:23:12 -0000

2/22/2016, 12:03 AM, otroan@employees.org kirjoitti:
>> Ťp2p links without NDť sounds like a rather shoddy implementation to
>> me. Even though you won't need ND to discover link-layer addreses on
>> p2p links, you're still going to need it for DAD, NUD, SLAAC, default
>> router discovery, more-specific routes discovery, RDNSS discovery, etc.
>> etc. etc.
>
> at least with regards to the implementations I'm familiar with, that means no ND address resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication that also means we don't do NUD.

NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still 
usable as IP layer reachability detection of your next hop, right.

- Jouni

>
> multi-access networks aren't around much any more, after the yellow cable went out of fashion. John B's draft on per host /64s, got me thinking that we can trivially represent an Ethernet (wired or wireless) as a set of point to point links. then we can largely remove dynamic address resolution also on Ethernet. for wireless that's quite attractive. anyone have the energy to join me writing it up for BA?
>
> cheers,
> Ole
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Mon Feb 22 14:31:10 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5DF1A702A for ; Mon, 22 Feb 2016 14:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2ubJQu9sg35 for ; Mon, 22 Feb 2016 14:31:06 -0800 (PST)
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 463B21A6FD0 for ; Mon, 22 Feb 2016 14:31:06 -0800 (PST)
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 u1MMVCiA022863; Mon, 22 Feb 2016 14:31:12 -0800
Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1MMVAHb022841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 22 Feb 2016 14:31:10 -0800
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.135]) with mapi id 14.03.0235.001;  Mon, 22 Feb 2016 14:31:03 -0800
From: "Templin, Fred L" 
To: "v6ops@ietf.org WG" 
Thread-Topic: Comments on draft-ietf-v6ops-host-addr-availability-05
Thread-Index: AdFtuuZdacBlAhDFT8ONews5zmBtdQ==
Date: Mon, 22 Feb 2016 22:31:02 +0000
Message-ID: <2134F8430051B64F815C691A62D983183396E593@XCH-BLV-105.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Subject: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Feb 2016 22:31:09 -0000

Hi,

I told Fred B. that I would review this document and post comments.
Overall, I think the document is in reasonably good shape but I have
 two primary suggested areas for improvement.

First, the document throughout uses expressions of the form "networks
provide hosts with multiple global addresses" but IMHO that implies  a
sort of "push" operation where the network pushes addresses onto the
host which is not the way things work in practice. I think a more appropria=
te
expression form would be "networks provide hosts with a means to obtain
multiple global addresses".

Second, the document seems to imply in several places that SLAAC can
be used as a sort of implicit prefix delegation service; presumably in the
same spirit as RFC7278. If that is the intention, then it also needs to say
that the host needs to have some way of knowing outside of the scope
of the node requirement standards that the prefix is being delegated
for the host's exclusive use. For example, an unmodified host that obeys
RFC4861 on a WiFi link would have no way of knowing that a prefix
advertised in a PIO with (A=3D1; L=3D0) is in fact being delegated for its =
own
exclusive use. The document therefore needs to note this rather than
imply that an unmodified host can use SLAAC for prefix delegation.

See below for detailed comments, including those related to the two
primary themes as well as others:

Fred
fred.l.templin@boeing.com

---

1) Introduction, "It recommends that networks provide
   general-purpose end hosts with multiple global addresses"
   suggest changing to: "It recommends that networks provide
   general-purpose end hosts with a means to obtain
   multiple global addresses".

2) Section 3, "Today there are many host functions that
   require more than one IP address to be available to
   the host:" suggest changing to: "Today there are many
   host functions that require more than one IP address to
   be available to the to the host, including:"

3) Section 4, "Providing a restricted number of addresses"
   suggest changing to: "Restricting the number of
   addresses".

4) Section 4, "e.g., if the network provides only one IPv6
   address per host" suggest changing to: "e.g., if the
   network permits only one IPv6 address per host".

5) Section 5, "and even when the decision to provide only
   one IPv6 address per device ... because devices can
   share their IPv6 address with other devices." suggest
   changing to: "and even when the decision to permit only
   limited numbers of IPv6 addresses per device ... because
   devices can share their IPv6 addresses with other devices."

6) Section 6, title: "Options for providing more than one
   address" suggest changing to: "Multi-addressing Options".

7) Section 6, "Multiple IPv6 addresses can be provided in
   the following ways:" suggest changing to: "Hosts can
   obtain multiple IPv6 addresses in the following ways:"

8) Section 6, under the heading "Using Stateless Address
   Autoconfiguration [RFC4862]." This section does not make
   a statement as to whether the "dedicated /64 prefix" is
   to be used only for SLAAC on the interface over which the
   prefix is advertised, or whether the prefix can be
   extended to a LAN link as in RFC7278. If the intention
   is the latter, then the host would need to have some
   means of knowing that the prefix is indeed dedicated,
   but RFC4861 only says that "L=3D0" means that the PIO
   contains no information about the on/off-link property
   of the prefix.

9) Sectin 6, under the heading "Using Stateful DHCPv6 address
   assignment [RFC3315]" final sentence in the paragraph says
   "The number of IPv6 addresses that can be provided in a
   single DHCPv6 packet is approximately 30." but it does
   not say where the "30" came from. Is it because of packet
   size limitations? Some protocol constant? Something else?
   Suggest adding a trailing phrase giving some rationale
   for the "30".

10) Table 1, "Extend network" is listed as "Yes" for SLAAC,
   which would seem to imply that SLAAC is intended to extend
   the prefix to a LAN link as in RFC7278. But, that can only
   be possible when the host has some way of knowing that the
   prefix has been "delegated" which is outside the scope of
   RFC4861. Can be addressed by adding a "**" next to the
   Yes with the footnote:

   (**) If the host has knowledge that the prefix has been
        dedicated for its own exclusive use.

11) Table 1, ""Unlimited" endpoints is listed as "No" for
   DHCPv6 PD. Shouldn't it be a "Yes"?

12) Section 8, "it is RECOMMENDED that IPv6 network deployments
   provide multiple IPv6 addresses from each prefix to general
   purpose hosts." suggest changing to: "it is RECOMMENDED that
   IPv6 network deployments provide general-purpose hosts with
   a means to obtain multiple IPv6 addresses from each prefix".

13) Section 8, "The prefix MAY be provided using DHCPv6 PD,
   SLAAC with per-device VLANs, or any other means." Two issue
   with this - first, the text earlier also included "wireless
   network where every MAC address is placed in its own
   broadcast domain" which should also be reiterated here.
   Second (as with comments 8 and 10), for SLAAC-based methods
   the document needs to say that the host must have some way
   of knowing that the prefix has been dedicated for its own
   exclusive use beyond the existing IPv6 node requirements
   (i.e., beyond RFC4861).

14) Section 9.1, rename section as simply "Host Tracking", since
   the section covers both stateful and SLAAC.

15) Section 9.1, paragraph beginning "Many large enterprise
   networks, including the enterprise networks of the authors'
   employers" seems to be advocating for a specific approach
   while the rest of the document is appropriately neutral.
   IMHO, this paragraph could be removed.

16) The document could benefit from adding a section on mobility.


From nobody Mon Feb 22 16:06:16 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD051A1AC1 for ; Mon, 22 Feb 2016 16:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Level: 
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRMP6J9qgNLT for ; Mon, 22 Feb 2016 16:06:12 -0800 (PST)
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 627AF1A016A for ; Mon, 22 Feb 2016 16:06:12 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 D3A248047A; Tue, 23 Feb 2016 01:06:00 +0100 (CET)
To: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CBA254.2090107@si6networks.com>
Date: Mon, 22 Feb 2016 21:05:40 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 00:06:15 -0000

Folks,

I support publication of this document as an RFC. Here's my review:


** Technical **

* Section 1, page 3:
>    The M and O flags are advisory, not prescriptive.  For example, the M
>    flag indicates that addresses are available from DHCPv6, but It does
>    not indicate that hosts are required to acquire addresses from
>    DHCPv6.  Similar statements can be made about the O flag.  (A flag is
>    also advisory by definition in standard, but it is quite prescriptive
>    in implementations according to the test results in the appendix.)

mm.. could you quote something from RFC4862 regarding these bits "being
advisory"?


* Section 2.1, page 4 (and other instances):
> 
>    o  A (Autonomous) Flag
> 
>          A flag is defined in the PIO, "When set indicates that this
>          prefix can be used for stateless address configuration as
>          specified in [RFC4862].".

This, as is, is misleading: I'd separate the analysis of "M" and "O" --
which are mandatory in the RA header, vs the A flag, which is only
present in the PIOs, and hence is optional.


* Section 3, page 4:
> More specifically, it is
>       unclear whether RA (with M=1) is required to trigger DHCPv6; in
>       other words, It is unclear whether hosts should initiate DHCPv6 by
>       themselves if there are no RAs at all.

This is confusing. There are two different cases here: M=1 -- for which
I don't think there's any ambuiguity, and no RA, in which case there is.


* Section 6, page 10:
>    An attacker, without having to install a rogue router, can install a
>    rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1
>    systems.  This can allow her to interact with these systems in a
>    different scope, which, for instance, is not monitored by an IDPS
>    system.


Not sure what you mean. Do you mean that with other OS, an attacked
would be required to forge RA's in order to be able to perform this
attack? - If so, please say so. :-)  Additionally, these RFCs would be
helpful here: RFC7610, RFC7123, RFC6105.


* Section 6, page 10:
>    The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited
>    for DoS purposes.  A rogue IPv6 router not only provides its own
>    information to the clients, but it also removes the previous obtained
>    (legitimate) information. 

Note sure what you mean by "rogue IPv6 router". Are you referring to
spoofed RA?


* Appendix A, page 12:
> 
>    The authors from two orgnizations tested different scenarios
>    independent of each other.

It's not clear from this text whether you tested the same thing, or
different things (i.e., no overlap, partial overlap, or full overlap of
the tests).

While it is valuable to indicate that multiple tests were performed
independently (i.e., they were validated), what's useful from the pov of
the reader is to get the aggregate of the tests, possibly in a table.

If all the overlapping text shielded the same result, please say so, and
just publish the aggregate of the results. If the same test shielded a
different result in each of the test scenarios, please note which ones,
and try to explain why the same test shielded a different result.






** Editorial **

* Section 1, page 3:
>  to to discover 

Writeo -- remove one instance of "to"


* Section 1, page 3:
>    o  an M (Managed) flag, indicating that addresses are available from
>       DHCPv6 or not
> 
>    o  an O (OtherConfig) flag, indicating that other configuration
>       information (e.g., DNS-related information) is available from
>       DHCPv6 or not
> 
>    o  zero or more Prefix Information (PI) Options
> 
>          an A (Autonomous) flag is included, indicating that the prefix
>          can be used for SLAAC or not


Bullet #3 should follow the style of the fit two bullets.


* Section 1, page 3:
> This
>    document analyzes possible divergent host behaviors might happen
>    (most of the possible divergent behaviors are already observed in
>    popular operating systems) and the operational problems might caused
>    by divergent behaviors.

missing "how" in "[how] possible different..."


* Section 3, page 4:
>       In standards, behavior of DHCPv6 and Neighbor Discovery protocols
>       is specified respectively.

s/respectively/separately/? -- if not, what do you mean?


* Section 5.2, page 9:
>          release the current SLAAC address and acquire another new SLAAC
>          address (might comes from different source).

s/comes/come/


* Section 6, page 10:
> 
>    If an attacker wants to perform MiTM (Man in The Middle) using a
>    rogue DNS while legitimates RAs with the O flag set are sent to
>    enforce the use of a DHCPv6 server,

s/legitimates/legitimate/


* Section A.2.3, page 19:
> these scenarios there are two routers on the same link. 

s/these/These.


Thanks!

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





From nobody Mon Feb 22 18:04:39 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D431B3BB5 for ; Mon, 22 Feb 2016 18:04:37 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMhyPThGilLR for ; Mon, 22 Feb 2016 18:04:35 -0800 (PST)
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 60B2D1B3BB4 for ; Mon, 22 Feb 2016 18:04:35 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 B0EC780DB9; Tue, 23 Feb 2016 03:04:29 +0100 (CET)
To: fred@cisco.com, v6ops@ietf.org
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CBAB0C.4080704@si6networks.com>
Date: Mon, 22 Feb 2016 21:42:52 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 02:04:37 -0000

On 02/21/2016 04:00 PM, fred@cisco.com wrote:
> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.
> 
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.

I support the publication of this document as an RFC. I believe it
contains valuable information.

Detailed comments have been posted in a separate thead, and I expect
most of such comments to be addresses before the document is shipped to
the IESG.

Thanks!

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





From nobody Mon Feb 22 19:41:46 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18F41B3B3E for ; Mon, 22 Feb 2016 19:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwsdt0dUhH-g for ; Mon, 22 Feb 2016 19:41:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462B81B3A01 for ; Mon, 22 Feb 2016 19:41:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEW44921; Tue, 23 Feb 2016 03:41:38 +0000 (GMT)
Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 23 Feb 2016 03:41:37 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 23 Feb 2016 03:41:36 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Tue, 23 Feb 2016 11:41:31 +0800
From: "Liubing (Leo)" 
To: Fernando Gont , "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
Thread-Index: AQHRbc4WXdeH8AUELEm3F2sYZRE8EJ844qwA
Date: Tue, 23 Feb 2016 03:41:31 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D45C70@nkgeml514-mbx.china.huawei.com>
References: <56CBA254.2090107@si6networks.com>
In-Reply-To: <56CBA254.2090107@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56CBD4F2.0078, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 305d5db881a534940e44aa82fa02086e
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 03:41:46 -0000

Hi Fernando,

Thanks much for your support and comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: Tuesday, February 23, 2016 8:06 AM
> To: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org
> Cc: IPv6 Operations
> Subject: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
>=20
> Folks,
>=20
> I support publication of this document as an RFC. Here's my review:
>=20
>=20
> ** Technical **
>=20
> * Section 1, page 3:
> >    The M and O flags are advisory, not prescriptive.  For example, the =
M
> >    flag indicates that addresses are available from DHCPv6, but It does
> >    not indicate that hosts are required to acquire addresses from
> >    DHCPv6.  Similar statements can be made about the O flag.  (A flag
> is
> >    also advisory by definition in standard, but it is quite prescriptiv=
e
> >    in implementations according to the test results in the appendix.)
>=20
> mm.. could you quote something from RFC4862 regarding these bits "being
> advisory"?
[Bing] In the previous version SLAAC (RFC2462), there was some nice prescri=
ptive processing of the flags, but it was just removed in RFC4862 as stated=
 "Removed the text regarding the M and O flags, considering the maturity of=
 implementations and operational experiences...". I believe that is the mai=
n reason of why current OSes' behavior diverts.

> * Section 2.1, page 4 (and other instances):
> >
> >    o  A (Autonomous) Flag
> >
> >          A flag is defined in the PIO, "When set indicates that this
> >          prefix can be used for stateless address configuration as
> >          specified in [RFC4862].".
>=20
> This, as is, is misleading: I'd separate the analysis of "M" and "O" -- w=
hich are
> mandatory in the RA header, vs the A flag, which is only present in the P=
IOs,
> and hence is optional.
[Bing] I agree with you that separating them is more logically clear. But t=
he trouble thing is, according to Divergence 2-1 (in Section 4.2), A flag a=
nd O flag have some relationship in some OSes. So I just felt it had to be =
discussed together. Do you have any suggestion? I'd be glad to hear. Thanks=
.=20

> * Section 3, page 4:
> > More specifically, it is
> >       unclear whether RA (with M=3D1) is required to trigger DHCPv6; in
> >       other words, It is unclear whether hosts should initiate DHCPv6 b=
y
> >       themselves if there are no RAs at all.
>=20
> This is confusing. There are two different cases here: M=3D1 -- for which=
 I
> don't think there's any ambuiguity, and no RA, in which case there is.
[Bing] I think we're talking about the same thing. However, the text intend=
s to emphasize in another perspective: if "no RAs" is ambiguity, it means s=
ome OSes just wait to the M=3D1; if they don't see it, they just don't do D=
HCPv6. This implies a dependency relationship which in my mind is not prope=
r.

> * Section 6, page 10:
> >    An attacker, without having to install a rogue router, can install a
> >    rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1
> >    systems.  This can allow her to interact with these systems in a
> >    different scope, which, for instance, is not monitored by an IDPS
> >    system.
>=20
>=20
> Not sure what you mean. Do you mean that with other OS, an attacked
> would be required to forge RA's in order to be able to perform this attac=
k? -
> If so, please say so. :-)  Additionally, these RFCs would be helpful here=
:
> RFC7610, RFC7123, RFC6105.
[Bing] Yes, exactly what you mean. Because Win8.1 just ignore RAs to indepe=
ndently interact with DHCPv6 server, it lacks a protection such as RA guard=
 on this kind of attack.
I'll see whether it's good to reference the RFCs here, especially the RFC76=
10. Thanks for the info.

 > * Section 6, page 10:
> >    The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited
> >    for DoS purposes.  A rogue IPv6 router not only provides its own
> >    information to the clients, but it also removes the previous obtaine=
d
> >    (legitimate) information.
>=20
> Note sure what you mean by "rogue IPv6 router". Are you referring to
> spoofed RA?
[Bing] Yes, this specifically means the flag transitioning. E.g., when M is=
 turned off, these OSes would immediately release the DHCPv6 addresses. Thi=
s could be used by the attacker.
I'll make this clearer in the next version.

> * Appendix A, page 12:
> >
> >    The authors from two orgnizations tested different scenarios
> >    independent of each other.
>=20
> It's not clear from this text whether you tested the same thing, or diffe=
rent
> things (i.e., no overlap, partial overlap, or full overlap of the tests).
>=20
> While it is valuable to indicate that multiple tests were performed
> independently (i.e., they were validated), what's useful from the pov of =
the
> reader is to get the aggregate of the tests, possibly in a table.
>=20
> If all the overlapping text shielded the same result, please say so, and =
just
> publish the aggregate of the results. If the same test shielded a differe=
nt
> result in each of the test scenarios, please note which ones, and try to
> explain why the same test shielded a different result.
[Bing] Good point, thanks. The two tests were partial overlapped, and the o=
verlapped part was consistent in results. We just aggregated the results as=
 Section 4, and keep the raw details of the two tests in the Appendix.=20
When people read the document, we assume it is sufficient to get aware of t=
he problems from the main body text; and if somebody interested in the test=
 details, then he/she could get it in the Appendix.
Do you think it's ok?

The below editorial comments will be addressed as well.
I really appreciate your careful review.

Best regards,
Bing

>=20
>=20
>=20
> ** Editorial **
>=20
> * Section 1, page 3:
> >  to to discover
>=20
> Writeo -- remove one instance of "to"
>=20
>=20
> * Section 1, page 3:
> >    o  an M (Managed) flag, indicating that addresses are available from
> >       DHCPv6 or not
> >
> >    o  an O (OtherConfig) flag, indicating that other configuration
> >       information (e.g., DNS-related information) is available from
> >       DHCPv6 or not
> >
> >    o  zero or more Prefix Information (PI) Options
> >
> >          an A (Autonomous) flag is included, indicating that the prefix
> >          can be used for SLAAC or not
>=20
>=20
> Bullet #3 should follow the style of the fit two bullets.
>=20
>=20
> * Section 1, page 3:
> > This
> >    document analyzes possible divergent host behaviors might happen
> >    (most of the possible divergent behaviors are already observed in
> >    popular operating systems) and the operational problems might
> caused
> >    by divergent behaviors.
>=20
> missing "how" in "[how] possible different..."
>=20
>=20
> * Section 3, page 4:
> >       In standards, behavior of DHCPv6 and Neighbor Discovery
> protocols
> >       is specified respectively.
>=20
> s/respectively/separately/? -- if not, what do you mean?
>=20
>=20
> * Section 5.2, page 9:
> >          release the current SLAAC address and acquire another new
> SLAAC
> >          address (might comes from different source).
>=20
> s/comes/come/
>=20
>=20
> * Section 6, page 10:
> >
> >    If an attacker wants to perform MiTM (Man in The Middle) using a
> >    rogue DNS while legitimates RAs with the O flag set are sent to
> >    enforce the use of a DHCPv6 server,
>=20
> s/legitimates/legitimate/
>=20
>=20
> * Section A.2.3, page 19:
> > these scenarios there are two routers on the same link.
>=20
> s/these/These.
>=20
>=20
> Thanks!
>=20
> Best regards,
> --
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Feb 22 23:57:21 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE1F1A6FFC for ; Mon, 22 Feb 2016 23:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.856
X-Spam-Level: 
X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTokrlR6HS1x for ; Mon, 22 Feb 2016 23:57:16 -0800 (PST)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DC81A6F6D for ; Mon, 22 Feb 2016 23:57:15 -0800 (PST)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Feb 2016 08:57:15 +0100
X-IronPort-AV: E=Sophos;i="5.22,488,1449529200"; d="scan'208";a="832991417"
Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 23 Feb 2016 08:57:13 +0100
Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Feb 2016 08:57:13 +0100
From: 
To: , 
Date: Tue, 23 Feb 2016 08:57:11 +0100
Thread-Topic: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
Thread-Index: AdFqKEpukrNkNNemTw20Luhp26kiTgD5rxyA
Message-ID: <88CAA5385EB5404392BF93106C8C53F8C33425901E@HE111507.emea1.cds.t-internal.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com>
In-Reply-To: <56C5838D.2020808@gmail.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 07:57:20 -0000

SGVsbG8sDQoNCnRoZSAvNjQgR1VBIGlzIGV4Y2x1c2l2ZSB0byB0aGUgVUUuIFRoZSBuZXR3b3Jr
IGRvZXMgbm90IGhhdmUgYW55IGFkZHJlc3MgaW4gdGhlIC82NCBHVUEgYmxvY2sgYWxsb2NhdGVk
IHRvIHRoZSBzdWJzY3JpYmVyLg0KDQpUaGlzIGxpbmsgaXMgUHRQLiBMaW5rLWxvY2FsIGFkZHJl
c3NlcyBhcmUgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmsgdG8gYm90aCB0aGUgVUUgYW5kIHRoZSAi
bmV0d29yayBlbmQiLCB3aGljaCBpcyB0aGUgR0dTTiwgYXMgd2l0aCBhbnkgUHRQIGxpbmsuDQoN
CldoYXQgeW91IHNlZSBvbiB0aGUgbW9iaWxlIE9TIGlzIG5vdCBuZWNlc3NhcmlseSB3aGF0IGlz
IGhhcHBlbmluZyBvbiB0aGUgbGluay4gTW9kZW0gY2hpcHNldHMgdHJ5IHRvIHRyYW5zbGF0ZSBi
ZXR3ZWVuIHRoZSBFdGhlcm5ldCBpbnRlcmZhY2Ugb2ZmZXJlZCB0byB0aGUgT1MgYW5kIHRoZSBQ
dFAgM0dQUCBpbnRlcmZhY2U6DQoNCi0gTUFDIGFkZHJlc3NlcyBhcmUgZW11bGF0ZWQgc2luY2Ug
dGhleSBhcmUgcmVxdWlyZWQgYnkgdGhlIEV0aGVybmV0IGludGVyZmFjZSB0byB0aGUgT1MsIGJ1
dCBub3QgZXhpc3Rpbmcgb24gdGhlIDNHUFAgbGluaw0KLSBUaGUgM0dQUCBsaW5rIG1hbmRhdGVz
IHRoYXQgdGhlIFVFIHVzZXMgYSBzcGVjaWFsIGxpbmstbG9jYWwgYWRkcmVzcyB3aGljaCBpcyBw
cmVzY3JpYmVkIGJ5IHRoZSBuZXR3b3JrLiBNb3N0IE9TIHN0YWNrcyBob3dldmVyIGNyZWF0ZSB0
aGUgbGluay1sb2NhbCBhZGRyZXNzIG9uIHRoZWlyIG93biwgdGhlcmVmb3JlLCB0aGUgbW9kZW0g
Y2hpcHNldCB0cmFuc2xhdGVzIGJldHdlZW4gdGhlIHR3by4NCi0gVGhlcmUgaXMgbm8gTkQgaGFw
cGVuaW5nIG9uIHRoZSAzR1BQIGxpbmsgKHNpbmNlIGl0IGlzIFB0UCk7IHRoZSBtb2RlbSBjaGlw
c2V0IHRlcm1pbmF0ZXMgdGhlIE5EIHJlcXVlc3RzIGZyb20gdGhlIE9TIGFuZCByZXNwb25kcyBv
biBpdHMgb3duLg0KDQpIb2xnZXINCg0KLS0gDQpIb2xnZXIgTWV0c2NodWxhdCANCkRldXRzY2hl
IFRlbGVrb20gVGVjaG5payBHbWJIIA0KSGVpbnJpY2gtSGVydHotU3RyYXNzZSAzLTcsIDY0Mjk1
IERhcm1zdGFkdCANCis0OSA2MTUxIDU4IC0gMTg2NzEgKFRlbC4pIA0KKzQ5IDE2MCA5MDEgMzU0
NDMgKE1vYmlsKSANCkUtTWFpbDogaG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZSANCmh0dHA6
Ly93d3cudGVsZWtvbS5kZSANCkVybGViZW4sIHdhcyB2ZXJiaW5kZXQuwqAgDQpEaWUgZ2VzZXR6
bGljaGVuIFBmbGljaHRhbmdhYmVuIGZpbmRlbiBTaWUgdW50ZXI6IHd3dy50ZWxla29tLmRlL3Bm
bGljaHRhbmdhYmVuLWR0dGVjaG5paw0KR3Jvw59lIFZlcsOkbmRlcnVuZ2VuIGZhbmdlbiBrbGVp
biBhbiDigJMgUmVzc291cmNlbiBzY2hvbmVuIHVuZCBuaWNodCBqZWRlIEUtTWFpbCBkcnVja2Vu
LiANCg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHY2b3BzIFtt
YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQWxleGFuZHJlIFBl
dHJlc2N1DQpHZXNlbmRldDogRG9ubmVyc3RhZywgMTguIEZlYnJ1YXIgMjAxNiAwOTo0MQ0KQW46
IE1hcmsgU21pdGgNCkNjOiB2Nm9wcyBsaXN0DQpCZXRyZWZmOiBSZTogW3Y2b3BzXSBSRkMgNzI3
OCBvbiBFeHRlbmRpbmcgYW4gSVB2NiAvNjQgUHJlZml4IGZyb20gYSBUaGlyZCBHZW5lcmF0aW9u
IFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIE1vYmlsZSBJbnRlcmZhY2UgdG8gYSBMQU4gTGlu
aw0KDQoNCg0KTGUgMTcvMDIvMjAxNiAyMDo1NiwgTWFyayBTbWl0aCBhIMOpY3JpdCA6DQo+DQo+
IE9uIDE4IEZlYiAyMDE2IDI6MjYgQU0sICJBbGV4YW5kcmUgUGV0cmVzY3UiDQo+IDxhbGV4YW5k
cmUucGV0cmVzY3VAZ21haWwuY29tIDxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNv
bT4+DQo+ICB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+PiBJIGhhdmUgYSBjb21tZW50IG9uIHRo
aXMgUkZDNzI3OC4NCj4+DQo+PiBUaGUgY29tbWVudCBjb21lcyBmcm9tIHRoZSBvYnNlcnZhdGlv
biB0aGF0IHRoZSBvcGVyYXRvciBhbHNvIHVzZXMgIA0KPj4gYW4NCj4gYWRkcmVzcyBmcm9tIHRo
ZSA2NHNoYXJlIHByZWZpeCAoYSBnbG9iYWwgYWRkcmVzcykuDQo+Pg0KPg0KPiBBcmUgeW91IHN1
cmUgYWJvdXQgdGhhdD8NCg0KWUVzLiAgSW4gdGhlIFVFIHRoZSBhZGRyZXNzIG9mIHRoZSBkZWZh
dWx0IHJvdXRlciBpcyBhbiBhZGRyZXNzIHByZWZpeGVkIGJ5IHRoZSBzYW1lIHByZWZpeCBhcyB0
aGUgcHJlZml4IHRoYXQgdGhlIFVFIGJlbGlldmVzIGlzIGZvciBzZWxmICh0aGUgNjRzaGFyZSBw
cmVmaXgpLg0KDQpUaGUgZGVmYXVsdCByb3V0ZXIgYWRkcmVzcyBpcyBub3QgYSBsaW5rLWxvY2Fs
IGFkZHJlc3MgKGl0J3MgYSBHVUEpLCBhbHRob3VnaCBpdCBjb3VsZCBoYXZlIGJlZW4gTEwgaW4g
dGhlb3J5Lg0KDQpBbmQgdGhpcyB0aW1lLCBkaWZmZXJlbnQgZnJvbSBteSBlYXJsaWVyIGV4cGVy
aW1lbnRzLCB0aGUgNjRzaGFyZSBoYXBwZW5zIG9uIHRoZSBtb2R1bGUgLSBpLmUuIHRoZXJlIGlz
IG5vIGludGVybWVkaWFyeSBtb2RlbSBsaWtlIGEgY2VsbHVsYXIgVVNCIGRvbmdsZSBvciBzb21l
dGhpbmcgd2hpY2ggd291bGQgZG8gdGhpbmdzIG5vdCBpbiBjb250cm9sLCBsaWtlIHByb3h5IE5E
IG9yIHByb3h5IERIQ1AuDQoNCj4gSXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgdW5j
b252ZW50aW9uYWwgdGhpbmcgYWJvdXQgYSAzR1BQIA0KPiBzZXR1cCB3YXMgdGhhdCBhbGwgdHJh
ZmZpYyB0byBhbGwgYWRkcmVzc2VzIHdpdGhpbiB0aGUgLzY0IHdhcw0KPiAoYmxpbmRseSkgZm9y
d2FyZGVkIHRvIHRoZSBVRSwgZXZlbiBpZiB0aGUgVUUgdXNlcyBvbmUgb3IgbW9yZSBvZiANCj4g
dGhvc2UgYWRkcmVzc2VzIG9uIHRoZSBlbmQgb2YgdGhlIGxpbmsuIEkgdGhpbmsgdGhhdCBpcyBv
bmx5IHBvc3NpYmxlIA0KPiBiZWNhdXNlIHRoZSBsaW5rIGlzIGEgcG9pbnQgdG8gcG9pbnQgb25l
Lg0KDQpZRXMsIHRoYXQgaXMgdGhlIGNhc2UgLSBhbGwgYWRkcmVzc2VzIGluIHRoZSBwcmVmaXgg
YXJlIGZvcndhcmRlZCB0byB0aGUgVUUuICBCdXQgSSBkb3VidCB0aGUgb3BlcmF0b3IgZm9yd2Fy
ZHMgdG8gVUUgdGhlIHBhY2tldHMgYWRkcmVzc2VkIHRvIHRoZSBkZWZhdWx0IHJvdXRlci4gIFRo
aXMgaXMgc29tZXRoaW5nIEkgY2FuIHRyeSBhbmQgcmVwb3J0Lg0KDQooaXQgd291bGQgYmUgc3Ry
YW5nZSB0aGF0IHRoZSBwYWNrZXRzIGFkZHJlc3NlZCBvZiB0aGUgZGVmYXVsdCByb3V0ZXINCiAg
YmUgZm9yd2FyZGVkIHRvIHRoZSBVRSwgYnV0IG9uZSBuZXZlciBrbm93cyB3aXRoIHRoZSBwcHAg
bGlua3MpLg0KDQo+IChQcmVzdW1hYmx5IHRoZSBVRSBoYXMgYSBkaXNjYXJkIHJvdXRlIGZvciB0
aGUgLzY0IHRvIHByZXZlbnQgbG9vcHMgDQo+IGZvciBub24tZXhpc3RlbnQgYWRkcmVzc2VzLikN
Cg0KWUVzLiAgVy9vIDY0c2hhcmUgdGhlIFVFIGluc3RhbGxzIGEgcm91dGUgZm9yIHRoZSAvNjQg
b24gaXRzIGNlbGx1bGFyIGludGVyZmFjZSAoYSAiKiIgcm91dGUgb24gd2hpY2ggVUUgZG9lcyBO
RCkuICBUaGVuIHdoZW4gZG9pbmcgNjRzaGFyZSB0aGUgVUUgbXVzdCByZW1vdmUgdGhhdCByb3V0
ZSBmcm9tIHRoZSBjZWxsdWxhciBpbnRlcmZhY2UgYW5kIGluc3RhbGwgaXQgb24gaXRzIG90aGVy
IGludGVyZmFjZSAoVVNCbmV0IGluIG15IGNhc2UpLiAgSSBndWVzcyB0aGlzIGlzIHdoYXQgeW91
IG1lYW4gYnkgZGlzY2FyZCByb3V0ZS4NCg0KSG93ZXZlciwgaXQgbXVzdCBtYWludGFpbiBvbiBp
dHMgY2VsbHVhciBpbnRlcmZhY2UgdGhlIGRlZmF1bHQgcm91dGUgKGENCi8xMjggaG9zdC1iYXNl
ZCByb3V0ZSkuDQoNCkFsZXgNCg0KPj4gQXMgc3VjaCB0aGF0IGFkZHJlc3MgdG9vIHNob3VsZCBu
b3QgYmUgdXNlZCBpbiB0aGUgJ0xBTicuDQo+Pg0KPj4gVGhpcyBtYXkgbGVhZCB0byBzZXZlcmFs
IHRleHR1YWwgbW9kaWZpY2F0aW9ucyB0byB0aGUgZG9jdW1lbnQuDQo+PiBGb3INCj4gZXhhbXBs
ZToNCj4+Pg0KPj4+IFItMjogVGhlIFVFIE1VU1QgZGVmZW5kIGFsbCBvZiBpdHMgSVB2NiBhZGRy
ZXNzZXMgb24gdGhlIExBTiBsaW5rLg0KPj4NCj4+DQo+PiBUaGlzIGlzIHdyb25nbHkgc3RhdGVk
LCBiZWNhdXNlIHRoZSBVRSBkb2VzIG5vdCBvd24gdGhhdCBwcmVmaXgsIHNvDQo+Pg0KPiBpdCBj
YW4ndCBzYXkgIml0cyBJUHY2IGFkZHJlc3NlcyIuICBUaGF0IHByZWZpeCBpcyBiZWxvbmdpbmcg
dG8gYSBsaW5rIA0KPiBub3QgdG8gdGhlIFVFLCBiZWNhdXNlIHRoZSBvcGVyYXRvciBhbHNvIG1h
a2VzIGFuIGFkZHJlc3Mgb3V0IG9mIGl0Lg0KPj4NCj4+IEFsZXgNCj4+DQo+PiBMZSAyNi8wNi8y
MDE0IDIyOjU1LCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQo+IDxtYWlsdG86cmZjLWVkaXRv
ckByZmMtZWRpdG9yLm9yZz4gYSDDqWNyaXQgOg0KPj4+DQo+Pj4gQSBuZXcgUmVxdWVzdCBmb3Ig
Q29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJhcmllcy4NCj4+Pg0K
Pj4+DQo+Pj4gUkZDIDcyNzgNCj4+Pg0KPj4+IFRpdGxlOiAgICAgIEV4dGVuZGluZyBhbiBJUHY2
IC82NCBQcmVmaXggZnJvbSBhIFRoaXJkIEdlbmVyYXRpb24NCj4+PiAgUGFydG5lcnNoaXAgUHJv
amVjdCAoM0dQUCkgTW9iaWxlIEludGVyZmFjZSB0byBhIExBTiBMaW5rDQo+Pj4gQXV0aG9yOiBD
LiBCeXJuZSwgRC4gRHJvd24sIEEuIFZpemRhbCBTdGF0dXM6ICAgICBJbmZvcm1hdGlvbmFsDQo+
Pj4gU3RyZWFtOiBJRVRGIERhdGU6ICAgICAgIEp1bmUgMjAxNCBNYWlsYm94Og0KPj4+IGNhbWVy
b24uYnlybmVAdC1tb2JpbGUuY29tDQo+IDxtYWlsdG86Y2FtZXJvbi5ieXJuZUB0LW1vYmlsZS5j
b20+LA0KPj4+IGRhbkBkcm93bi5vcmcgPG1haWx0bzpkYW5AZHJvd24ub3JnPiwgYWxlcy52aXpk
YWxAdC1tb2JpbGUuY3oNCj4+PiA8bWFpbHRvOmFsZXMudml6ZGFsQHQtbW9iaWxlLmN6PiBQYWdl
czogICAgICAxMCBDaGFyYWN0ZXJzOg0KPj4+IDE5OTY1IFVwZGF0ZXMvT2Jzb2xldGVzL1NlZUFs
c286ICAgTm9uZQ0KPj4+DQo+Pj4gSS1EIFRhZzogICAgZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJl
LTEwLnR4dA0KPj4+DQo+Pj4gVVJMOiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3
Mjc4LnR4dA0KPj4+DQo+Pj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIGZv
ciBleHRlbmRpbmcgYW4gSVB2NiAvNjQNCj4+PiBwcmVmaXggZnJvbSBhIFVzZXIgRXF1aXBtZW50
IFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdA0KPj4+ICgzR1BQKSByYWRpbyBp
bnRlcmZhY2UgdG8gYSBMQU4gbGluayBhbmQgZGVzY3JpYmVzIHR3bw0KPj4+IGltcGxlbWVudGF0
aW9uIGV4YW1wbGVzLg0KPj4+DQo+Pj4gVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhl
IElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdyb3VwDQo+Pj4gb2YNCj4gdGhlIElFVEYuDQo+Pj4N
Cj4+Pg0KPj4+IElORk9STUFUSU9OQUw6IFRoaXMgbWVtbyBwcm92aWRlcyBpbmZvcm1hdGlvbiBm
b3IgdGhlIEludGVybmV0DQo+IGNvbW11bml0eS4NCj4+PiBJdCBkb2VzIG5vdCBzcGVjaWZ5IGFu
IEludGVybmV0IHN0YW5kYXJkIG9mIGFueSBraW5kLg0KPj4+IERpc3RyaWJ1dGlvbiBvZiB0aGlz
IG1lbW8gaXMgdW5saW1pdGVkLg0KPj4+DQo+Pj4gVGhpcyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0
byB0aGUgSUVURi1Bbm5vdW5jZSBhbmQgcmZjLWRpc3QNCj4+PiBsaXN0cy4gVG8gc3Vic2NyaWJl
IG9yIHVuc3Vic2NyaWJlLCBzZWUNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaWV0Zi1hbm5vdW5jZQ0KPj4+IGh0dHA6Ly9tYWlsbWFuLnJmYy1lZGl0b3Iub3JnL21h
aWxtYW4vbGlzdGluZm8vcmZjLWRpc3QNCj4+Pg0KPj4+IEZvciBzZWFyY2hpbmcgdGhlIFJGQyBz
ZXJpZXMsIHNlZQ0KPj4+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvc2VhcmNoIEZvciBkb3du
bG9hZGluZyBSRkNzLCBzZWUNCj4+PiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy5odG1s
DQo+Pj4NCj4+PiBSZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJlIGFk
ZHJlc3NlZCB0byBlaXRoZXINCj4+PiB0aGUgYXV0aG9yIG9mIHRoZSBSRkMgaW4gcXVlc3Rpb24s
IG9yIHRvDQo+Pj4gcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZw0KPiA8bWFpbHRvOnJmYy1lZGl0
b3JAcmZjLWVkaXRvci5vcmc+LiAgVW5sZXNzDQo+Pj4gc3BlY2lmaWNhbGx5IG5vdGVkIG90aGVy
d2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJlIGZvcg0KPj4+IHVubGltaXRlZCBk
aXN0cmlidXRpb24uDQo+Pj4NCj4+Pg0KPj4+IFRoZSBSRkMgRWRpdG9yIFRlYW0gQXNzb2NpYXRp
b24gTWFuYWdlbWVudCBTb2x1dGlvbnMsIExMQw0KPj4+DQo+Pj4NCj4+Pg0KPj4NCj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcg
bGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcgPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0K
djZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv
cHMNCg==


From nobody Mon Feb 22 23:59:35 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE0F1B39F0 for ; Mon, 22 Feb 2016 23:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.856
X-Spam-Level: 
X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln2UnkaQlt1f for ; Mon, 22 Feb 2016 23:59:30 -0800 (PST)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB36C1B3311 for ; Mon, 22 Feb 2016 23:59:29 -0800 (PST)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Feb 2016 08:59:17 +0100
X-IronPort-AV: E=Sophos;i="5.22,488,1449529200"; d="scan'208";a="1011856434"
Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 23 Feb 2016 08:59:17 +0100
Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Feb 2016 08:59:17 +0100
From: 
To: , 
Date: Tue, 23 Feb 2016 08:59:16 +0100
Thread-Topic: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
Thread-Index: AdFq+Pb7fgPSD0f1QiCtz8dNV6nl6gDFxSFA
Message-ID: <88CAA5385EB5404392BF93106C8C53F8C334259023@HE111507.emea1.cds.t-internal.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com>
In-Reply-To: <56C6E1C8.2080907@gmail.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 07:59:33 -0000

Hello,

... and these changes are transparent to the network.

Holger

--=20
Holger Metschulat=20
Deutsche Telekom Technik GmbH=20
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt=20
+49 6151 58 - 18671 (Tel.)=20
+49 160 901 35443 (Mobil)=20
E-Mail: holger.metschulat@telekom.de=20
http://www.telekom.de=20
Erleben, was verbindet.=A0=20
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtang=
aben-dttechnik
Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede=
 E-Mail drucken.=20



-----Urspr=FCngliche Nachricht-----
Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandre Petresc=
u
Gesendet: Freitag, 19. Februar 2016 10:35
An: v6ops@ietf.org
Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third =
Generation Partnership Project (3GPP) Mobile Interface to a LAN Link



Le 18/02/2016 22:08, Jouni Korhonen a =E9crit :
>> I will get a capture soon.  What I suspect happening is the ppp=20
>> software
>
> And please get the capture from the GTP-U/C tunnel & its content that=20
> leaves the GGSN/PGW and also from the NAS signaling that the UE=20
> receives. Those tell quite a bit.

That's going to be hard if not impossible.

The 64share technique relies on changes on only the UE.

Alex

>
> - Jouni
>
>
>> ("cm" command) installing the LL default route and the RA installing=20
>> the GUA default route.  But I will see more tomorrow.
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


From nobody Tue Feb 23 00:04:58 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7961B3E4C for ; Tue, 23 Feb 2016 00:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv-ZUqGn1_6D for ; Tue, 23 Feb 2016 00:04:55 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E02C1B3E48 for ; Tue, 23 Feb 2016 00:04:55 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EACE8D7884; Tue, 23 Feb 2016 00:04:52 -0800 (PST)
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=oyasjUi4xAGYqWcFl4/am1WcM80=; b= gg1FSiEYED6si/LuoO+TpgteagzfcXL7Kcara/1zwd9LWtPMM1KpZINOwdN7mDs6 RTFq3PIfchK7r3eZ3W41mQ51/l8okd9kg66UCNannEMk0AG1pIzjcfqF9yH8j/Kj /yMFmGMmAwoZqHrA4r4oBHvS85Lf66res0v6L2cHA3w=
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=Ph/oM4edynKKN0r6KUMdA9M8Qf fDFaJdJBJ+4TO2D1hwsgXwuQaNZa/b14o+9HCF/07qNhmo282reJITO0eq4TDuT4 V3A5C443Oi+yovbKeLEDKPztholvpkoROJvySkBfxtAsh9iaJOPHXhA6q6P0UlNT BhJA2RJ/p7zWg4dUk=
Received: from h.hanazo.no (unknown [173.38.220.43]) (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 AE2E1D7883; Tue, 23 Feb 2016 00:04:52 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7BB9A115BEB0; Tue, 23 Feb 2016 09:04:50 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_5EC74169-D18E-484C-8DB9-995E34E6203E"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56CB7C3C.9090506@gmail.com>
Date: Tue, 23 Feb 2016 09:04:50 +0100
Message-Id: <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 08:04:57 -0000

--Apple-Mail=_5EC74169-D18E-484C-8DB9-995E34E6203E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Jouni,

>>> =ABp2p links without ND=BB sounds like a rather shoddy =
implementation to
>>> me. Even though you won't need ND to discover link-layer addreses on
>>> p2p links, you're still going to need it for DAD, NUD, SLAAC, =
default
>>> router discovery, more-specific routes discovery, RDNSS discovery, =
etc.
>>> etc. etc.
>>=20
>> at least with regards to the implementations I'm familiar with, that =
means no ND address resolution. address resolution on a link without L2 =
addresses is in any case meaningless. by implication that also means we =
don't do NUD.
>=20
> NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still =
usable as IP layer reachability detection of your next hop, right.

yes, but typically in this case the router wouldn't keep state for its =
neighbours. no state no NUD.

cheers,
Ole

--Apple-Mail=_5EC74169-D18E-484C-8DB9-995E34E6203E
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

iQIcBAEBCgAGBQJWzBKiAAoJEL7aWKiYQt923IgP/Ax1Qdm4hofQSY+r6mbpYzeT
xOFwLPSVo0yEsB++XQKnYNe58ZytL1h87kr7wIuk40MsQkF7EUMVaPTnF4XO5fOG
ZYEXYbiPP/tcA2PtQj7mQxmDGCCnGxpQ4vmiILKv/zAd8jfEsPXnDv3MgGkR8n2O
6lKLspN8MEM8vJv16nJAm+oWANfyZignFPzh1n+dpdHEX4aIpgDUPFGsCUZGxt2f
AJdwCYeXYDrr7g0okCCLoX0UcHvpL3QkJIy8N23klxL0hbaRwZdzguTHDALfoK0s
9t61z7kOdztcacI+G1WhoeUcxNlBOtQ/jLIgJdPyDpnfvu0RpTco/MBgSG4XA/Jr
y7OQnjoGZQUJt7bKvOxHP1KLceh53MsHFRq6YCpdoACf5R7+r8C/2IIqRWHc/pXW
IfpWXcYkI4ZkjlbMxs/5YkmudFHr7TTLq59jh16J2P31otj+Si5Rb8W9j1I1Pn/C
VVSXa6lT3bwGU48USHy/kX8GdLu3NAd0qYVaBWfkoIfgOOnJc43U5yF7kXOelO+l
bbtskGSsvI1gIBYJNkIjdEMObiFjl2WA2a/UQvzEZQuChpOykTfobE6+30+DkmMY
7bUhH2yXJ6cAblf6KkR4ZbN+ZK02e4IPPCGkqABHSkmynCyMbRwdBc0LbP3IkKNx
R17MEa+b6cuasfxOet77
=2qdo
-----END PGP SIGNATURE-----

--Apple-Mail=_5EC74169-D18E-484C-8DB9-995E34E6203E--


From nobody Tue Feb 23 00:12:59 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878B1B3E8A for ; Tue, 23 Feb 2016 00:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.855
X-Spam-Level: 
X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXLEvIac2cB5 for ; Tue, 23 Feb 2016 00:12:55 -0800 (PST)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15C21B3E88 for ; Tue, 23 Feb 2016 00:12:52 -0800 (PST)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Feb 2016 09:12:48 +0100
X-IronPort-AV: E=Sophos;i="5.22,488,1449529200";  d="scan'208,217";a="1011870463"
Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 23 Feb 2016 09:12:48 +0100
Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Feb 2016 09:12:48 +0100
From: 
To: 
Date: Tue, 23 Feb 2016 09:12:47 +0100
Thread-Topic: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
Thread-Index: AdFuEbE+bRwaSXS8SMqz5YND7KgtSQAABY5A
Message-ID: <88CAA5385EB5404392BF93106C8C53F8C334259045@HE111507.emea1.cds.t-internal.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>	<56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com>	<56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com> <88CAA5385EB5404392BF93106C8C53F8C334259023@HE111507.emea1.cds.t-internal.com> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_88CAA5385EB5404392BF93106C8C53F8C334259045HE111507emea1_"
MIME-Version: 1.0
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 08:12:58 -0000

--_000_88CAA5385EB5404392BF93106C8C53F8C334259045HE111507emea1_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8gTWFyaywNCg0KdGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSSBzaG91bGQgaGF2
ZSBzYWlkLCB0aGVpciB1c2FnZSBkb2VzIG5vdCByZXF1aXJlIGFueSBjaGFuZ2VzIHRvIHRoZSBu
ZXR3b3JrIHNpZGUgb2YgYSAzR1BQIGxpbmsuIEhvd2V2ZXIsIHRoZSB1c2FnZSBvZiA2NHNoYXJl
IGNhbiBiZSBkZXRlY3RlZC4NCg0KSG9sZ2VyDQoNCi0tDQpIb2xnZXIgTWV0c2NodWxhdA0KRGV1
dHNjaGUgVGVsZWtvbSBUZWNobmlrIEdtYkgNCkhlaW5yaWNoLUhlcnR6LVN0cmFzc2UgMy03LCA2
NDI5NSBEYXJtc3RhZHQNCis0OSA2MTUxIDU4IC0gMTg2NzEgKFRlbC4pDQorNDkgMTYwIDkwMSAz
NTQ0MyAoTW9iaWwpDQpFLU1haWw6IGhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU8bWFpbHRv
OmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU+DQpodHRwOi8vd3d3LnRlbGVrb20uZGUNCkVy
bGViZW4sIHdhcyB2ZXJiaW5kZXQuDQpEaWUgZ2VzZXR6bGljaGVuIFBmbGljaHRhbmdhYmVuIGZp
bmRlbiBTaWUgdW50ZXI6IHd3dy50ZWxla29tLmRlL3BmbGljaHRhbmdhYmVuLWR0dGVjaG5pazxo
dHRwOi8vd3d3LnRlbGVrb20uZGUvcGZsaWNodGFuZ2FiZW4tZHR0ZWNobmlrPg0KR3Jvw59lIFZl
csOkbmRlcnVuZ2VuIGZhbmdlbiBrbGVpbiBhbiDigJMgUmVzc291cmNlbiBzY2hvbmVuIHVuZCBu
aWNodCBqZWRlIEUtTWFpbCBkcnVja2VuLg0KDQoNClZvbjogTWFyayBTbWl0aCBbbWFpbHRvOm1h
cmt6enpzbWl0aEBnbWFpbC5jb21dDQpHZXNlbmRldDogRGllbnN0YWcsIDIzLiBGZWJydWFyIDIw
MTYgMDk6MTENCkFuOiBNZXRzY2h1bGF0LCBIb2xnZXINCkNjOiBBbGV4YW5kcmUgUGV0cmVzY3U7
IHY2b3BzIGxpc3QNCkJldHJlZmY6IFJlOiBbdjZvcHNdIFJGQyA3Mjc4IG9uIEV4dGVuZGluZyBh
biBJUHY2IC82NCBQcmVmaXggZnJvbSBhIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJv
amVjdCAoM0dQUCkgTW9iaWxlIEludGVyZmFjZSB0byBhIExBTiBMaW5rDQoNCg0KT24gMjMgRmVi
IDIwMTYgNjo1OSBQTSwgPGhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU8bWFpbHRvOmhvbGdl
ci5tZXRzY2h1bGF0QHRlbGVrb20uZGU+PiB3cm90ZToNCj4NCj4gSGVsbG8sDQo+DQo+IC4uLiBh
bmQgdGhlc2UgY2hhbmdlcyBhcmUgdHJhbnNwYXJlbnQgdG8gdGhlIG5ldHdvcmsuDQo+DQoNCk5v
dCBpZiB5b3UgY2FuIGRldGVjdCB0aGVtLCBieSwgZm9yIGV4YW1wbGUsIGNyeXB0byBvciBvdGhl
ciBmYWlsdXJlcy4NCg0KVGhleSdyZSBiZXR0ZXIgZGVzY3JpYmVkIGFzICJ0cmFuc2x1Y2VudCIu
DQoNCj4gSG9sZ2VyDQo+DQo+IC0tDQo+IEhvbGdlciBNZXRzY2h1bGF0DQo+IERldXRzY2hlIFRl
bGVrb20gVGVjaG5payBHbWJIDQo+IEhlaW5yaWNoLUhlcnR6LVN0cmFzc2UgMy03LCA2NDI5NSBE
YXJtc3RhZHQNCj4gKzQ5IDYxNTEgNTggLSAxODY3MSAoVGVsLikNCj4gKzQ5IDE2MCA5MDEgMzU0
NDMgKE1vYmlsKQ0KPiBFLU1haWw6IGhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU8bWFpbHRv
OmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU+DQo+IGh0dHA6Ly93d3cudGVsZWtvbS5kZQ0K
PiBFcmxlYmVuLCB3YXMgdmVyYmluZGV0Lg0KPiBEaWUgZ2VzZXR6bGljaGVuIFBmbGljaHRhbmdh
YmVuIGZpbmRlbiBTaWUgdW50ZXI6IHd3dy50ZWxla29tLmRlL3BmbGljaHRhbmdhYmVuLWR0dGVj
aG5pazxodHRwOi8vd3d3LnRlbGVrb20uZGUvcGZsaWNodGFuZ2FiZW4tZHR0ZWNobmlrPg0KPiBH
cm/Dn2UgVmVyw6RuZGVydW5nZW4gZmFuZ2VuIGtsZWluIGFuIC0gUmVzc291cmNlbiBzY2hvbmVu
IHVuZCBuaWNodCBqZWRlIEUtTWFpbCBkcnVja2VuLg0KPg0KPg0KPg0KPiAtLS0tLVVyc3Byw7xu
Z2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz
QGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPl0gSW0gQXVmdHJhZyB2b24g
QWxleGFuZHJlIFBldHJlc2N1DQo+IEdlc2VuZGV0OiBGcmVpdGFnLCAxOS4gRmVicnVhciAyMDE2
IDEwOjM1DQo+IEFuOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IEJl
dHJlZmY6IFJlOiBbdjZvcHNdIFJGQyA3Mjc4IG9uIEV4dGVuZGluZyBhbiBJUHY2IC82NCBQcmVm
aXggZnJvbSBhIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCkgTW9i
aWxlIEludGVyZmFjZSB0byBhIExBTiBMaW5rDQo+DQo+DQo+DQo+IExlIDE4LzAyLzIwMTYgMjI6
MDgsIEpvdW5pIEtvcmhvbmVuIGEgw6ljcml0IDoNCj4gPj4gSSB3aWxsIGdldCBhIGNhcHR1cmUg
c29vbi4gIFdoYXQgSSBzdXNwZWN0IGhhcHBlbmluZyBpcyB0aGUgcHBwDQo+ID4+IHNvZnR3YXJl
DQo+ID4NCj4gPiBBbmQgcGxlYXNlIGdldCB0aGUgY2FwdHVyZSBmcm9tIHRoZSBHVFAtVS9DIHR1
bm5lbCAmIGl0cyBjb250ZW50IHRoYXQNCj4gPiBsZWF2ZXMgdGhlIEdHU04vUEdXIGFuZCBhbHNv
IGZyb20gdGhlIE5BUyBzaWduYWxpbmcgdGhhdCB0aGUgVUUNCj4gPiByZWNlaXZlcy4gVGhvc2Ug
dGVsbCBxdWl0ZSBhIGJpdC4NCj4NCj4gVGhhdCdzIGdvaW5nIHRvIGJlIGhhcmQgaWYgbm90IGlt
cG9zc2libGUuDQo+DQo+IFRoZSA2NHNoYXJlIHRlY2huaXF1ZSByZWxpZXMgb24gY2hhbmdlcyBv
biBvbmx5IHRoZSBVRS4NCj4NCj4gQWxleA0KPg0KPiA+DQo+ID4gLSBKb3VuaQ0KPiA+DQo+ID4N
Cj4gPj4gKCJjbSIgY29tbWFuZCkgaW5zdGFsbGluZyB0aGUgTEwgZGVmYXVsdCByb3V0ZSBhbmQg
dGhlIFJBIGluc3RhbGxpbmcNCj4gPj4gdGhlIEdVQSBkZWZhdWx0IHJvdXRlLiAgQnV0IEkgd2ls
bCBzZWUgbW9yZSB0b21vcnJvdy4NCj4gPj4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4g
djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0KPg0KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g
djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0Bp
ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdjZvcHMNCg==

--_000_88CAA5385EB5404392BF93106C8C53F8C334259045HE111507emea1_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz
cGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw
Ljg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1ERSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYg
Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPkhlbGxvIE1hcmssPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPnRoYW5rcyBmb3Ig
dGhlIGNsYXJpZmljYXRpb24uIEkgc2hvdWxkIGhhdmUgc2FpZCwgdGhlaXIgdXNhZ2UgZG9lcyBu
b3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byB0aGUgbmV0d29yayBzaWRlIG9mIGEgM0dQUCBsaW5r
LiBIb3dldmVyLCB0aGUgdXNhZ2Ugb2YgNjRzaGFyZSBjYW4gYmUgZGV0ZWN0ZWQuPG86cD48L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvbGdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtm
b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLSA8L3NwYW4+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG9s
Z2VyIE1ldHNjaHVsYXQ8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPGJyPjwvc3Bhbj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPkRldXRzY2hlIFRlbGVrb20gVGVjaG5payBHbWJIPC9zcGFuPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+IDxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3
LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IZWlu
cmljaC1IZXJ0ei1TdHJhc3NlIDMtNywgNjQyOTUgRGFybXN0YWR0PC9zcGFuPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+IDxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250
LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4rNDkgNjE1MSA1OCAt
IDE4NjcxIChUZWwuKTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8YnI+PC9zcGFuPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+KzQ5IDE2MCA5MDEgMzU0NDMgKE1vYmlsKTwvc3Bhbj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPiA8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7
Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RS1NYWlsOiA8
YSBocmVmPSJtYWlsdG86aG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZSI+aG9sZ2VyLm1ldHNj
aHVsYXRAdGVsZWtvbS5kZTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPC9zcGFu
PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToi
QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vd3d3LnRl
bGVrb20uZGUiPmh0dHA6Ly93d3cudGVsZWtvbS5kZTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7
Y29sb3I6I0UyMDA3NCc+RXJsZWJlbiwgd2FzIHZlcmJpbmRldC48L3NwYW4+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv
cjojMUY0OTdEJz4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGllIGdlc2V0emxpY2hlbiBQZmxpY2h0YW5nYWJl
biBmaW5kZW4gU2llIHVudGVyOjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8L3NwYW4+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vd3d3LnRlbGVrb20uZGUvcGZs
aWNodGFuZ2FiZW4tZHR0ZWNobmlrIj53d3cudGVsZWtvbS5kZS9wZmxpY2h0YW5nYWJlbi1kdHRl
Y2huaWs8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9u
dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+R3Jvw59lIFZlcsOk
bmRlcnVuZ2VuIGZhbmdlbiBrbGVpbiBhbjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8
L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCTPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
IFJlc3NvdXJjZW4gc2Nob25lbiB1bmQgbmljaHQgamVkZSBFLU1haWwgZHJ1Y2tlbi48L3NwYW4+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1h
bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiInPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1hcmsgU21pdGggW21haWx0bzpt
YXJrenp6c21pdGhAZ21haWwuY29tXSA8YnI+PGI+R2VzZW5kZXQ6PC9iPiBEaWVuc3RhZywgMjMu
IEZlYnJ1YXIgMjAxNiAwOToxMTxicj48Yj5Bbjo8L2I+IE1ldHNjaHVsYXQsIEhvbGdlcjxicj48
Yj5DYzo8L2I+IEFsZXhhbmRyZSBQZXRyZXNjdTsgdjZvcHMgbGlzdDxicj48Yj5CZXRyZWZmOjwv
Yj4gUmU6IFt2Nm9wc10gUkZDIDcyNzggb24gRXh0ZW5kaW5nIGFuIElQdjYgLzY0IFByZWZpeCBm
cm9tIGEgVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKSBNb2JpbGUg
SW50ZXJmYWNlIHRvIGEgTEFOIExpbms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh
c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwPjxicj5PbiAyMyBGZWIgMjAxNiA2
OjU5IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGUi
PmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU8L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4m
Z3Q7IEhlbGxvLDxicj4mZ3Q7PGJyPiZndDsgLi4uIGFuZCB0aGVzZSBjaGFuZ2VzIGFyZSB0cmFu
c3BhcmVudCB0byB0aGUgbmV0d29yay48YnI+Jmd0OzxvOnA+PC9vOnA+PC9wPjxwPk5vdCBpZiB5
b3UgY2FuIGRldGVjdCB0aGVtLCBieSwgZm9yIGV4YW1wbGUsIGNyeXB0byBvciBvdGhlciBmYWls
dXJlcy48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPlRoZXkn
cmUgYmV0dGVyIGRlc2NyaWJlZCBhcyAmcXVvdDt0cmFuc2x1Y2VudCZxdW90Oy48bzpwPjwvbzpw
PjwvcD48cD4mZ3Q7IEhvbGdlcjxicj4mZ3Q7PGJyPiZndDsgLS08YnI+Jmd0OyBIb2xnZXIgTWV0
c2NodWxhdDxicj4mZ3Q7IERldXRzY2hlIFRlbGVrb20gVGVjaG5payBHbWJIPGJyPiZndDsgSGVp
bnJpY2gtSGVydHotU3RyYXNzZSAzLTcsIDY0Mjk1IERhcm1zdGFkdDxicj4mZ3Q7ICs0OSA2MTUx
IDU4IC0gMTg2NzEmbmJzcDsoVGVsLik8YnI+Jmd0OyArNDkgMTYwIDkwMSAzNTQ0MyZuYnNwOyhN
b2JpbCk8YnI+Jmd0OyBFLU1haWw6IDxhIGhyZWY9Im1haWx0bzpob2xnZXIubWV0c2NodWxhdEB0
ZWxla29tLmRlIj5ob2xnZXIubWV0c2NodWxhdEB0ZWxla29tLmRlPC9hPjxicj4mZ3Q7IDxhIGhy
ZWY9Imh0dHA6Ly93d3cudGVsZWtvbS5kZSI+aHR0cDovL3d3dy50ZWxla29tLmRlPC9hPjxicj4m
Z3Q7IEVybGViZW4sIHdhcyB2ZXJiaW5kZXQuJm5ic3A7PGJyPiZndDsgRGllIGdlc2V0emxpY2hl
biBQZmxpY2h0YW5nYWJlbiBmaW5kZW4gU2llIHVudGVyOiA8YSBocmVmPSJodHRwOi8vd3d3LnRl
bGVrb20uZGUvcGZsaWNodGFuZ2FiZW4tZHR0ZWNobmlrIj53d3cudGVsZWtvbS5kZS9wZmxpY2h0
YW5nYWJlbi1kdHRlY2huaWs8L2E+PGJyPiZndDsgR3Jvw59lIFZlcsOkbmRlcnVuZ2VuIGZhbmdl
biBrbGVpbiBhbiAtIFJlc3NvdXJjZW4gc2Nob25lbiB1bmQgbmljaHQgamVkZSBFLU1haWwgZHJ1
Y2tlbi48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAtLS0tLVVyc3Byw7xuZ2xpY2hl
IE5hY2hyaWNodC0tLS0tPGJyPiZndDsgVm9uOiB2Nm9wcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0
bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPl0gSW0g
QXVmdHJhZyB2b24gQWxleGFuZHJlIFBldHJlc2N1PGJyPiZndDsgR2VzZW5kZXQ6IEZyZWl0YWcs
IDE5LiBGZWJydWFyIDIwMTYgMTA6MzU8YnI+Jmd0OyBBbjogPGEgaHJlZj0ibWFpbHRvOnY2b3Bz
QGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+Jmd0OyBCZXRyZWZmOiBSZTogW3Y2b3Bz
XSBSRkMgNzI3OCBvbiBFeHRlbmRpbmcgYW4gSVB2NiAvNjQgUHJlZml4IGZyb20gYSBUaGlyZCBH
ZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIE1vYmlsZSBJbnRlcmZhY2UgdG8g
YSBMQU4gTGluazxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IExlIDE4LzAyLzIwMTYg
MjI6MDgsIEpvdW5pIEtvcmhvbmVuIGEgw6ljcml0IDo8YnI+Jmd0OyAmZ3Q7Jmd0OyBJIHdpbGwg
Z2V0IGEgY2FwdHVyZSBzb29uLiZuYnNwOyBXaGF0IEkgc3VzcGVjdCBoYXBwZW5pbmcgaXMgdGhl
IHBwcDxicj4mZ3Q7ICZndDsmZ3Q7IHNvZnR3YXJlPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsg
QW5kIHBsZWFzZSBnZXQgdGhlIGNhcHR1cmUgZnJvbSB0aGUgR1RQLVUvQyB0dW5uZWwgJmFtcDsg
aXRzIGNvbnRlbnQgdGhhdDxicj4mZ3Q7ICZndDsgbGVhdmVzIHRoZSBHR1NOL1BHVyBhbmQgYWxz
byBmcm9tIHRoZSBOQVMgc2lnbmFsaW5nIHRoYXQgdGhlIFVFPGJyPiZndDsgJmd0OyByZWNlaXZl
cy4gVGhvc2UgdGVsbCBxdWl0ZSBhIGJpdC48YnI+Jmd0Ozxicj4mZ3Q7IFRoYXQncyBnb2luZyB0
byBiZSBoYXJkIGlmIG5vdCBpbXBvc3NpYmxlLjxicj4mZ3Q7PGJyPiZndDsgVGhlIDY0c2hhcmUg
dGVjaG5pcXVlIHJlbGllcyBvbiBjaGFuZ2VzIG9uIG9ubHkgdGhlIFVFLjxicj4mZ3Q7PGJyPiZn
dDsgQWxleDxicj4mZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgLSBKb3VuaTxicj4mZ3Q7
ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyZndDsgKCZxdW90O2NtJnF1b3Q7IGNvbW1h
bmQpIGluc3RhbGxpbmcgdGhlIExMIGRlZmF1bHQgcm91dGUgYW5kIHRoZSBSQSBpbnN0YWxsaW5n
PGJyPiZndDsgJmd0OyZndDsgdGhlIEdVQSBkZWZhdWx0IHJvdXRlLiZuYnNwOyBCdXQgSSB3aWxs
IHNlZSBtb3JlIHRvbW9ycm93Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7
ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
Jmd0OyAmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv
OnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPiZndDsgJmd0Ozxicj4mZ3Q7
PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNA
aWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IHY2b3BzIG1haWxpbmcgbGlz
dDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8
L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48
bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_88CAA5385EB5404392BF93106C8C53F8C334259045HE111507emea1_--


From nobody Tue Feb 23 00:20:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9365E1B3EC8 for ; Tue, 23 Feb 2016 00:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RazvMQPcPuIX for ; Tue, 23 Feb 2016 00:20:45 -0800 (PST)
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 3584C1B3E74 for ; Tue, 23 Feb 2016 00:10:41 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id e6so153994035vkh.2 for ; Tue, 23 Feb 2016 00:10:41 -0800 (PST)
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:content-type; bh=vtMqrW5oNDsOePDWjkfGVVUao9BE4xXlxTsPYucBrxU=; b=eVpsbZfQauULmAqxJ20nzW81H884gJx3p9IyFzEIsI8+iQrExlqoxrlOPcGHdVfu3a SIEQYK4n+kgCG2vDAM1JSvrWVKOwQMGvbSSWKtRC4DWcXXWnBU/TJF6e/1vL7RJbyW81 YzPhcrws0l0Fc0iSonrvHR+NfOf+OfbIzrB8sVXkpQSc2z5r1+vqIDnMOIEBAOfGtjAz hQlUXE93tg4EZ17+ohJYYYRybbnpz5Eb1FcnKKKEVke8WGjCS17AdnOTF3NlmS1XniIe 7hKo71OI/AmupUFD5bhpRLckV4pouK1nRcIDlhSzE4DsPkTjxM0xUSElugeXrpbjAgyd 6g4Q==
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-type; bh=vtMqrW5oNDsOePDWjkfGVVUao9BE4xXlxTsPYucBrxU=; b=VulFQietAvnVq1r1bJ5+WZdPiPNsmxoZXmZTKZqvoAlw1/FsVDsH9iGeiaE9/x76by 55tAyrGWAnahbc0pDzjfkk9Yg1Qi9cifMJGVMMoF6XMkM0BXZXYlQUHecYTeSKRY5O6H JtJqEOqYULxql04Fy7mNjuQJ/jwMbqtvsVI+zIYMkHMMDWB0WGJqCEWjnA1g99T0rhaR VSs3qcCe4efSu6KxwqCCCid441X9ArtcgnCBbqojJC0Lgg1xV1+KcFcKvz+E8y6PjUTu AFUibKlwfJn+uqSOqdO1yfWXNELalOWaDmYVU6mLS5dYDNyVDv2GIQ/Ic7acupvDRrqW B9rw==
X-Gm-Message-State: AG10YORopQ2KACZiaPUeWJqiE23BmbI5invG0eV4k+lveftbTFMS1DyfzphnhbkmyJVOiM/WzPIUcjiNqRnY0A==
MIME-Version: 1.0
X-Received: by 10.31.58.83 with SMTP id h80mr27456857vka.149.1456215041059; Tue, 23 Feb 2016 00:10:41 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 00:10:40 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 00:10:40 -0800 (PST)
In-Reply-To: <88CAA5385EB5404392BF93106C8C53F8C334259023@HE111507.emea1.cds.t-internal.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com> <88CAA5385EB5404392BF93106C8C53F8C334259023@HE111507.emea1.cds.t-internal.com>
Date: Tue, 23 Feb 2016 19:10:40 +1100
Message-ID: 
From: Mark Smith 
To: holger.metschulat@telekom.de
Content-Type: multipart/alternative; boundary=001a114389d43d3131052c6b7cce
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 08:20:47 -0000

--001a114389d43d3131052c6b7cce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 Feb 2016 6:59 PM,  wrote:
>
> Hello,
>
> ... and these changes are transparent to the network.
>

Not if you can detect them, by, for example, crypto or other failures.

They're better described as "translucent".

> Holger
>
> --
> Holger Metschulat
> Deutsche Telekom Technik GmbH
> Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt
> +49 6151 58 - 18671 (Tel.)
> +49 160 901 35443 (Mobil)
> E-Mail: holger.metschulat@telekom.de
> http://www.telekom.de
> Erleben, was verbindet.
> Die gesetzlichen Pflichtangaben finden Sie unter:
www.telekom.de/pflichtangaben-dttechnik
> Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an - Ressourcen schonen und ni=
cht jede
E-Mail drucken.
>
>
>
> -----Urspr=C3=BCngliche Nachricht-----
> Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandre
Petrescu
> Gesendet: Freitag, 19. Februar 2016 10:35
> An: v6ops@ietf.org
> Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
>
>
>
> Le 18/02/2016 22:08, Jouni Korhonen a =C3=A9crit :
> >> I will get a capture soon.  What I suspect happening is the ppp
> >> software
> >
> > And please get the capture from the GTP-U/C tunnel & its content that
> > leaves the GGSN/PGW and also from the NAS signaling that the UE
> > receives. Those tell quite a bit.
>
> That's going to be hard if not impossible.
>
> The 64share technique relies on changes on only the UE.
>
> Alex
>
> >
> > - Jouni
> >
> >
> >> ("cm" command) installing the LL default route and the RA installing
> >> the GUA default route.  But I will see more tomorrow.
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a114389d43d3131052c6b7cce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 23 Feb 2016 6:59 PM, <holger.metschulat@telekom.de> wrote:

>

> Hello,

>

> ... and these changes are transparent to the network.

>


Not if you can detect them, by, for example, crypto or other=
 failures.


 They're better described as "translucent".


> Holger

>

> --

> Holger Metschulat

> Deutsche Telekom Technik GmbH

> Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt

> +49 6151 58 - 18671=C2=A0(Tel.)

> +49 160 901 35443=C2=A0(Mobil)

> E-Mail: holger.metschu=
lat@telekom.de

> http://www.telekom.de

> Erleben, was verbindet.=C2=A0

> Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttech=
nik

> Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an - Ressourcen schonen und=
 nicht jede E-Mail drucken.

>

>

>

> -----Urspr=C3=BCngliche Nachricht-----

> Von: v6ops [mailto:v6ops-bou=
nces@ietf.org] Im Auftrag von Alexandre Petrescu

> Gesendet: Freitag, 19. Februar 2016 10:35

> An: v6ops@ietf.org

> Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a T=
hird Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
>

>

>

> Le 18/02/2016 22:08, Jouni Korhonen a =C3=A9crit :

> >> I will get a capture soon.=C2=A0 What I suspect happening is =
the ppp

> >> software

> >

> > And please get the capture from the GTP-U/C tunnel & its cont=
ent that

> > leaves the GGSN/PGW and also from the NAS signaling that the UE
> > receives. Those tell quite a bit.

>

> That's going to be hard if not impossible.

>

> The 64share technique relies on changes on only the UE.

>

> Alex

>

> >

> > - Jouni

> >

> >

> >> ("cm" command) installing the LL default route and =
the RA installing

> >> the GUA default route.=C2=A0 But I will see more tomorrow.
> >>

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://w=
ww.ietf.org/mailman/listinfo/v6ops

> >

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--001a114389d43d3131052c6b7cce--


From nobody Tue Feb 23 00:53:04 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCAC1B3BE3 for ; Tue, 23 Feb 2016 00:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vluurcIf8Ot for ; Tue, 23 Feb 2016 00:53:01 -0800 (PST)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 A15461B3B47 for ; Tue, 23 Feb 2016 00:53:01 -0800 (PST)
Received: by mail-vk0-x236.google.com with SMTP id c3so154898464vkb.3 for ; Tue, 23 Feb 2016 00:53:01 -0800 (PST)
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:content-type; bh=Wtc7KOK12JMzgh8kjNPTNPYI+Cjb6NKazBIs3vbivJg=; b=zZR8PUWPaxg5FSAEBerU2gnYbhyPbxooKyxAEhL99DBd8gDxAepBOHHW/9sjFwoKnI k6AFNplB/LJkVFD1OyNDSfktYeT4Ncyhlye6esQq7N4ZImxq5cGuaA1PAMONR4K36rq7 Ik+0qXV77agp+dTEfd3pUMKKtVKaYVt3TJJ2IPu6buM781cuOCDVJRj9yXBDX3juRZsH YZ86QsA/8FEvz6UylUPl7Yjm8jy8YKWgJJYfCWbJ2MoFYWGcyO/Ij9R6YMOmQtOYUaTY ta5V2x8iBSBJP5Utir8ZfUHA72qVHZE3EzmATr5Z2zgmq4Ku2kBtPeURFcKu5AkUx/5H AHXA==
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-type; bh=Wtc7KOK12JMzgh8kjNPTNPYI+Cjb6NKazBIs3vbivJg=; b=fv3Ngt2yIJi43voCAg0IGnZMERMbYVwKCdFedmfkyuZ+FctVoIBjj0cVJx1ht6Z7pw qqB2NNYVs54WByxFUf1XiX4d3gR5YX8LG+D2T5fkkSqA45ey0CoTU/LWD7UFkDmD5bA+ afnjyc6XN5C08fddYsHfyp7G10lR2nAHMtqyvs/YBlsCiKDqgMf2A6HvxuV8oCkoOtjZ ymmA/5f81aJL1anwQaeaOqC0XWU5jvM1biWMhSGpYy9SNsW5erkba5Ygo2V4wtaiiFxM sxd+NNdRTDbPYprpiC/q/6cRQgdZOQEF68e0AVqwyABKKU+E8+gylN9LqlR+gUBQqiK1 H7wg==
X-Gm-Message-State: AG10YOSV0bWvgFi3CqmdZCHEjPJB2nKCvDgFoePQdVpmnD2G2TFZEhrpqVqT+IgVQKhN3/xZagdZWMi6TbOr6g==
MIME-Version: 1.0
X-Received: by 10.31.162.20 with SMTP id l20mr24039777vke.137.1456217580758; Tue, 23 Feb 2016 00:53:00 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 00:53:00 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 00:53:00 -0800 (PST)
In-Reply-To: <88CAA5385EB5404392BF93106C8C53F8C334259045@HE111507.emea1.cds.t-internal.com>
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com> <56C5E77C.8030801@gmail.com> <56C6086C.9000703@gmail.com> <56C632D5.9000606@gmail.com> <56C6E1C8.2080907@gmail.com> <88CAA5385EB5404392BF93106C8C53F8C334259023@HE111507.emea1.cds.t-internal.com>  <88CAA5385EB5404392BF93106C8C53F8C334259045@HE111507.emea1.cds.t-internal.com>
Date: Tue, 23 Feb 2016 19:53:00 +1100
Message-ID: 
From: Mark Smith 
To: Holger Metschulat 
Content-Type: multipart/alternative; boundary=001a1143f2ac9debce052c6c1352
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 08:53:04 -0000

--001a1143f2ac9debce052c6c1352
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 Feb 2016 7:12 PM,  wrote:
>
> Hello Mark,
>
>
>
> thanks for the clarification. I should have said, their usage does not
require any changes to the network side of a 3GPP link. However, the usage
of 64share can be detected.
>
>

That may have sounded a bit snarky, however I've experienced enough
"transparent" devices that I'd prefer to call them what they actually are -
translucent. You can see through them, but they aren't actually transparent=
.

Regards,
Mark.

>
> Holger
>
>
>
> --
> Holger Metschulat
> Deutsche Telekom Technik GmbH
> Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt
> +49 6151 58 - 18671 (Tel.)
> +49 160 901 35443 (Mobil)
> E-Mail: holger.metschulat@telekom.de
>
> http://www.telekom.de
>
> Erleben, was verbindet.
>
> Die gesetzlichen Pflichtangaben finden Sie unter:
www.telekom.de/pflichtangaben-dttechnik
>
> Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an =E2=80=93 Ressourcen schone=
n und nicht jede
E-Mail drucken.
>
>
>
>
>
> Von: Mark Smith [mailto:markzzzsmith@gmail.com]
> Gesendet: Dienstag, 23. Februar 2016 09:11
> An: Metschulat, Holger
> Cc: Alexandre Petrescu; v6ops list
>
> Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
>
>
>
>
> On 23 Feb 2016 6:59 PM,  wrote:
> >
> > Hello,
> >
> > ... and these changes are transparent to the network.
> >
>
> Not if you can detect them, by, for example, crypto or other failures.
>
> They're better described as "translucent".
>
> > Holger
> >
> > --
> > Holger Metschulat
> > Deutsche Telekom Technik GmbH
> > Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt
> > +49 6151 58 - 18671 (Tel.)
> > +49 160 901 35443 (Mobil)
> > E-Mail: holger.metschulat@telekom.de
> > http://www.telekom.de
> > Erleben, was verbindet.
> > Die gesetzlichen Pflichtangaben finden Sie unter:
www.telekom.de/pflichtangaben-dttechnik
> > Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an - Ressourcen schonen und =
nicht jede
E-Mail drucken.
> >
> >
> >
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandre
Petrescu
> > Gesendet: Freitag, 19. Februar 2016 10:35
> > An: v6ops@ietf.org
> > Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
> >
> >
> >
> > Le 18/02/2016 22:08, Jouni Korhonen a =C3=A9crit :
> > >> I will get a capture soon.  What I suspect happening is the ppp
> > >> software
> > >
> > > And please get the capture from the GTP-U/C tunnel & its content that
> > > leaves the GGSN/PGW and also from the NAS signaling that the UE
> > > receives. Those tell quite a bit.
> >
> > That's going to be hard if not impossible.
> >
> > The 64share technique relies on changes on only the UE.
> >
> > Alex
> >
> > >
> > > - Jouni
> > >
> > >
> > >> ("cm" command) installing the LL default route and the RA installing
> > >> the GUA default route.  But I will see more tomorrow.
> > >>
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops

--001a1143f2ac9debce052c6c1352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 23 Feb 2016 7:12 PM, <holger.metschulat@telekom.de> wrote:

>

> Hello Mark,

>

> =C2=A0

>

> thanks for the clarification. I should have said, their usage does not=
 require any changes to the network side of a 3GPP link. However, the usage=
 of 64share can be detected.

>

> =C2=A0


That may have sounded a bit snarky, however I've experie=
nced enough "transparent" devices that I'd prefer to call the=
m what they actually are - translucent. You can see through them, but they =
aren't actually transparent.


Regards,

Mark.


>

> Holger

>

> =C2=A0

>

> -- 

> Holger Metschulat 

> Deutsche Telekom Technik GmbH 

> Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt 

> +49 6151 58 - 18671 (Tel.) 

> +49 160 901 35443 (Mobil) 

> E-Mail: holger.metschu=
lat@telekom.de

>

> http://www.telekom.de

>

> Erleben, was verbindet.=C2=A0

>

> Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttech=
nik

>

> Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an =E2=80=93 Ressourcen sch=
onen und nicht jede E-Mail drucken.

>

> =C2=A0

>

> =C2=A0

>

> Von: Mark Smith [mailto:mark=
zzzsmith@gmail.com] 

> Gesendet: Dienstag, 23. Februar 2016 09:11

> An: Metschulat, Holger

> Cc: Alexandre Petrescu; v6ops list

>

> Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a T=
hird Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
>

> =C2=A0

>

>

> On 23 Feb 2016 6:59 PM, <holger.metschulat@telekom.de> wrote:

> >

> > Hello,

> >

> > ... and these changes are transparent to the network.

> >

>

> Not if you can detect them, by, for example, crypto or other failures.=


>

> They're better described as "translucent".

>

> > Holger

> >

> > --

> > Holger Metschulat

> > Deutsche Telekom Technik GmbH

> > Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt

> > +49 6151 58 - 18671=C2=A0(Tel.)

> > +49 160 901 35443=C2=A0(Mobil)

> > E-Mail: holger.me=
tschulat@telekom.de

> > http://www.telekom.de

> > Erleben, was verbindet.=C2=A0

> > Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-d=
ttechnik

> > Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an - Ressourcen schone=
n und nicht jede E-Mail drucken.

> >

> >

> >

> > -----Urspr=C3=BCngliche Nachricht-----

> > Von: v6ops [mailto:v6op=
s-bounces@ietf.org] Im Auftrag von Alexandre Petrescu

> > Gesendet: Freitag, 19. Februar 2016 10:35

> > An: v6ops@ietf.org

> > Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix fro=
m a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN L=
ink

> >

> >

> >

> > Le 18/02/2016 22:08, Jouni Korhonen a =C3=A9crit :

> > >> I will get a capture soon.=C2=A0 What I suspect happenin=
g is the ppp

> > >> software

> > >

> > > And please get the capture from the GTP-U/C tunnel & its=
 content that

> > > leaves the GGSN/PGW and also from the NAS signaling that the=
 UE

> > > receives. Those tell quite a bit.

> >

> > That's going to be hard if not impossible.

> >

> > The 64share technique relies on changes on only the UE.

> >

> > Alex

> >

> > >

> > > - Jouni

> > >

> > >

> > >> ("cm" command) installing the LL default route=
 and the RA installing

> > >> the GUA default route.=C2=A0 But I will see more tomorro=
w.

> > >>

> > >

> > > _______________________________________________

> > > v6ops mailing list

> > > v6ops@ietf.org

> > > http=
s://www.ietf.org/mailman/listinfo/v6ops

> > >

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://w=
ww.ietf.org/mailman/listinfo/v6ops

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://w=
ww.ietf.org/mailman/listinfo/v6ops


--001a1143f2ac9debce052c6c1352--


From nobody Tue Feb 23 01:07:52 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01F41B3F5B for ; Tue, 23 Feb 2016 01:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpR3Roa1tlxw for ; Tue, 23 Feb 2016 01:07:50 -0800 (PST)
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 0760D1B3F58 for ; Tue, 23 Feb 2016 01:07:50 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id c3so155193074vkb.3 for ; Tue, 23 Feb 2016 01:07:49 -0800 (PST)
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:content-type; bh=FonVnxF+5wbrh4BU/UlaKHVBtxXUhEC6OpXrBqXQAXk=; b=oUjeOBN0x+JK379FtVcrbZZnTlTQL6FWlO1yNbLssG8rsl1MPbk3JYk4VeGWZQyoJ+ GE/Xr3qEITdviTD74d9IqFy8zZQ3LMou2adv3JXEqC/w3GYXf+p97f1rv4kDbdrXB79w 4GOCANfB0vGRElrLXW7HiTUVPFyWYPCMIzw9BV7nUvixKWoFCxg528Z3XwAWolE7BALQ f1qq4QSRQxMDmtzra+YDkXYstkP2NBIMDJE9oeLqLJ7V2dzHjnx8QuYPMBLc9RYXFeAi BAJyVhgYawo+HmhM2/VBnSJbnJckoYTVfOkH2W7ZqX74pi0yyCnMCzSavB2Hj/KRSQWS J8Hg==
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-type; bh=FonVnxF+5wbrh4BU/UlaKHVBtxXUhEC6OpXrBqXQAXk=; b=H5K7AZTrOMd0tJNIKemM+YMmEVE2hE3+ZmNR8wSfFmnQRjszO0nykkNFuc5SVvewE2 OQCZRGevwXjZiBZN55QQJRULnOJecb9EiVF1lfBJ0gijfUasNTs3wyuZTKLYOiNIxlWW Fg+bdZB5lBZR7u4oOud4rpEKuSSp+TOdo9DHwLB1c0JcgepOvD19THCLgbSvlTMOHmjR 07By++2KjkJD34RhrYxFWDJ/vGNB8bzFxlFIvSMcEwtW4J8A0JGaZg1AfCVUUmkthXwK 5d6F2neUrJxyXs+NR/VdkDUsAh4R1DXemsCFjvtKHgwHsQl0BvrDvw+PhVVCFN87kiMp HWXw==
X-Gm-Message-State: AG10YOTburp3eDVFRu/vLjL50jB+ZOYGWdExbHXcYQSCuqiqFTj+ix9L5rDjodUdcX1NWsF43CgKnWVV7nRGfA==
MIME-Version: 1.0
X-Received: by 10.31.58.83 with SMTP id h80mr27618480vka.149.1456218469129; Tue, 23 Feb 2016 01:07:49 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 01:07:49 -0800 (PST)
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 01:07:49 -0800 (PST)
In-Reply-To: <44eb12cca9714424b087c97628f3d51b@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org> <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com>  <44eb12cca9714424b087c97628f3d51b@XCH-RCD-005.cisco.com>
Date: Tue, 23 Feb 2016 20:07:49 +1100
Message-ID: 
From: Mark Smith 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=001a114389d4916cb2052c6c48e1
Archived-At: 
Cc: Tore Anderson , v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 09:07:51 -0000

--001a114389d4916cb2052c6c48e1
Content-Type: text/plain; charset=UTF-8

On 23 Feb 2016 6:43 AM, "Hemant Singh (shemant)"  wrote:
>
>
> From: Mark Smith [mailto:markzzzsmith@gmail.com]
> Sent: Monday, February 22, 2016 2:28 PM
> To: Hemant Singh (shemant)
> Cc: Tore Anderson; v6ops list; otroan@employees.org
> Subject: RE: [v6ops] p2p links without ND
>
> >Probably can't (/127s work reliably in RAs?) and don't want to in
residential broadband over PPPoE - customer being able to plug a PC
directly on avoids forcing them to buy a >router and is useful for
troubleshooting.
>
> I have already said if both ends of a p2p link are routers, then RFC6164
allows use of a /127.

I think you said use a /127, not that you were allowed to use a /127.

>Of course, the /127 is not configured using a prefix from the RA if that
is what you meant above.

What I meant was that I don't know if /127s can be conveyed in RAs, whether
residential CPE would handle them correctly, and even if they did, there
are good and valid reasons to use per customer /64s over their PPP/PPPoE
sessions.

> The /127 is configured manually at each end since the Subnet-Router
anycast address conflicts with the /127.
>

And certainly something you can't expect residential users to do, and a
portion of network engineers who don't pay attention to detail and who
aren't thorough.

> RFC6164 does not cover router to host or host to host p2p links.
>

Certainly not. The answer for p2p links isn't and cannot always be "use
/127s".

Regards,
Mark.

> Hemant

--001a114389d4916cb2052c6c48e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 23 Feb 2016 6:43 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

>

>

> From: Mark Smith [mailto:mar=
kzzzsmith@gmail.com]

> Sent: Monday, February 22, 2016 2:28 PM

> To: Hemant Singh (shemant)

> Cc: Tore Anderson; v6ops list;=
 otroan@employees.org

> Subject: RE: [v6ops] p2p links without ND

>

> >Probably can't (/127s work reliably in RAs?) and don't wan=
t to in residential broadband over PPPoE - customer being able to plug a PC=
 directly on avoids forcing them to buy a >router and is useful for trou=
bleshooting.

>

> I have already said if both ends of a p2p link are routers, then RFC61=
64 allows use of a /127.=C2=A0 


I think you said use a /127, not that you were allowed to us=
e a /127.


>Of course, the /127 is not configured using a prefix fro=
m the RA if that is what you meant above.=C2=A0 =C2=A0


What I meant was that I don't know if /127s can be conve=
yed in RAs, whether residential CPE would handle them correctly, and even i=
f they did, there are good and valid reasons to use per customer /64s over =
their PPP/PPPoE sessions.


> The /127 is configured manually at each end since the S=
ubnet-Router anycast address conflicts with the /127.

>


And certainly something you can't expect residential use=
rs to do, and a portion of network engineers who don't pay attention to=
 detail and who aren't thorough.


> RFC6164 does not cover router to host or host to host p=
2p links.

>


Certainly not. The answer for p2p links isn't and cannot=
 always be "use /127s".


Regards,

Mark.


> Hemant




--001a114389d4916cb2052c6c48e1--


From nobody Tue Feb 23 02:59:17 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367441B3A59 for ; Tue, 23 Feb 2016 02:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoVSqKokRHvP for ; Tue, 23 Feb 2016 02:59:14 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EAF1B3A3C for ; Tue, 23 Feb 2016 02:59:13 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id A29AFD7883; Tue, 23 Feb 2016 02:59:11 -0800 (PST)
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=RZlMyf7lgNoQq7/oBlp+8EfEUWQ=; b= U4tDVDZYVxmwi3F3LtfuB+WuTqo/5OUi4RmjpX7+AZYN907xCg/x0G7uOCgWwu5x J7GhG0KHwb57JXH1QNsg6478XoPv9bRlEsVRdzAooPDBUZ5ZfVi/RQmAr+SZbiac +ZvsiQP3/YOuF6tRUNXlgNoiDyusG9Y37Iv18aoH63Q=
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=pWV5YQi3EfdJgYAfvgTwFb87F5 D3ib8tol1SM0FZ1J5UY63dq3zA4vMsyVzZD+Hn1XIO8H/+ln+tKJ8tWb1lTGMz6F AN87VEFRgGP9bvEsRrcheLkICvspf8emggjM0Z8GqAi0A/x5QnOLcMLvUhnvigi+ qkSwzGGX8VV/XDlSU=
Received: from h.hanazo.no (unknown [173.38.220.43]) (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 371BCD7895; Tue, 23 Feb 2016 02:59:11 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E6FD4116A357; Tue, 23 Feb 2016 11:59:11 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_59516B63-833A-4D89-A1AC-51BDC9E3C827"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: 
Date: Tue, 23 Feb 2016 11:59:11 +0100
Message-Id: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
References: 
To: Mark Smith 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 10:59:16 -0000

--Apple-Mail=_59516B63-833A-4D89-A1AC-51BDC9E3C827
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mark,

MLD joins for the solicited node multicast address has turned out to =
have little practical purpose. I am thinking of going the other way and =
stop sending joins for link-local multicast groups.

Best regards,
Ole

> On 07 Feb 2016, at 20:25, Mark Smith  wrote:
>=20
> HI,
>=20
> I'm revisiting a few of my drafts that I've been intending to update,
> and here is the first.
>=20
> My basic realisation was that Solicited-Node joins also could serve as
> a low resolution address (or address space range) registration method,
> which could then be used by a router to determine whether it needs to
> send a ND NS or not. If the Solicited-Node group is present, send the
> ND NS, if the group isn't, then don't.
>=20
> This update adds a few sections and modes based on Lorenzo's feedback:
>=20
> - Strict and Relaxed discard modes. Universal discarding is Strict
> mode, Relaxed mode only discards if there is an indication a DoS is
> occurring, to allow for lower MLD reliability or implementations that
> don't support MLD
>=20
> - Some discussion on MLD reliability and how it would effect this =
method.
>=20
> Comments and suggestions appreciated.
>=20
> Regards,
> Mark.
>=20
>=20
> ---------- Forwarded message ----------
> From:  
> Date: 8 February 2016 at 06:14
> Subject: New Version Notification for
> draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
> To: "markzzzsmith+ietf-dt@gmail.com" 
>=20
>=20
>=20
> A new version of I-D, =
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
> has been successfully submitted by Mark Smith and posted to the
> IETF repository.
>=20
> Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
> Revision:       01
> Title:          Further Mitigating Router ND Cache Exhaustion DoS
> Attacks Using Solicited-Node Group Membership
> Document date:  2016-02-07
> Group:          Individual Submission
> Pages:          11
> URL:
> =
https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-ml=
d-slctd-node-01.txt
> Status:
> =
https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-sl=
ctd-node/
> Htmlized:
> =
https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-n=
ode-01
> Diff:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-mitigate-rtr-dos-mld=
-slctd-node-01
>=20
> Abstract:
>   For each of their IPv6 unicast or anycast addresses, nodes join a
>   Solicited-Node multicast group, formed using the lower 24 bits of =
the
>   address.  This Solicited-Node group membership could be used by
>   routers to further mitigate a Neighbor Discovery cache Denial of
>   Service attack.
>=20
>=20
>=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
> The IETF Secretariat
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail=_59516B63-833A-4D89-A1AC-51BDC9E3C827
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

iQIcBAEBCgAGBQJWzDt/AAoJEL7aWKiYQt92dM8P/iIHD6n5UeqtZEdHZiqeK83G
G6T0uNkqru6jN8JYptqWPMk5io5yK3XoD4su8DF+l2JIaL6ar4nChzWOP+6QpEb3
Ngi2XwiMnEMQT0ToZFT6aMa+iO3FTLpmEbzsjwTwatv3CkbK9zwlQC+oAv2YaxWN
1KDBNscGgd0nspJtJfKe8CzRKSNK832IgWcQAQPQjrFYZPtbolRFbaHd875EuVgL
v4EYkqt19h5L/XFsY7U7J2KlMLxtg+7SKQ4NUarUWoFgedwZhS8kIZe+cAm/8ZnN
oBHAIz+NcqU9MbNVeWE7MR7JmFbtZ1C2iWvxjbWlzyav7joK4NvBh1RE1Aw84X96
LASISLLuS7vHUZrWHIoWbEuQzTOsCDiCHPvlYsgjQlHCOt5bag2OP7vVFQuRKcmU
dze2RYbGUe9aP0kHymJABNoEiQzp+SGMRTSfLsfNCWLnKNcKhmwIZFTGxBtJT8Zg
acWl/yo6d97WroadKLW2Et6DzNHS70CL4u9ThCHuaED5qG3PI4YPaP4RV5fuYa/l
tKWXtKbaRTExLW6ZN8KbS+NTzwlPkKt5vaqvSRTWLmEEfWx6fI+epXV9QUnSYZDh
hH3iDxjNxhL1jYso8FcGPVBhKZ3RR6R0piAMa/F5VmmJT2BXBi25DvydZ3bG4Bhp
+nt/CRvIAnp2QRTr0Krg
=D18f
-----END PGP SIGNATURE-----

--Apple-Mail=_59516B63-833A-4D89-A1AC-51BDC9E3C827--


From nobody Tue Feb 23 03:07:38 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D351AD26B for ; Tue, 23 Feb 2016 03:07:37 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uVDkEReTmlW for ; Tue, 23 Feb 2016 03:07:28 -0800 (PST)
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 C62FD1B3CAC for ; Tue, 23 Feb 2016 03:07:27 -0800 (PST)
Received: from [192.168.3.107] (unknown [181.165.125.191]) (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 100DD80DA9; Tue, 23 Feb 2016 12:07:24 +0100 (CET)
To: "Liubing (Leo)" , "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" 
References: <56CBA254.2090107@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D45C70@nkgeml514-mbx.china.huawei.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CC3D40.1080007@si6networks.com>
Date: Tue, 23 Feb 2016 08:06:40 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D45C70@nkgeml514-mbx.china.huawei.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 11:07:37 -0000

Hi, Leo,

Comments only on those parts that needed additional "discussion"...

On 02/23/2016 12:41 AM, Liubing (Leo) wrote:
>> ** Technical **
>> 
>> * Section 1, page 3:
>>> The M and O flags are advisory, not prescriptive.  For example,
>>> the M flag indicates that addresses are available from DHCPv6,
>>> but It does not indicate that hosts are required to acquire
>>> addresses from DHCPv6.  Similar statements can be made about the
>>> O flag.  (A flag
>> is
>>> also advisory by definition in standard, but it is quite
>>> prescriptive in implementations according to the test results in
>>> the appendix.)
>> 
>> mm.. could you quote something from RFC4862 regarding these bits
>> "being advisory"?
> [Bing] In the previous version SLAAC (RFC2462), there was some nice
> prescriptive processing of the flags, but it was just removed in
> RFC4862 as stated "Removed the text regarding the M and O flags,
> considering the maturity of implementations and operational
> experiences...". I believe that is the main reason of why current
> OSes' behavior diverts.

It would be great if you could elaborate a bit on this.



>> * Section 2.1, page 4 (and other instances):
>>> 
>>> o  A (Autonomous) Flag
>>> 
>>> A flag is defined in the PIO, "When set indicates that this 
>>> prefix can be used for stateless address configuration as 
>>> specified in [RFC4862].".
>> 
>> This, as is, is misleading: I'd separate the analysis of "M" and
>> "O" -- which are mandatory in the RA header, vs the A flag, which
>> is only present in the PIOs, and hence is optional.
> [Bing] I agree with you that separating them is more logically clear.
> But the trouble thing is, according to Divergence 2-1 (in Section
> 4.2), A flag and O flag have some relationship in some OSes. So I
> just felt it had to be discussed together. Do you have any
> suggestion? I'd be glad to hear. Thanks.



>> * Section 3, page 4:
>>> More specifically, it is unclear whether RA (with M=1) is
>>> required to trigger DHCPv6; in other words, It is unclear whether
>>> hosts should initiate DHCPv6 by themselves if there are no RAs at
>>> all.
>> 
>> This is confusing. There are two different cases here: M=1 -- for
>> which I don't think there's any ambuiguity, and no RA, in which
>> case there is.
> [Bing] I think we're talking about the same thing. However, the text
> intends to emphasize in another perspective: if "no RAs" is
> ambiguity, it means some OSes just wait to the M=1; if they don't see
> it, they just don't do DHCPv6. This implies a dependency relationship
> which in my mind is not proper.

Ok, now I see what you mean. However, looking at RFC4862, this is a
lowecase "may".



>> * Appendix A, page 12:
>>> 
>>> The authors from two orgnizations tested different scenarios 
>>> independent of each other.
>> 
>> It's not clear from this text whether you tested the same thing, or
>> different things (i.e., no overlap, partial overlap, or full
>> overlap of the tests).
>> 
>> While it is valuable to indicate that multiple tests were
>> performed independently (i.e., they were validated), what's useful
>> from the pov of the reader is to get the aggregate of the tests,
>> possibly in a table.
>> 
>> If all the overlapping text shielded the same result, please say
>> so, and just publish the aggregate of the results. If the same test
>> shielded a different result in each of the test scenarios, please
>> note which ones, and try to explain why the same test shielded a
>> different result.
> [Bing] Good point, thanks. The two tests were partial overlapped, and
> the overlapped part was consistent in results. We just aggregated the
> results as Section 4, and keep the raw details of the two tests in
> the Appendix. When people read the document, we assume it is
> sufficient to get aware of the problems from the main body text; and
> if somebody interested in the test details, then he/she could get it
> in the Appendix. Do you think it's ok?

I'd just keep the aggregate results. i.e., if both independent test
shielded the same results, then there's no need to provide details about
the two testing setups.

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





From nobody Tue Feb 23 04:15:25 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F091B42E4 for ; Tue, 23 Feb 2016 04:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level: 
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og3rps6RVPoF for ; Tue, 23 Feb 2016 04:15:23 -0800 (PST)
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 5F3B21B42DD for ; Tue, 23 Feb 2016 04:15:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=916; q=dns/txt; s=iport; t=1456229723; x=1457439323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+I5mw7gWA9XQcgPWjcT6HyyqfV/eYMJKkI8r/TJIVKI=; b=Oy4w2i4foq82VmsAau//UCXGQwPOSCjrZbAFEXHXHDztiWzWzd3xEHer sMydO+fhLrqNn/eKk/Jcwh7jZc9XK3+fCuk5u5K9asv1qFFJ60oKimdm4 tobeQiGsRrlYVBKhWx7DaTkNE47WpRgkeRiitC1FJcdhL5EdE8/1QYEpM 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAgBkTMxW/49dJa1egzqBPwazPIciA?= =?us-ascii?q?Q2BZoYNAhyBKjgUAQEBAQEBAWQnhEEBAQEEIxFFEAIBCBEEAQEDAiMDAgICHxE?= =?us-ascii?q?UAQgIAgQOBQiHfgMSrRCKKQ2EMQEBAQEBAQEBAQEBAQEBAQEBAQEBARV7iVGCO?= =?us-ascii?q?oR7gToFlwcBi2qBbI54hwWHQwEeAQFCggMZgUhqhzx9AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,489,1449532800"; d="scan'208";a="241473365"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 12:15:22 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1NCFMH3006302 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 12:15:22 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 06:15:22 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 06:15:21 -0600
From: "Hemant Singh (shemant)" 
To: Mark Smith 
Thread-Topic: [v6ops] p2p links without ND
Thread-Index: AQHRbOZUmY0YgiwNmk+VNMXlq9OMlJ83cM6AgACo3wCAAAF7AIAAFW2AgAAL1wCAAAOiAP//wAiwgADY14D//56ToIABRp6A///ObYA=
Date: Tue, 23 Feb 2016 12:15:21 +0000
Message-ID: <0a63ca28e3834e49aba4f0fc338db4b6@XCH-RCD-005.cisco.com>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org>  <442195BD-1F54-450B-A265-03BF05638F54@employees.org>  <33C1108E-D6A3-45BB-AEE7-90B18923F9B2@employees.org> <157e12b40b8e4ba3a784dffebc0ac698@XCH-RCD-005.cisco.com>  <44eb12cca9714424b087c97628f3d51b@XCH-RCD-005.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: [10.82.229.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Tore Anderson , v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 12:15:24 -0000

DQoNCkZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXSANClNl
bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE2IDQ6MDggQU0NClRvOiBIZW1hbnQgU2luZ2gg
KHNoZW1hbnQpDQpDYzogVG9yZSBBbmRlcnNvbjsgT2xlIFRyb2FuOyB2Nm9wcyBsaXN0DQpTdWJq
ZWN0OiBSRTogW3Y2b3BzXSBwMnAgbGlua3Mgd2l0aG91dCBORA0KDQo+V2hhdCBJIG1lYW50IHdh
cyB0aGF0IEkgZG9uJ3Qga25vdyBpZiAvMTI3cyBjYW4gYmUgY29udmV5ZWQgaW4gUkFzLCB3aGV0
aGVyIHJlc2lkZW50aWFsIENQRSB3b3VsZCBoYW5kbGUgdGhlbSBjb3JyZWN0bHksIGFuZCBldmVu
IGlmIHRoZXkgZGlkLCB0aGVyZSBhcmUgZ29vZCBhbmQgdmFsaWQgcmVhc29ucyB0byB1c2UgcGVy
IGN1c3RvbWVyID4vNjRzIG92ZXIgdGhlaXIgUFBQL1BQUG9FIHNlc3Npb25zLg0KDQpDZXJ0YWlu
bHkgIGEgLzEyNyBjYW5ub3QgYmUgdXNlZCBpbiBhbiBSQSBiZWNhdXNlIHRoZSBhZGRyZXNzIGhh
cyB0byBiZSBjb25maWd1cmVkIG1hbnVhbGx5IGR1ZSB0byBjb25mbGljdCB3aXRoIHRoZSBhbnlj
YXN0IGFkZHJlc3MuICBBIHJlc2lkZW50aWFsIENQRSBoYXMgdG8gdXNlIGF1dG9tYXRpYyBtZWFu
cyBmb3IgYWRkcmVzcyBjb25maWd1cmF0aW9uLg0KDQpIZW1hbnQNCg==


From nobody Tue Feb 23 07:02:42 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12331B308B for ; Tue, 23 Feb 2016 07:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4II0FEKMyLc9 for ; Tue, 23 Feb 2016 07:02:37 -0800 (PST)
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 147F71B307C for ; Tue, 23 Feb 2016 07:02:36 -0800 (PST)
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 u1NF2Y4T022469; Tue, 23 Feb 2016 16:02:34 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 137EA20668E; Tue, 23 Feb 2016 16:02:41 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0503E202EE1; Tue, 23 Feb 2016 16:02:41 +0100 (CET)
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 u1NF2XbZ014794; Tue, 23 Feb 2016 16:02:33 +0100
To: holger.metschulat@telekom.de
References: <20140626205546.713F21801AE@rfc-editor.org> <56C490DE.8000406@gmail.com>  <56C5838D.2020808@gmail.com> <88CAA5385EB5404392BF93106C8C53F8C33425901E@HE111507.emea1.cds.t-internal.com>
From: Alexandre Petrescu 
Message-ID: <56CC7489.6070100@gmail.com>
Date: Tue, 23 Feb 2016 16:02:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <88CAA5385EB5404392BF93106C8C53F8C33425901E@HE111507.emea1.cds.t-internal.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 15:02:41 -0000

Le 23/02/2016 08:57, holger.metschulat@telekom.de a ĂŠcrit :
> Hello,
>
> the /64 GUA is exclusive to the UE. The network does not have any
> address in the /64 GUA block allocated to the subscriber.
>
> This link is PtP. Link-local addresses are provided by the network to
> both the UE and the "network end", which is the GGSN, as with any PtP
> link.
>
> What you see on the mobile OS is not necessarily what is happening on
> the link. Modem chipsets try to translate between the Ethernet
> interface offered to the OS and the PtP 3GPP interface:
>
> - MAC addresses are emulated since they are required by the Ethernet
>  interface to the OS,

In many cases the MAC addresses are emulated, but some are more emulated
than others.

For example, some LTE User Equipment generates the entire MAC address in
a pure random manner (e.g. sierra) whereas other UEs have the first
three bytes of that MAC address centrally allocated by IEEE (e.g.
qualcomm) and the last 3 bytes 0.

> but not existing on the 3GPP link

Are MAC addresses absent from both 3G and 4G?

I am asking because I find it strange for these large companies like
qualcomm and huawei who produce chipsets for the 4G devices (but not
wifi devices) to reserve (pay) OUIs at IEEE if it were not for an
intention to use MAC addresses on the cellular link.

> - The 3GPP link mandates that the UE uses a special link-local
> address which is prescribed by the network. Most OS stacks however
> create the link-local address on their own, therefore, the modem
> chipset translates between the two.

I am not sure what you mean by modem chipset, but I am talking about a
"module" which has everything inside a large chip.  It's not like the
laptop computer on which one plugs a USB dongle containing a modem.

> - There is no ND happening on the 3GPP link (since it is PtP)

On other Point-to-Point links there is very well ND happening.  A point
to point link using a tunnel interface has ND running on it ok (e.g.
IPv6-in-IPv4 tunnel, or VPN tunnel, or MR-HA tunnel).

> the modem chipset terminates the ND requests from the OS and
> responds on its own.

I think I need to better understand the interaction between "OS" and
"modem chipset".

But I would like to suggest that 3GPP specs could take advantage from
using directly ND on the not-so-ptp links, and use unique MAC addresses
as allocated by IEEE.  For example, 3GPP could make LTE-D2D more real by
relying on these MAC and ND concepts.

Alex

>
> Holger
>


From nobody Tue Feb 23 10:47:03 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4871A21BC for ; Tue, 23 Feb 2016 10:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPwGSbO381Nv for ; Tue, 23 Feb 2016 10:46:59 -0800 (PST)
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 536FD1A21AA for ; Tue, 23 Feb 2016 10:46:59 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id c10so120516362pfc.2 for ; Tue, 23 Feb 2016 10:46:59 -0800 (PST)
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-type :content-transfer-encoding; bh=nnwLmHnMEMTDRFhIN15E/tKM/MSArwRQnh9JSb8FER4=; b=KpkPJYOivu4uyYptQ2QQ/BaUvK8+Ga7RDlraixbLpljPbpRT7phtmQJsDPb2EQ9dN4 LJF5OATef2Ee5L8VmSIVAhej26QrHzgJgRbaQFuhSloV2JmJlZbKUF7ra97wBYr40jyr 7xQVSwiVNan90ntN5AnL4n1VOyoMK51LBCNywy7i9FDQSKa4APF+LYmQY/qbwTcPQdBK NiLyk1TFrNGou7wRwVIOXHAzfJvzXq5rFnMoA8CDZQUBzmAb2Gl1JBU5BuiieZLCWrfX CwYV/0NTHsFvr3GcDHxCFR3LsNfldkoiDZKByFjIsOsmfNWLqRFFy66nphxiqeBVmDoK 2+XA==
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-type :content-transfer-encoding; bh=nnwLmHnMEMTDRFhIN15E/tKM/MSArwRQnh9JSb8FER4=; b=KVZOwTq+ROt8PKBwyX3bCCi42qxfkIG10VbO5riieRBfrLBftRevtbq0GbFZ+6oGRO hr+u3rvuKGuGI07i9HpKqHu7VuXl74pGYYz9+0m0cxC1w+YLNt7P4nRFppD++JXMWul5 PAZcL4KJTh7bnsg6+JMmCYkreRl5tyKGCbmfuy1fpKCTl17nuCmkuT0KEEKVj7JYJSWZ s/rPHvhI4+5RP3X+3vYdX1ZxnFiofTmR5leMVH8qgFkOPBo0HaVoeWE8H8xJhdfsmEgr SWzmGIwQbJ31AM2fDx54hgG6RYdOrfZSwBioxacJiuig/bFB+PDhEAuwlSpXikQXsMBB iMAA==
X-Gm-Message-State: AG10YOT1oxo/zpSvDWrEWOOlcYGeysJIwdd5p4dJ/HyHqIsUvcFZCysyZdOqNZghJ5aGKw==
X-Received: by 10.98.33.77 with SMTP id h74mr47987417pfh.157.1456253218717; Tue, 23 Feb 2016 10:46:58 -0800 (PST)
Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 19sm45774027pfb.64.2016.02.23.10.46.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 10:46:57 -0800 (PST)
To: otroan@employees.org, Mark Smith 
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56CCA922.6020907@gmail.com>
Date: Wed, 24 Feb 2016 07:46:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 18:47:01 -0000

On 23/02/2016 23:59, otroan@employees.org wrote:
> Mark,
> 
> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.

Yes. What is the possible use of a link-local "join"?  The packets are just there
on the link anyway, so "joining" is entirely an internal matter for each node.

However, it is the case that some switches are not transparent to LL multicasts
to arbitrary addresses. For example in some tests I did recently, the lab switch
was transparent to ff02::1 but opaque to ff02::114.

    Brian

> 
> Best regards,
> Ole
> 
>> On 07 Feb 2016, at 20:25, Mark Smith  wrote:
>>
>> HI,
>>
>> I'm revisiting a few of my drafts that I've been intending to update,
>> and here is the first.
>>
>> My basic realisation was that Solicited-Node joins also could serve as
>> a low resolution address (or address space range) registration method,
>> which could then be used by a router to determine whether it needs to
>> send a ND NS or not. If the Solicited-Node group is present, send the
>> ND NS, if the group isn't, then don't.
>>
>> This update adds a few sections and modes based on Lorenzo's feedback:
>>
>> - Strict and Relaxed discard modes. Universal discarding is Strict
>> mode, Relaxed mode only discards if there is an indication a DoS is
>> occurring, to allow for lower MLD reliability or implementations that
>> don't support MLD
>>
>> - Some discussion on MLD reliability and how it would effect this method.
>>
>> Comments and suggestions appreciated.
>>
>> Regards,
>> Mark.
>>
>>
>> ---------- Forwarded message ----------
>> From:  
>> Date: 8 February 2016 at 06:14
>> Subject: New Version Notification for
>> draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
>> To: "markzzzsmith+ietf-dt@gmail.com" 
>>
>>
>>
>> A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
>> has been successfully submitted by Mark Smith and posted to the
>> IETF repository.
>>
>> Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
>> Revision:       01
>> Title:          Further Mitigating Router ND Cache Exhaustion DoS
>> Attacks Using Solicited-Node Group Membership
>> Document date:  2016-02-07
>> Group:          Individual Submission
>> Pages:          11
>> URL:
>> https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
>> Htmlized:
>> https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
>>
>> Abstract:
>>   For each of their IPv6 unicast or anycast addresses, nodes join a
>>   Solicited-Node multicast group, formed using the lower 24 bits of the
>>   address.  This Solicited-Node group membership could be used by
>>   routers to further mitigate a Neighbor Discovery cache Denial of
>>   Service attack.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Tue Feb 23 10:53:27 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6AA1A6FBA for ; Tue, 23 Feb 2016 10:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5A9L8gaii8Z for ; Tue, 23 Feb 2016 10:53:24 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F911A6F87 for ; Tue, 23 Feb 2016 10:53:24 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CE479D7895; Tue, 23 Feb 2016 10:53:22 -0800 (PST)
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=fETDvAMqivYLVUOuMuDLU2+Rqu0=; b= QFQfPSZ3owPoOFNQMAJwRM5hi8cM4XxziU6XzNsGttJAAtxupWQmPKbqzrlnNxrr Zbz6BBAMpHMgZQ3oxK1GEc+ovEfcSBMgAxYOuHD+/IRftK1KT3+r6iG7TO/rPz8C 6ZGK6Dgyw9H7qqzFAWqJtYtYSZEJwnuI3+etfyRo/ik=
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=R5YPQPBGOrWzJGRaXLWJnpqKG/ Y6cFbTWmfBd1fAEzc/hxi5KtXKSCRbcOLVZWIlPHSiFB4Plw41wAglhihU8+18QO tdCecIE0CFywO6lGrj2HDmytBUFUpIsbjugEG+sgDY1Ij2VcwF7d12Tq+csFCxEB e3e6nrY/zq4+kQrH4=
Received: from h.hanazo.no (unknown [195.159.234.46]) (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 9E38AD7884; Tue, 23 Feb 2016 10:53:22 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CF54C11708B2; Tue, 23 Feb 2016 19:53:19 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CDC9A3D2-B1BF-468C-8D10-2905B2AA11B3"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56CCA922.6020907@gmail.com>
Date: Tue, 23 Feb 2016 19:53:18 +0100
Message-Id: <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org>
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 18:53:26 -0000

--Apple-Mail=_CDC9A3D2-B1BF-468C-8D10-2905B2AA11B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> MLD joins for the solicited node multicast address has turned out to =
have little practical purpose. I am thinking of going the other way and =
stop sending joins for link-local multicast groups.
>=20
> Yes. What is the possible use of a link-local "join"?  The packets are =
just there
> on the link anyway, so "joining" is entirely an internal matter for =
each node.
>=20
> However, it is the case that some switches are not transparent to LL =
multicasts
> to arbitrary addresses. For example in some tests I did recently, the =
lab switch
> was transparent to ff02::1 but opaque to ff02::114.

it was presumably snooping on MLD and did forward when it had received a =
join for ff02::114?
the switch designers I've spoken to state that they cannot scale for the =
number of multicast groups, in particular solicited node multicast. I =
think they often do an exception for ff02::1 and treat that as =
broadcast.

cheers,
Ole

--Apple-Mail=_CDC9A3D2-B1BF-468C-8D10-2905B2AA11B3
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

iQIcBAEBCgAGBQJWzKqfAAoJEL7aWKiYQt92b24QAMv+UTax5u2coB0wnXUbbPDV
lPeUhbuan1JUeHeqI5py22s5BxBy8UL68z9irz8jknp7a2jEWA+Y1/3jt1UR/0+g
eGvUoE7B83HWoCasyRMbxsmoQrKRXigk3z6Pu8PnxgKfql836u2B1AFxtwJx9qEF
6omneKtABDDfxSAsvFmjLe5kFjzEndmaZhG89XLRSDWPlcsijW63NPeF2l/uqnKD
QDKI1bSzsiHpaN+xetNwbgcP2IGyY8aFUcLiCH1RrOjlKr7Fo01bv4yDPL9OAbI2
osY7iiLMh0r8VJZMkaJDx2KZ7F7HoLJASoyF7VP58Z9WZ+jttdcRCLE/+/j/P7rj
zMGUbnBUOGpYmiD3htd+JfhBsqMQwK9F+bCap3wKFMe9uDvsd78PkxYQyMhcX1nM
W554XSSHy5/I4s1QGA1+iBMRHwTRexBA9686TPFhH7/SoYBhQyeGPqvI7eu6BcBb
6yky45ukz+vimUYyCn0m+QfBRjxZ0DsoxiZIOehLj/4UJZP4EHCmpDvGmQkSojQL
cMWrfQigiQQjIUqdpjOnLjqRTIzHPgtvRvNGW/CyuuCT0bZ23DUbeXY9kiVAMzOa
vJ1vXp7piXpZuBPOn+ojPlPciSE6yq3U1s/L7jlsVMwY4qTOs7kbfY/rEYqZ+VLf
HZlECVsUj1nXW1xLLJmm
=k9vL
-----END PGP SIGNATURE-----

--Apple-Mail=_CDC9A3D2-B1BF-468C-8D10-2905B2AA11B3--


From nobody Tue Feb 23 11:01:24 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC071A8028 for ; Tue, 23 Feb 2016 11:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5N259ejU9da for ; Tue, 23 Feb 2016 11:01:21 -0800 (PST)
Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776B81A8852 for ; Tue, 23 Feb 2016 11:01:21 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0O3000D00KHIZO00@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Tue, 23 Feb 2016 13:01:20 -0600 (CST)
X-Spam-PmxInfo: Server=avs-2, Version=6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.23.185416, SenderIP=0.0.0.0
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPS id <0O3000G7ZKU53190@smtpauth2.wiscmail.wisc.edu>; Tue, 23 Feb 2016 13:01:18 -0600 (CST)
Authentication-results: employees.org; dkim=none (message not signed) header.d=none;employees.org; dmarc=none action=none header.from=wisc.edu;
Received: from havarti.local (72.33.0.210) by DM2PR06MB318.namprd06.prod.outlook.com (10.141.103.149) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 19:01:16 +0000
Date: Tue, 23 Feb 2016 13:01:06 -0600
From: "Dale W. Carder" 
To: otroan@employees.org
Message-id: <20160223190106.GA11971@havarti.local>
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org>
In-reply-to: <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [72.33.0.210]
X-ClientProxiedBy: BY1PR19CA0012.namprd19.prod.outlook.com (25.162.139.150) To DM2PR06MB318.namprd06.prod.outlook.com (10.141.103.149)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR06MB318; 2:HotRtoUhLcIf4MZ+NOE4AIVJpFJhiOijj4WcKUzRUP+ZgRzWfaFYX5fSeSh5a2kReP7tYccUDuzItOYuNAUseZdzzsgaB2b+dhNwHlhry7BgrFMUztftaZyNgeq11Gugm4c8blK7e61sjZ6DbYCoFg==; 3:3ZzeFqmmSBNfu0sg73agnfjfLDu50xSaRgEqaoq5IEYYH3ddLxx4ByXgEeMuzYISFPP8GV63Ntf//wJ1nJfDJHkymsAyBA2RzdRShWhq9eVRii8NK6caZWqb355fbv1b; 25:5xf3xR1k670mSZ9YF4IcELlpDPAByWSWZWfIm8R3/xgJTPz5OYw20IuuHl88nAE1/imkLScFBtAYP/dxVMLd7uvyCbu7wldk58NbZPIYGbafSTwObaPe/H58ru+cWzbOU+22kpl8qg6KytDurNaaeEuhVpngizMMFSTHPuwbXFSTarN7w0ncg6SDUlVAr/HfV9TScIiRhsXJEw6F9xZA1QwybtWBeyg1Rlez/pinxQ8Ps6aydu8hITmcvl8TEStl7dgfbzoT0bpXXD2Q49jDLKlEWkRak4f7jkwGtHDVBIEcUBxgpACk6I9BGsJfSLfN1i+zT9jL9Wgs98UA6qxW/J84ZO19R/hwXodqPU5O6sk=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR06MB318;
X-MS-Office365-Filtering-Correlation-Id: 5f0ba8f6-8017-4120-78c0-08d33c83b566
X-Microsoft-Exchange-Diagnostics: 1; DM2PR06MB318; 20:8gWcIkLwq7wqBHLea83ucTlkjVwZnawiiOgr60yw+m5+kJEPyx+HG9sWjXWCx01n287ilWBE2biwYfDIVC3z5sZl0EdWzZHtqlap4rBwD+EQOvK3FxEpNGkAoTnC9HaQIjjHSc3ydCd0jGLscCHgitkaOqiKDG+cOciM54SfOHzqthdrP78q9rqhv8wynBGOyyDg9xwrTWs1gkmvWdIvcitB61Cu9xrWVa8Z0tMSoF+G2kuAmGF70c0sagCELn4aF4beOzPcd2lFZpdB8XCxqsB6ZuujStoKgy+Z2ApoHm06mhPqFu7Ba9LM9msYEVUVkmNXk686lFhu19q2HX+ixzN/jyZxmqeqNIAtT28+1pU=; 4:v7e+u0P1RPZD2RCbp3GIDzMomX7TXbd3pfU76OyZR37PE2Jp2nKdyvDjhyCqn3Sahxpr7FvPZMFVWDQh9npZES70ZTfiaxKyF97wPfjQAOrgnNnAC1AA5hgtflz4BPViB5180/Igk4zO/Jx/3i7YKkLAItVkg73SIdpe23fbivLUV8GlSal6v2631V4nWXgVg6LobtMy1GFGVZq5IoDyYZwJ2fCN14jydtwqAAZd27vUjn+rwoqzWS9xmmq0euH5ypPZmEPCYIK6vYkXznPQohbEbxYfkD/gsjKT9xi+7QoGN8sTFpslfeVkxCxWeZqadmrDq+9CZZ9kwmm3bYfHp0MUP66pUiDvzz5NYaPEc0BvX22YWy7v+p87iiaS/Ixt
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR06MB318; BCL:0; PCL:0; RULEID:; SRVR:DM2PR06MB318; 
X-Forefront-PRVS: 08617F610C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(52314003)(2950100001)(50466002)(77096005)(122386002)(19580405001)(40100003)(90282001)(19580395003)(3846002)(4326007)(6116002)(586003)(46406003)(5008740100001)(1076002)(5004730100002)(2906002)(93886004)(83506001)(88552002)(23726003)(87976001)(92566002)(50986999)(76176999)(54356999)(89122001)(97756001)(2351001)(98436002)(47776003)(33656002)(189998001)(4001350100001)(66066001)(42186005)(5001960100002)(75432002)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR06MB318; H:havarti.local; FPR:; SPF:None;  MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR06MB318; 23:+TR6HXCO1isc/ueijfhVEF+epEpsEQiYOnbsQGGH8r?= =?us-ascii?Q?2GxF2ZcK1hAniV3Qnvav6Bi9L2LkUlJDspv8wRZJ2FxE/33R6IFi7hzcprcZ?= =?us-ascii?Q?NGqPq8Ixlc/RDsZo/WZClrjUDTvhLtTZskDm4mlP5Mm46nqVL33IJjsJirRf?= =?us-ascii?Q?ePeEGNpd/rZ66SgBBn8M96IbD8YqUY4atLs1Rvhn6tizZxOMpGOQw94fJ+LP?= =?us-ascii?Q?zlfbXlNR2Dt1DOBJ9yeES5if1olNpmFozP/opLZhxcLZKle2udSQWPAlFXpu?= =?us-ascii?Q?K9lFHoJwoNjjbfaHLyY7b5SiUpc/aXIzX6L1+0fcuGYZeqnN5eF82mhMBz7d?= =?us-ascii?Q?3PXr+Q1GtVM4OOpmhNVaLCtFhDPLQhfwEcUhXwen50Mc/rQJ7T/kmnIGLpKO?= =?us-ascii?Q?BI/iJss0raEH30BFdanD35nFc3zEYp27itBmng4/xBWsF90iIH/BD+nJqw6i?= =?us-ascii?Q?KLJO0RLv9InegmblQDRJwZqI+8TE4+GFNcYWFwce53Y+nuXSeA7FHurExN1R?= =?us-ascii?Q?xvdb2jNIRtjR2hLHaWZ9Vu7olfEkds7LN9JbDB3PP3LV1vNxenR56GRJolC4?= =?us-ascii?Q?BRzw6IzzAQIgkwHQMYmwjWXSh49QJCXLt6dhMq4CejnJ2dNuu7wxABOFTPOH?= =?us-ascii?Q?gMav/oglLNpSZynk7elJr9b3gS9r8LSkWf9AWzE3E1t5S2gCXmb4j1W+sL+a?= =?us-ascii?Q?6Eg22Jn4s9//4Isb64RdfLI3W/VgTfEVpIhosofPD4zx/pblUFrZGraUm6qr?= =?us-ascii?Q?JXWFQpH+O9+i5ruQQPXmB16WYvUAkut4Ml2L0jFVQ7yRaRdVLV1raVexZhML?= =?us-ascii?Q?xeXOiPOzpyBT05EapXKAFrqZpkWUXkCikvQ1JpNUGiWjjSfD25j9UeEmZ3D9?= =?us-ascii?Q?hq7H8hmPzkT2KBPRbW7TlyJKwoAkgr/tBUGc+z7M+56eL2GV6CQS2xCL/C+O?= =?us-ascii?Q?EBBpssQEnQykt+nD+d12GWzHKGIwgpJOL6uX95AptWuLRK09zKn22hkSrN75?= =?us-ascii?Q?FY1pnvobrxl1EhJteWaYqS4pT/LsFdXGAIWE7rZ12Sn32Z0Fe3nCeVMqmL5J?= =?us-ascii?Q?pMw9W+uHHz9QKD8HXFXSL0PjMfu95eJnA5wB9ook0D6Wfk5IlqwsO1+6auUa?= =?us-ascii?Q?FA1xFE7LY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR06MB318; 5:SQhD/9kL3BjA7UgLM0XxZoLy0hS8yl5yvaxM28WQwgj4WacBcoTpXSBK4xAiM5T2Sastq1D1qiTz4HPYG44exYLWB6JeGGMULWwASZRU4NLTG1SPKubCz2ckYDAd7DZtIlVZ/iCOyExMJ5j50VSo4w==; 24:D9WOYa+fP8nUUQdxkfbkMkauP52YzbtiFFe2FNJZ5X5yN8JTRwN2icDtASSCN+AFRqaRyFOXD6mNYqHQTcYFazT4ls/xCr16Qti7DUiq+B8=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2016 19:01:16.2410 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR06MB318
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:01:23 -0000

Thus spake otroan@employees.org (otroan@employees.org) on Tue, Feb 23, 2016 at 07:53:18PM +0100:
> >> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.
> > 
> > Yes. What is the possible use of a link-local "join"?  The packets are just there
> > on the link anyway, so "joining" is entirely an internal matter for each node.
> > 
> > However, it is the case that some switches are not transparent to LL multicasts
> > to arbitrary addresses. For example in some tests I did recently, the lab switch
> > was transparent to ff02::1 but opaque to ff02::114.
> 
> it was presumably snooping on MLD and did forward when it had received a join for ff02::114?
> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast.

Newer implementations might, but many commonly deployed platforms by
default do snooping that results in loss of multicast traffic.  I think
only very modern platforms can excempt this.

Particular cases we have seen also include loss of RA's (made worse by
a router that can't do solicited unicast RA when possible).  At our site
we now have to flood all ipv6 multicast.

Dale


From nobody Tue Feb 23 11:07:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F21A8A6A for ; Tue, 23 Feb 2016 11:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgzWuSK3L70M for ; Tue, 23 Feb 2016 11:07:47 -0800 (PST)
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 AD1801A8A68 for ; Tue, 23 Feb 2016 11:07:47 -0800 (PST)
Received: by mail-pa0-x22a.google.com with SMTP id fy10so114733113pac.1 for ; Tue, 23 Feb 2016 11:07:47 -0800 (PST)
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-type :content-transfer-encoding; bh=NkxgnNUS4lDfMQ1y/dq7WUEV8A6Ssc7S8tF5H8F8Xqc=; b=zIuvV+X2SqI3lzdH90sPUQZJ6MttJtsalO+INfe9uf+oQ+NDcY2d39ZtfCoJSVjA+k +ClZ/N/eMHxQdWUeeC5uKd6aYDAzBa9WoIyr1X4vdbMv+41TMxIZKeAOJpizsg6+puXE 7VmLIsJQFWrZUJIDPo/v/ALfuuvWZ086yfupsOCTHumrZ4K/9VqGDUA0B9rTK2au5PxS Qn/e3tClZ2KdpDRCt2ARsLoBzaQ8ibHecyDZn+jMmhm/med0Cv97bWP/znfLPFLv+jI6 X5CaXx44lgTeDDEx4qNpS14PLQWgvldiR94BSY2xG6w0UrznCOZF6AeVH6+/jSlbTVf3 RVgg==
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-type :content-transfer-encoding; bh=NkxgnNUS4lDfMQ1y/dq7WUEV8A6Ssc7S8tF5H8F8Xqc=; b=NR/6L/zFLsEiDeKXT0bJlsEPHpZ0JJfIqUybwH/gfVE+1rcRnmdbacUp+yEPH+hEfn 7OFgVQvFRZm3zCKuO7XPIUWTyl10+R+uMB3EsBTikRpoOcCGT/ZM2j+mFeLxxDyeM57b pKqGQDu4TJq+XBTUjSSApXej2CAvsI/oCKdHinWOaeDqX7ot+b0zXtX0o+AOTBO9z7Jk 9fTuWRYCu/YBkcGfRMhQMgvC0QHsfyp2McYZtMZ5Q991PCOP2XfHjqIt1PFTbzMmgJCR ejaCVMM+6KvJfcVkM3nwXazJGvDqGuZbDRHHe/UFi05LCrDVuigxmu7SJOTWEYwaHe1m m/Yw==
X-Gm-Message-State: AG10YORE9flKNZ8paJlDdJCJR39tD6BegjzfkbT2RcpWutYQFuT8q0dUMF40pRroLhvk5Q==
X-Received: by 10.67.8.100 with SMTP id dj4mr48665472pad.88.1456254467319; Tue, 23 Feb 2016 11:07:47 -0800 (PST)
Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b2sm45913256pfd.24.2016.02.23.11.07.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 11:07:45 -0800 (PST)
To: otroan@employees.org
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56CCAE04.6010308@gmail.com>
Date: Wed, 24 Feb 2016 08:07:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:07:49 -0000

On 24/02/2016 07:53, otroan@employees.org wrote:
>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.
>>
>> Yes. What is the possible use of a link-local "join"?  The packets are just there
>> on the link anyway, so "joining" is entirely an internal matter for each node.
>>
>> However, it is the case that some switches are not transparent to LL multicasts
>> to arbitrary addresses. For example in some tests I did recently, the lab switch
>> was transparent to ff02::1 but opaque to ff02::114.
> 
> it was presumably snooping on MLD and did forward when it had received a join for ff02::114?

Possibly. I fixed the problem by inserting a dumb bridge that does what bridges
are supposed to do.

> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast.

But why not pass all LL multicasts?

Anyway, if this is common behaviour by switches it has to be allowed for.

    Brian

> cheers,
> Ole
> 


From nobody Tue Feb 23 11:09:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825A1A8AE8 for ; Tue, 23 Feb 2016 11:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2raJEJXKkIQ for ; Tue, 23 Feb 2016 11:09:47 -0800 (PST)
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 A370A1A8AE4 for ; Tue, 23 Feb 2016 11:09:47 -0800 (PST)
Received: by mail-pa0-x22a.google.com with SMTP id yy13so114847021pab.3 for ; Tue, 23 Feb 2016 11:09:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HMUaXEhoFG+mWGTKmYbsDWezC8aszWVI62sGmr5hK2Q=; b=N9Tx6vvIVX6BVDf5Ru6QT5D7RsVxnDVcnTAxu8vC6uFYBlj98Hq3PIDzPH6Zi4RX3c 7YPQGdtH1b4S8Juu+6mJ2vL7mI0lyKJHiA5um0aJmOpddi7jB4KUe/SBoKJZQN620z0k tGg2rm9lyLNWoio8TTUweTtxD4uvogP0o0ZBhbE2qPyD9e3aKFkAlTL9uxE/z4ETK3wo /HgKHuKC2lT8NrPQOCjTvpDB+EO2Wub3Ab5AmKQvKhObzsUEO/bdNB6EMrts3d4UinrO apEvmY8vEQuplKJQiK6MZ/I/S0ZX0trQkk+Gtez2mngR4qYZDm+SHzyiKALu41Xz/Hpk GP7g==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HMUaXEhoFG+mWGTKmYbsDWezC8aszWVI62sGmr5hK2Q=; b=Z+8FUI11d+gJTX1T7gLFRsKxcaNC79I5+gil45M3DbujVxhaaMjNMy264GP/IMx0oE fDjRjmvarB0gnLT0miJSt1TsZH1ABZ+SfxiFTm8c5AwWZ0YWyaNbGS5B7up2nQbc+gMV gglm335AcjilenxNAK7CPS66yrVUUVQJeD9BjIox8DuVB+QDmsqMVejvReZKouxVEhEf Z9u5oacdqYqjbv+m87oEzFFzzfnOHZk+p0qjuW58dFfXbO8s5l03N8JjPTrYccHQduIo Qm+JL91icd4VuYGfrSXqdbNBI0DMM5IHCQWaSGPvhWyxxuKVBXo8Lemcp24oN7UluSvb Mn8A==
X-Gm-Message-State: AG10YOTcxZLYVqB7pVBWYV9htu2iCfsHchigaw2wYGJ5GLY/+3tXgm2LW387tG1BiDTFww==
X-Received: by 10.66.144.134 with SMTP id sm6mr48782002pab.158.1456254587340;  Tue, 23 Feb 2016 11:09:47 -0800 (PST)
Received: from ?IPv6:2602:306:cd66:32c0:50cc:eaf3:9e9f:eaeb? ([2602:306:cd66:32c0:50cc:eaf3:9e9f:eaeb]) by smtp.googlemail.com with ESMTPSA id yj1sm46147250pac.16.2016.02.23.11.09.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 11:09:46 -0800 (PST)
To: otroan@employees.org
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org>
From: Jouni Korhonen 
Message-ID: <56CCAE79.6040506@gmail.com>
Date: Tue, 23 Feb 2016 11:09:45 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:09:50 -0000

Ole,

2/23/2016, 12:04 AM, otroan@employees.org kirjoitti:
> Jouni,
>
>>>> Ťp2p links without NDť sounds like a rather shoddy implementation to
>>>> me. Even though you won't need ND to discover link-layer addreses on
>>>> p2p links, you're still going to need it for DAD, NUD, SLAAC, default
>>>> router discovery, more-specific routes discovery, RDNSS discovery, etc.
>>>> etc. etc.
>>>
>>> at least with regards to the implementations I'm familiar with, that means no ND address resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication that also means we don't do NUD.
>>
>> NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still usable as IP layer reachability detection of your next hop, right.
>
> yes, but typically in this case the router wouldn't keep state for its neighbours. no state no NUD.

The case I was after here is where the p2p link is up (thus no 
link-specific information to indicate anything is wrong) but the next 
hop IP layer is dead and the upper layer traffic one is using does not 
provide "positive reachability confirmation". Eventually failing NUD 
determines the next hop is unreachable. Not that this would fix the 
situation but atleast the stack now knows the (only) next hop it has to 
send all its packets through is unreachable..

- Jouni

>
> cheers,
> Ole
>


From nobody Tue Feb 23 11:25:08 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023651ACD3E for ; Tue, 23 Feb 2016 11:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-is5KYSaiQr for ; Tue, 23 Feb 2016 11:25:00 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CBC1ACD3F for ; Tue, 23 Feb 2016 11:25:00 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 13C99D7883; Tue, 23 Feb 2016 11:25:00 -0800 (PST)
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=kQhYLZk7eZfKqxzgdDCba06vHvU=; b= GndVc67Bub8R8B8Qq+wFMTLdYsa/h8BgH8mz8u59i92dliTdEfEncAAtOX0IQ76A EFx6SAgLnrl2ZjdarB+6JUovLNQtgPQ1eb+vOcw8Y4WAkiiUXOuXymOnx6W7rEyp 69hMPxSU7FbHgOo90xrPHbcuqNzOEqMoQavkutovOvQ=
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=HnX//F8Gt554PkCNLy4t883JXD 74H6wf6lfEC1SYdWWJWOYJF8+Z9gw7m7EipICcqrfuKk88G61CkbUJQtA8RqIYNW Hlj6fHbkD4giOmIx7l1ql3ki18lBFCR6B+Oqw9EVzO6bYstPUfI8lGjAtE00BuNu neKacmChPSaI/JkxY=
Received: from h.hanazo.no (unknown [195.159.234.46]) (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 D7038D7895; Tue, 23 Feb 2016 11:24:59 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 29C80117193C; Tue, 23 Feb 2016 20:24:57 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_779324D9-DEB9-44A5-A7DB-64C841B30C0B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56CCAE79.6040506@gmail.com>
Date: Tue, 23 Feb 2016 20:24:56 +0100
Message-Id: <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org> <56CCAE79.6040506@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:25:08 -0000

--Apple-Mail=_779324D9-DEB9-44A5-A7DB-64C841B30C0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Jouni,

>>>>> =ABp2p links without ND=BB sounds like a rather shoddy =
implementation to
>>>>> me. Even though you won't need ND to discover link-layer addreses =
on
>>>>> p2p links, you're still going to need it for DAD, NUD, SLAAC, =
default
>>>>> router discovery, more-specific routes discovery, RDNSS discovery, =
etc.
>>>>> etc. etc.
>>>>=20
>>>> at least with regards to the implementations I'm familiar with, =
that means no ND address resolution. address resolution on a link =
without L2 addresses is in any case meaningless. by implication that =
also means we don't do NUD.
>>>=20
>>> NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still =
usable as IP layer reachability detection of your next hop, right.
>>=20
>> yes, but typically in this case the router wouldn't keep state for =
its neighbours. no state no NUD.
>=20
> The case I was after here is where the p2p link is up (thus no =
link-specific information to indicate anything is wrong) but the next =
hop IP layer is dead and the upper layer traffic one is using does not =
provide "positive reachability confirmation". Eventually failing NUD =
determines the next hop is unreachable. Not that this would fix the =
situation but atleast the stack now knows the (only) next hop it has to =
send all its packets through is unreachable..

router - router: BFD, routing protocol keepalives
router - host: host has state (from router discovery) and can do NUD if =
it cares.

(assuming no L2 keepalives).

cheers,
Ole


--Apple-Mail=_779324D9-DEB9-44A5-A7DB-64C841B30C0B
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

iQIcBAEBCgAGBQJWzLIIAAoJEL7aWKiYQt92crwP/iIzo7RMz8XzJwuBucENSDaA
eiGslfZ8wXfcyvQgcTMOVSDkIP6dGIqHcS7L9f08QCynUcVAgLXaurIr55PvJY7I
3HJOGKOyaJl+fEUzVzlUqnuLU8MGABXMLDDMwSB7iZN8YH/ycynALRVwn4j4p3Mm
ujLuRorhmWxuYVKQWE/Kjyu4n+dCwqSRfs0iV6XkG2klWYQhiAKRB84zzzavQNsc
pfGWA4HrxHAZjpbViLL/o0FebfPCNvwx/WW9hRO0W6hmgmeHmRRgVXzrbQBm+n2t
gydbQUI9mENxmLs/xBwZJdByyMVnek/3wMLlNAiuu2BGd4G90h0fKEwR1J2kIPTO
nd1BHRaG5vPpK1tqMi5zc636KAWkEK4GWhZEC5AWnF5OEeSSJDUbrX53bvlZgZZ4
PHv2gJPYBPvA1xwQku2vJXn7CnWusdeRZmCC5wH/azokicCxLAqJz7Pf53/ScmlB
wEfnLNoI+CVVu1B2VCZXGwSESx0uZD4+sVP/UKGp+9V8AmZU8IbrucmKG8iEDCzw
9dFyiIgTIQCvBtv9f20UOL+s+jtHpIzr/h6U0XLqsFngwJPQSLFxvDAYJenuZ0bu
PzIXXRCtRObLCDTTjVaOAOzeVUsE3pwwwvIbmCa524zQa6eW393OFn8Cmp09xLd8
3g19WCLGWlodxP/4jsSc
=erZp
-----END PGP SIGNATURE-----

--Apple-Mail=_779324D9-DEB9-44A5-A7DB-64C841B30C0B--


From nobody Tue Feb 23 11:53:45 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E061B29CE for ; Tue, 23 Feb 2016 11:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIl4jNAbKMbm for ; Tue, 23 Feb 2016 11:53:41 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7FA1AD0AF for ; Tue, 23 Feb 2016 11:53:41 -0800 (PST)
Received: from [2a02:fe0:c420:331::c68] (port=49516 helo=envy.w5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aYJ1c-0007Rx-RL; Tue, 23 Feb 2016 20:53:36 +0100
Date: Tue, 23 Feb 2016 20:53:36 +0100
From: Tore Anderson 
To: otroan@employees.org
Message-ID: <20160223205336.125bd80b@envy.w5.y.home>
In-Reply-To: <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org> <56CCAE79.6040506@gmail.com> <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 19:53:43 -0000

* otroan@employees.org

> router - host: host has state (from router discovery) and can do NUD
> if it cares.

Yep. For that to work, though, the router will need to respond to the
host's NUD/NS queries with NAs.

My impression from reading this thread has been that some (most?)
routers/stacks won't bother to do. Have I misunderstood?

Tore


From nobody Tue Feb 23 12:01:34 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6D21B2C47 for ; Tue, 23 Feb 2016 12:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pPWC1hy14AK for ; Tue, 23 Feb 2016 12:01:32 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D6A1B2B4B for ; Tue, 23 Feb 2016 12:00:49 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 806FED7884; Tue, 23 Feb 2016 12:00:48 -0800 (PST)
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=qd/TsH363Q0HX5jTyiNmuYkByE8=; b= WhYe6Doe9C9F8gd6Cx2WgneXrfMPYhgCblMKZZ1ek+LDfnpcx9Edvfd2MzBY8wKM msYsVflrBirra2AuNS6ZmohLlOiYlMxjqvlUSqG7pV90EYiSyd1fZNG8EW2a3efo IJy7dg1RZ6m+bvR2cZ90wShj8y+vqxYJaC1aXv46U0s=
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=qrscO6GD45r4u9nJ/DZnQawScZ 1yE1Z0CLCVO24rz5D7LTs9Ra0NeqB5wABuUWst2dJn+ivyxWhSGtFIJ+a1ZeVTeZ wTmCmqyzH8Y9liPB/Z/nlFrXXKUJNR55EHt+yOVwI7b5pCM29KZSpvGNDeszadm6 91MQ0bCs79OPyrrj8=
Received: from h.hanazo.no (unknown [195.159.234.46]) (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 51835D789D; Tue, 23 Feb 2016 12:00:48 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D459C11726DA; Tue, 23 Feb 2016 21:00:45 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_54CC7478-8B76-49FA-9378-66F881E8AE58"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <20160223205336.125bd80b@envy.w5.y.home>
Date: Tue, 23 Feb 2016 21:00:44 +0100
Message-Id: <86B8D348-C288-49B9-9CC8-D98AA71FE6C9@employees.org>
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org> <56CCAE79.6040506@gmail.com> <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org> <20160223205336.125bd80b@envy.w5.y.home>
To: Tore Anderson 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 20:01:33 -0000

--Apple-Mail=_54CC7478-8B76-49FA-9378-66F881E8AE58
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Tore,

>> router - host: host has state (from router discovery) and can do NUD
>> if it cares.
> 
> Yep. For that to work, though, the router will need to respond to the
> host's NUD/NS queries with NAs.
> 
> My impression from reading this thread has been that some (most?)
> routers/stacks won't bother to do. Have I misunderstood?

I would consider that implementation broken.

cheers,
Ole

--Apple-Mail=_54CC7478-8B76-49FA-9378-66F881E8AE58
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

iQIcBAEBCgAGBQJWzLptAAoJEL7aWKiYQt92FXgQAIxV7GD8wOMKSVYPwlntmHSI
/M2GVF5uwr2B0hHDqRZ8BN7In8/YQ9kFHJ05FGFlJOESoG/3bZWUnkZpeUjRyEV5
i4gsA2OhPithTek/8D+qTmRdib1uXWn7Bvk3US3t9pYDoEBa0KUt0YKD2Qf375YW
mviRbi7yMULUodiEEJK+/CUNqF6nfilrWopCOjb2QlGWRozq6HylKA3Z8g56w7x7
jL7Y0zOfusFeYo7iGvgDpFxQMPc3eJSIaT3FOHy4m6vOOhAKy8xBr4QO8Pwec3qE
H5w0eow25xw5m9BBzwNRlFYEfh9cdsrmGvERnFletRum7ub0eK2EwYC+KlS89lMF
TxkP5RmEcWhhaAj0h25IgtnmmMMBmjWr5N1BPQjrTxuE1TVDpumAS/UhvJlJ9uqL
5NGWvK98YZPpU0WtijRPzCYS1sOLtGLX3kjhBqzEVyVT6hFD+/r3DoHM3mlL7m4E
oEUGfHmFmiiIbM7qgOwi2y2OwuagznxE7ZfjI2LOWV1iJPD2nm2ghdylRl7BgPzH
hMtA1JMcDqdsEYrRp5yJLbQDHs8Rv2xHjmJOOau2tSUp2iVcrPeS07iTGPOZiWCW
EUh+DT8csuNsln99sZphuA9K4zIByQeoV8BnUIfxujjPSIFYouAUqNi0dlp5ZFyF
gwNPrPvRtBLClbgIYxjN
=KIAN
-----END PGP SIGNATURE-----

--Apple-Mail=_54CC7478-8B76-49FA-9378-66F881E8AE58--


From nobody Tue Feb 23 12:10:51 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43381A7011 for ; Tue, 23 Feb 2016 12:10:49 -0800 (PST)
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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-dviAaJnaff for ; Tue, 23 Feb 2016 12:10:47 -0800 (PST)
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 89BED1A1BE9 for ; Tue, 23 Feb 2016 12:10:47 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 B978280DA3; Tue, 23 Feb 2016 21:10:43 +0100 (CET)
To: otroan@employees.org, Mark Smith 
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
From: Fernando Gont 
Message-ID: <56CCBCAC.6090509@si6networks.com>
Date: Tue, 23 Feb 2016 17:10:20 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 20:10:50 -0000

On 02/23/2016 07:59 AM, otroan@employees.org wrote:
> Mark,
> 
> MLD joins for the solicited node multicast address has turned out to
> have little practical purpose. 

Operation on swtiches that do mld-snooping?

Or am I missing something?

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





From nobody Tue Feb 23 12:14:22 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC21B2D35 for ; Tue, 23 Feb 2016 12:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AaYkubEn_pz for ; Tue, 23 Feb 2016 12:14:18 -0800 (PST)
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 81F211B2D25 for ; Tue, 23 Feb 2016 12:14:18 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id k196so174050343vka.0 for ; Tue, 23 Feb 2016 12:14:18 -0800 (PST)
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-type; bh=N82loJMIkd03VuGCf7ItR5Is6wr3ZgAyrtKjei/Lg68=; b=rMqPiJur4/CgX4HkpcZJiQ/F8O3naSgsqg9EA8rY0gLq73boFbyHN6WFuPExQzVlCj sWDfGvd5aUggS7aYbdwdIX8NXDoTM5+BGcJgDZN78zen23JHMlf4r+O+Qn4m8Nw8PJLL Y9O4UXmnrQ04uPOE9fANnbMYIqTPYxN8KycLzIpiMTrn4Tlm297PKDpcMYUviBvbQP8t 0I/f+JI8pMALyHH3o7HEle92a9LSLQqbjaLEjzRdA8LbT45y1617bWKIBJnrTeurI2mS 1HpZkThPKOu922SMTSVjRSxqMCVGrjKs6AJmudaWha8OBhQGLJJC7AnbMqU/p7QlTDnU lDvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N82loJMIkd03VuGCf7ItR5Is6wr3ZgAyrtKjei/Lg68=; b=C7I/Nvs8/mRz3hdn3kJ92rOWR6IF9fImX2/lK26zQFCxERrgm90WnBMhRnX00vnaZ2 RSME6Q5DD/n9rv0UZrCJs705mOaE/vjlwjPeOnLWLPgLj8CDtZNJvo/A85jBWjWFHCHW s72RWdaKYXaStJkZ4dFF3Q6xhef9j5cqLLoZ8skCWehp8ktiGsjlsnqRkF+X7ns8BoSs jq5Sihl8ETjs56QY6IYDuTk+yjNLJmQkAcLmVoYxM/KQfib1Jx0L51JYhdzdNWZBaKyS SL9qrF0JpHqIuVUOpPd+j7RM5xvsT8BvBhY88HRKr/WKB9MrJj2+bDRBSw9U/CTF8FWu dZ7g==
X-Gm-Message-State: AG10YOTSN4C4JjlFRJiSwAcQevPxuBxfjodQg6Bb7pVsiJaATYo/AZVK94VGRr65/CwYoBwEAfBAVwzJSL3M7g==
X-Received: by 10.31.48.216 with SMTP id w207mr30133832vkw.36.1456258457591; Tue, 23 Feb 2016 12:14:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.103 with HTTP; Tue, 23 Feb 2016 12:13:48 -0800 (PST)
In-Reply-To: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org>
From: Mark Smith 
Date: Wed, 24 Feb 2016 07:13:48 +1100
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=001a1143fd0410e67b052c759866
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 20:14:21 -0000

--001a1143fd0410e67b052c759866
Content-Type: text/plain; charset=UTF-8

On 23 Feb 2016 9:59 PM,  wrote:
>
> Mark,
>
> MLD joins for the solicited node multicast address has turned out to have
little practical purpose. I am thinking of going the other way and stop
sending joins for link-local multicast groups.
>

Well, they're mandated by the specs, and here is (what I think) is quite a
useful use for them.

I also think these SN group joins could help scale the size of virtualised
networks, because the underlay network could use them to track to which
NVE/tunnel end-points to send ND NSes to, rather than flooding them to all
NVEs/tunnel end points (the underlay network would be running a multicast
routing protocol to do this.)

Best regards,

Mark.


> Best regards,

> Ole
>
> > On 07 Feb 2016, at 20:25, Mark Smith  wrote:
> >
> > HI,
> >
> > I'm revisiting a few of my drafts that I've been intending to update,
> > and here is the first.
> >
> > My basic realisation was that Solicited-Node joins also could serve as
> > a low resolution address (or address space range) registration method,
> > which could then be used by a router to determine whether it needs to
> > send a ND NS or not. If the Solicited-Node group is present, send the
> > ND NS, if the group isn't, then don't.
> >
> > This update adds a few sections and modes based on Lorenzo's feedback:
> >
> > - Strict and Relaxed discard modes. Universal discarding is Strict
> > mode, Relaxed mode only discards if there is an indication a DoS is
> > occurring, to allow for lower MLD reliability or implementations that
> > don't support MLD
> >
> > - Some discussion on MLD reliability and how it would effect this
method.
> >
> > Comments and suggestions appreciated.
> >
> > Regards,
> > Mark.
> >
> >
> > ---------- Forwarded message ----------
> > From:  
> > Date: 8 February 2016 at 06:14
> > Subject: New Version Notification for
> > draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
> > To: "markzzzsmith+ietf-dt@gmail.com" 
> >
> >
> >
> > A new version of I-D,
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
> > has been successfully submitted by Mark Smith and posted to the
> > IETF repository.
> >
> > Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
> > Revision:       01
> > Title:          Further Mitigating Router ND Cache Exhaustion DoS
> > Attacks Using Solicited-Node Group Membership
> > Document date:  2016-02-07
> > Group:          Individual Submission
> > Pages:          11
> > URL:
> >
https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
> > Status:
> >
https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
> > Htmlized:
> >
https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
> > Diff:
> >
https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
> >
> > Abstract:
> >   For each of their IPv6 unicast or anycast addresses, nodes join a
> >   Solicited-Node multicast group, formed using the lower 24 bits of the
> >   address.  This Solicited-Node group membership could be used by
> >   routers to further mitigate a Neighbor Discovery cache Denial of
> >   Service attack.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>

--001a1143fd0410e67b052c759866
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 23 Feb 2016 9:59 PM, <otroan@employees.org> wrote:

>

> Mark,

>

> MLD joins for the solicited node multicast address has turned out to h=
ave little practical purpose. I am thinking of going the other way and stop=
 sending joins for link-local multicast groups.

>


Well, they're mandated by the specs, and here is (what I=
 think) is quite a useful use for them.


I also think these SN group joins could help scale the size of virtualis=
ed networks, because the underlay network could use them to track to which =
NVE/tunnel end-points to send ND NSes to, rather than flooding them to all =
NVEs/tunnel end points (the underlay network would be running a multicast r=
outing protocol to do this.)
Best regards,
Mark.



> Best regards,

> Ole

>

> > On 07 Feb 2016, at 20:25, Mark Smith <markzzzsmith@gmail.com> wrote:
> >

> > HI,

> >

> > I'm revisiting a few of my drafts that I've been intendin=
g to update,

> > and here is the first.

> >

> > My basic realisation was that Solicited-Node joins also could ser=
ve as

> > a low resolution address (or address space range) registration me=
thod,

> > which could then be used by a router to determine whether it need=
s to

> > send a ND NS or not. If the Solicited-Node group is present, send=
 the

> > ND NS, if the group isn't, then don't.

> >

> > This update adds a few sections and modes based on Lorenzo's =
feedback:

> >

> > - Strict and Relaxed discard modes. Universal discarding is Stric=
t

> > mode, Relaxed mode only discards if there is an indication a DoS =
is

> > occurring, to allow for lower MLD reliability or implementations =
that

> > don't support MLD

> >

> > - Some discussion on MLD reliability and how it would effect this=
 method.

> >

> > Comments and suggestions appreciated.

> >

> > Regards,

> > Mark.

> >

> >

> > ---------- Forwarded message ----------

> > From:=C2=A0 <internet-drafts@ietf.org>

> > Date: 8 February 2016 at 06:14

> > Subject: New Version Notification for

> > draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt

> > To: "markzzzsmith+ietf-dt@gmail.com" <markzzzsmith@gmail.com>=


> >

> >

> >

> > A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slct=
d-node-01.txt

> > has been successfully submitted by Mark Smith and posted to the
> > IETF repository.

> >

> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-smith-v6ops-m=
itigate-rtr-dos-mld-slctd-node

> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001

> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Further Mitigating Route=
r ND Cache Exhaustion DoS

> > Attacks Using Solicited-Node Group Membership

> > Document date:=C2=A0 2016-02-07

> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11

> > URL:

> > https://www.ietf=
.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.t=
xt

> > Status:

> > https://datatracker.ietf.o=
rg/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/

> > Htmlized:

> > https://tools.ietf.org/html/d=
raft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01

> > Diff:

> > https://www.ietf.org/=
rfcdiff?url2=3Ddraft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01

> >

> > Abstract:

> >=C2=A0 =C2=A0For each of their IPv6 unicast or anycast addresses, =
nodes join a

> >=C2=A0 =C2=A0Solicited-Node multicast group, formed using the lowe=
r 24 bits of the

> >=C2=A0 =C2=A0address.=C2=A0 This Solicited-Node group membership c=
ould be used by

> >=C2=A0 =C2=A0routers to further mitigate a Neighbor Discovery cach=
e Denial of

> >=C2=A0 =C2=A0Service attack.

> >

> >

> >

> >

> > Please note that it may take a couple of minutes from the time of=
 submission

> > until the htmlized version and diff are available at tools.ietf.org.

> >

> > The IETF Secretariat

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.or=
g

> > https://www.ietf.org/mailman/listinfo/v6ops

>






--001a1143fd0410e67b052c759866--


From nobody Tue Feb 23 12:27:19 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8301B2FCC for ; Tue, 23 Feb 2016 12:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjdlBkxAnF1p for ; Tue, 23 Feb 2016 12:27:17 -0800 (PST)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F7E1B2FBA for ; Tue, 23 Feb 2016 12:27:17 -0800 (PST)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id C8634D7884; Tue, 23 Feb 2016 12:27:16 -0800 (PST)
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=yTGblFft4hOhVWfHkrKNABnZ0KQ=; b= W8locu1Dk1o3Nn/DqJP5Enbsm27iQakBCBhE6UZ+1tX5rXjWOiN23W9so0lrjoKk OrAGWIHpNsb7zWsBCzPpZQOFZDILsy9N1GOQ8gQ6dRwdbI42miP0mgsdPCJJNkjJ xCA1ozdf1/txITHFSs91mxAGPf2Kd66l4qD12cwPa7w=
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=S8g+WQKvqJHYmhZSBwxwxZ7N8x VITH0cUSemPlcK31jTXR2WHvjsRydPRYrCMual0sz8ccgfsb54gjl7YGPGLMx+ls n1En1BF6yW4jAkW803e1ZZbLYnm7cs3aUaVQhSbzltXrL5x9AX6yIEotneCcjvPV iMUtHN7SefLdx8zfQ=
Received: from h.hanazo.no (unknown [195.159.234.46]) (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 8BE40D7883; Tue, 23 Feb 2016 12:27:16 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CBDAD1172DA9; Tue, 23 Feb 2016 21:27:13 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_42D2555F-89FB-4E69-B8F3-29EA9833984B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: otroan@employees.org
In-Reply-To: <56CCBCAC.6090509@si6networks.com>
Date: Tue, 23 Feb 2016 21:27:12 +0100
Message-Id: 
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCBCAC.6090509@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2016 20:27:18 -0000

--Apple-Mail=_42D2555F-89FB-4E69-B8F3-29EA9833984B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

>> MLD joins for the solicited node multicast address has turned out to
>> have little practical purpose.
>=20
> Operation on swtiches that do mld-snooping?
>=20
> Or am I missing something?

MLD snooping apparently doesn't scale to the number of link-local =
multicast groups.
switches fall back to flooding. (add typically and it depends as fits).

cheers,
Ole

--Apple-Mail=_42D2555F-89FB-4E69-B8F3-29EA9833984B
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

iQIcBAEBCgAGBQJWzMChAAoJEL7aWKiYQt92raoP/j20GLlaz0jq4jLMWr5kMpsR
zo616id03HR61kvc6M/B3d25HHwactdnNowZ0q1gpm+cq5nft/WrqbTTS+7l088j
5qWHvjRsp+ke9ZocBzAWdAzbvsXDVrA+iyFHTGfugvwGg6MuiNHG/4VM01KigQW6
/vmgI949k7F/5QaCy0s3LGc5vtOBMWYfJFrZQH2qsJbh44lL/b8WXx+WyJbD2oqP
l5ycdUUm7dGyRKfq7u9lKUz1Q0gmidWME0BOpzk+8iZ/67BP8129r1Y4GWPxZkR1
KxYJeirxUrRWpEzA46cF+Rkt0PW8rupiRlweYGJLbTg90xdh3t6skoGZKgFtmSzT
sFzEuIkcGrV9elIdWOh/o0+4Wr1F6SqPPWPEjU2re0kx+F8t1WXc9gXc7H3749cS
Wn8qHhrsPCDqRphAE96dhMN6bfykMVy00cULiGdJnMNfWN2Bh61ZHkmLW3Pq0swQ
uOvhmIRyFoVI3C2zBnvXXznl41QokK+9k43RTiT2Yqupcvj25ye0/QvHifdWukzG
qvzAe+4Lx60nZqwgwVl6AiKgrFPTfBmrndh+z39yOYBqc3Y4bMutNxGxKItfyDDv
1xw29dTUdcA4WMAr9Z62MPzA+XDr+1+R4YHphhVwGxwUH0Pqu9ODbwf05NeV7+Gb
NqQ4qPuQNd/+j5V/z8uL
=07DF
-----END PGP SIGNATURE-----

--Apple-Mail=_42D2555F-89FB-4E69-B8F3-29EA9833984B--


From nobody Tue Feb 23 17:33:48 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECB11B3EEB for ; Tue, 23 Feb 2016 17:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level: 
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfU0xmIiKbik for ; Tue, 23 Feb 2016 17:33:46 -0800 (PST)
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 EF5BB1B3E57 for ; Tue, 23 Feb 2016 17:33:45 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 21A92804C1; Wed, 24 Feb 2016 02:33:41 +0100 (CET)
To: otroan@employees.org
References:  <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCBCAC.6090509@si6networks.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CCC7E5.6050708@si6networks.com>
Date: Tue, 23 Feb 2016 17:58:13 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 01:33:47 -0000

On 02/23/2016 05:27 PM, otroan@employees.org wrote:
>>> MLD joins for the solicited node multicast address has turned out to
>>> have little practical purpose.
>>
>> Operation on swtiches that do mld-snooping?
>>
>> Or am I missing something?
> 
> MLD snooping apparently doesn't scale to the number of link-local multicast groups.
> switches fall back to flooding. (add typically and it depends as fits).

Hopefully they do. I seem to recall a couple of folks complaining abut
issues associated with faulty/buggy/sloppy MLD-snooping or lack of thereof.

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





From nobody Tue Feb 23 22:58:47 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF65D1B4660 for ; Tue, 23 Feb 2016 22:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.784
X-Spam-Level: 
X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApPFJFiERAX7 for ; Tue, 23 Feb 2016 22:58:44 -0800 (PST)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 ADAE91B465D for ; Tue, 23 Feb 2016 22:58:43 -0800 (PST)
Received: by mail-yk0-x233.google.com with SMTP id u9so4224906ykd.1 for ; Tue, 23 Feb 2016 22:58:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bPA2bRqgkxmyo1NW0gTMw/a71jEewFHQUl4S0JOIx7w=; b=czS1vEl9vb+XaZbstdwhID9UQ9ptOLVvz6pg3kLp0bOhfQd7uqaFnZR0da68Rkw/QX qNXP9AQ8kmBH5Dv5+7mlhmqI6tylJVdgL3SAP1heRr64SGSDGTZ/mRQ6y7jUwRW0nj0k tXv7x5rXZjlxgR6c+6lophtPyEjY3jJvYh1APrxEt75zJT7cUiY5/P23JpRzKcoG+leW y6DEuM6SMtGsWvIxK4e/n9xqzoVF7R+rCtgQtaFZdp+oRN34r6qqDcT8/Alrahzi/99i g4DVmrpWPeFmYLwclbOeUDbOeIdA8Gu5FVovtCgTJ5c9x1/jXosV9OYL/sJ9MpIAcqtl w4qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bPA2bRqgkxmyo1NW0gTMw/a71jEewFHQUl4S0JOIx7w=; b=b9RSuwd+C/YVPhZEMPCYLDqW4DTPzFty7RxyeOnomKgi5cHlcbv2s7a7LDgYbcmEca MEaa9kPI4JJZUrKN9M+fJ6KPrJWPyOx8dJI5Ly+aaqMri+GcIk63GcRrk5miVmA85m8v fHPQkThqHQeAsY8KdKWuV8VJiGdMsX9PhIjdTYclZQuQUwM428iQh+yj40yx+APwCII3 1ZGhMaWoxzmKMf+c72BCdKI4cvnGOEQFpjIg8k4edA7YZChrnYAD1N0dkhamlXIYTSGV aXUNXin7MaSXi+3BmugOZYz+mHstErqvqh9085pwFSkZfSiFjxN5Fj2zpouJ+NDHrcP4 sJbQ==
X-Gm-Message-State: AG10YORqbYjNLYFUt7xRZPAH/F6GI2unhkaa51fsnU6I/HC/nU3TSZxHLwD0H8qn5IB+5cT4knLTjKlkEe3ZYVVo
X-Received: by 10.37.13.131 with SMTP id 125mr6790359ybn.49.1456297122786; Tue, 23 Feb 2016 22:58:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Tue, 23 Feb 2016 22:58:23 -0800 (PST)
In-Reply-To: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
From: Lorenzo Colitti 
Date: Wed, 24 Feb 2016 15:58:23 +0900
Message-ID: 
To: Fred Baker 
Content-Type: multipart/alternative; boundary=001a11c0144ab1c068052c7e98c6
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 06:58:46 -0000

--001a11c0144ab1c068052c7e98c6
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 22, 2016 at 4:00 AM,  wrote:

> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
>

Hi,

technical review follows. For the avoidance of doubt: the intent of this
review is to ensure that if we publish this draft, it is correct; while I
do not particularly support this draft, I don't strongly oppose it either.

Substantive points:

1. I disagree with the statement "It is unclear whether hosts should
initiate DHCPv6 by themselves if there are no RAs at all." There is not
really point in using DHCPv6 without RAs. This is because DHCPv6 does not
configure prefixes, only addresses without prefix lengths, and therefore an
address assigned by DHCPv6 either has no prefix length or a prefix length
of /128. See dhcpv6bs ticket 68:
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68

So starting DHCPv6 without an RA is pointless because even if you get an
address, you can't use to talk to anything. Thus, I don't think there is
any ambiguity here, since one of the alternatives doesn't make sense. That
said, if we do still want to say this is ambiguous, then we should replace
"ambiguous" with "unspecified", and add something about the fact that
DHCPv6 without RAs is useless, such as:

===
It should be noted that DHCPv6 by itself only communicates address
information, not reachability information. The fact that an address was
received from DHCPv6 does not imply that that address can reach any
destination outside the host itself. Therefore, even if DHCPv6 succeeds
without an RA, the resulting configuration is not useful for network
communication.
===

The draft should also note that clients
following draft-ietf-dhc-anonymity-profile are not expected to start DHCPv6
without first receiving an RA, because draft-ietf-dhc-anonymity-profile
says that they SHOULD NOT do so.


2. Where the draft discusses changes in the M flag and says "it is clear
whether the host should start DHCPv6 or not", it should instead say that
the host is under no obligation to do so, first because implementing DHCPv6
is not a MUST, and second because the M flag is advisory.


3. Where the draft says "It could be reasonably deduced that M flag should
be independent from A flag" - again, the text should mention that for a
client following draft-ietf-dhc-anonymity-profile, that's not true.


4. "RDNSS" is used both to indicate the RDNSS option and to indicate DNS
server IP addresses. The two things should be called different names.


5. In several places, the draft says:

   (This divergence is only for those operations systems which
   support[RFC6106].)

Because RFC6106 is as much a SHOULD in the IPv6 node requirements as
DHCPv6, the draft should also tag everything related to DHCPv6 with:

   (This divergence is only for those operations systems which
   support[RFC3315].)

Or, if you prefer, note early on in the draft (e.g., in the introduction)
that DHCPv6 is a MUST and if hosts do not implement DHCPv6 then there is no
ambiguity.


6. The security considerations section is unrelated to the main purpose of
the draft, which is to "describe divergent host behaviours [and]
operational problems that the divergent behaviors might cause". These
security issues documented in this draft exist regardless of divergent
behaviour. They are security issues that address other unspecified parts of
the implementations, not the main issue in this draft, which is overlap
between DHCPv6 and SLAAC.


7. The draft makes no mention of Android. Perhaps it should say that
Android does not have this problem because it does not implement DHCPv6?


Minor issues:

1. In the introduction, but SLAAC first and DHCPv6 second, because in the
IPv6 node requirements, SLAAC is MUST and DHCPv6 is a SHOULD.

Regards,
Lorenzo

--001a11c0144ab1c068052c7e98c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Feb 22, 2016 at 4:00 AM,  <fred@cisco.com> wrote:
This is to initiate a two week working group last call of

http://tools.ietf.org/html/draft-iet=
f-v6ops-dhcpv6-slaac-problem.

Hi,

technical review follows. For the avoidance of doub=
t: the intent of this review is to ensure that if we publish this draft, it=
 is correct; while I do not particularly support this draft, I don't st=
rongly oppose it either.

Substantive points:

1. I disagree with the statement "It is unclear whether hosts=
 should initiate DHCPv6 by themselves if there are no RAs at all." The=
re is not really point in using DHCPv6 without RAs. This is because DHCPv6 =
does not configure prefixes, only addresses without prefix lengths, and the=
refore an address assigned by DHCPv6 either has no prefix length or a prefi=
x length of /128. See dhcpv6bs ticket 68: http://trac.tools.ietf.org/group/dhcpv6bis/=
ticket/68

So starting DHCPv6 without an RA is =
pointless because even if you get an address, you can't use to talk to =
anything. Thus, I don't think there is any ambiguity here, since one of=
 the alternatives doesn't make sense. That said, if we do still want to=
 say this is ambiguous, then we should replace "ambiguous" with &=
quot;unspecified", and add something about the fact that DHCPv6 withou=
t RAs is useless, such as:

=3D=3D=3D
It =
should be noted that DHCPv6 by itself only communicates address information=
, not reachability information. The fact that an address was received from =
DHCPv6 does not imply that that address can reach any destination outside t=
he host itself. Therefore, even if DHCPv6 succeeds without an RA, the resul=
ting configuration is not useful for network communication.
=3D=
=3D=3D

The draft should also note that clients following=
=C2=A0draft-ietf-dhc-anonymity-profile are not expected to start DHCPv6 wit=
hout first receiving an RA, because=C2=A0draft-ietf-dhc-anonymity-profile s=
ays that they SHOULD NOT do so.


2. =
Where the draft discusses changes in the M flag and says "it is clear =
whether the host should start DHCPv6 or not", it should instead say th=
at the host is under no obligation to do so, first because implementing DHC=
Pv6 is not a MUST, and second because the M flag is advisory.

3. Where the draft says "It could be reason=
ably deduced that M flag should be independent from A flag" - again, t=
he text should mention that for a client following=C2=A0draft-ietf-dhc-anon=
ymity-profile, that's not true.


4. "RDNSS" is used both to indicate the RDNSS option and to indi=
cate DNS server IP addresses. The two things should be called different nam=
es.


5. In several places, the draft=
 says:

=C2=A0 =C2=A0(This divergence is only =
for those operations systems which
=C2=A0 =C2=A0support[RFC6106].=
)

Because RFC6106 is as much a SHOULD in the=
 IPv6 node requirements as DHCPv6, the draft should also tag everything rel=
ated to DHCPv6 with:

=C2=A0 =C2=A0(This diver=
gence is only for those operations systems which
=C2=A0 =C2=A0sup=
port[RFC3315].)

Or, if you prefer, note earl=
y on in the draft (e.g., in the introduction) that DHCPv6 is a MUST and if =
hosts do not implement DHCPv6 then there is no ambiguity.


6. The security considerations section is unrelated =
to the main purpose of the draft, which is to "describe divergent host=
 behaviours [and] operational problems that the divergent behaviors might c=
ause". These security issues documented in this draft exist regardless=
 of divergent behaviour. They are security issues that address other unspec=
ified parts of the implementations, not the main issue in this draft, which=
 is overlap between DHCPv6 and SLAAC.


7. The draft makes no mention of Android. Perhaps it should say that And=
roid does not have this problem because it does not implement DHCPv6?
=



Minor issues:

1=
. In the introduction, but SLAAC first and DHCPv6 second, because in the IP=
v6 node requirements, SLAAC is MUST and DHCPv6 is a SHOULD.

<=
/div>
Regards,
Lorenzo


--001a11c0144ab1c068052c7e98c6--


From nobody Wed Feb 24 00:07:04 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE001B2DF6 for ; Wed, 24 Feb 2016 00:07:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FeZhjrqjKZ9 for ; Wed, 24 Feb 2016 00:07:00 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 BF20A1B2C90 for ; Wed, 24 Feb 2016 00:06:59 -0800 (PST)
Received: by mail-yk0-x236.google.com with SMTP id u9so4735560ykd.1 for ; Wed, 24 Feb 2016 00:06:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tH4cQZjKUj9bgU9mxFIF6sZJh9bBqYqWmByFIp8GITY=; b=c91M+6B4HCvahmeRaABPodMVzDJRXEPsFbDvD8pe9WBAMVd+27olrBfTfhv1xTm6u+ 88amk4h7eh9QqjrK+EvJv155Bt2viXfX9gAOhxhsUZaC7988ttDiIrnlfk1+V1ItfrNI AiwnTmarxpMXNCoKKlBIPuLJdS4mMTvlTN0J6edCwb+W/1N30xLaMYF2RHKWKXBKM4xH RPFzsxF2Kb8xhCGdI//KMrdhHbt9YW04+cNvdbEXm5K0MGP+604+JNIHiNI9LLXlXBVZ K//T28jaxNOIV+SRxw0xlqfngO/1QeYypWkV2GKLVO8rFd0Gih0MefxrrcaUqyH88eKm FmqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tH4cQZjKUj9bgU9mxFIF6sZJh9bBqYqWmByFIp8GITY=; b=jnATHZ48YyPQa+25dbz6Y5CaGPrxIhdylZn6SeYB/GiR1N1ZY3l+m03AWrd+EF45gK Xm7pQFn5VxbFLLYaX7J3CZJFjvZqeA8goxUcD5kRbynBZwJ3GB0cwIZHQEXspLpiaZe5 rakAv4FH3HyUOajd8j5eHj3ImiLGlgPhDwW8tAq58Cka3vX0jvk4iemcfIxO/q3zozdD VVOlYYPQB4zXdFtKNhtx2xmUOpGf8bM41LQ4yFCkSRxxaF/Nn1Gp9bf3fsIokigUtSYp qk+QZepOShwZKT+7yTPRR8tf4cnqBhxMZFJtjyccSzwxWGsRKWqbWXOPI/jiMz75Y0Cj p/nQ==
X-Gm-Message-State: AG10YOQYM332nQl+2wjv9D+UnT1YqiTWUyecJwhBFax9pwBCM7glHhjCKkcnj2UGS+8VvzQGKE6Ip4kQ6lw1+ICp
X-Received: by 10.37.13.131 with SMTP id 125mr6921114ybn.49.1456301218923; Wed, 24 Feb 2016 00:06:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Wed, 24 Feb 2016 00:06:39 -0800 (PST)
In-Reply-To: <2134F8430051B64F815C691A62D983183396E593@XCH-BLV-105.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D983183396E593@XCH-BLV-105.nw.nos.boeing.com>
From: Lorenzo Colitti 
Date: Wed, 24 Feb 2016 17:06:39 +0900
Message-ID: 
To: "Templin, Fred L" 
Content-Type: multipart/alternative; boundary=001a11c0144ad7b4bb052c7f8ccf
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 08:07:03 -0000

--001a11c0144ad7b4bb052c7f8ccf
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 7:31 AM, Templin, Fred L 
wrote:

> First, the document throughout uses expressions of the form "networks
> provide hosts with multiple global addresses" but IMHO that implies  a
> sort of "push" operation where the network pushes addresses onto the
> host which is not the way things work in practice. I think a more
> appropriate
> expression form would be "networks provide hosts with a means to obtain
> multiple global addresses".
>

We've already gone through the draft to change the terminology once (from
"assign addresses" to the current "provide addresses"). I'm not sure that
changing it again from "provide addresses" to "provide a means to obtain
addresses" provides much value.

To me, "provide" does not a imply push operation. The network can also
provide addresses / prefixes on request (e.g., if the host sends an RS or a
DHCPv6 solicit.)


> Second, the document seems to imply in several places that SLAAC can
> be used as a sort of implicit prefix delegation service; presumably in the
> same spirit as RFC7278. If that is the intention, then it also needs to say
> that the host needs to have some way of knowing outside of the scope
> of the node requirement standards that the prefix is being delegated
> for the host's exclusive use. For example, an unmodified host that obeys
> RFC4861 on a WiFi link would have no way of knowing that a prefix
> advertised in a PIO with (A=1; L=0) is in fact being delegated for its own
> exclusive use. The document therefore needs to note this rather than
> imply that an unmodified host can use SLAAC for prefix delegation.
>

It is not the intention of the draft to imply this. In fact, it explicitly
says the opposite: "If the host is aware that the prefix is dedicated
(e.g., if it was provided via DHCPv6 PD and not SLAAC)..." Knowing that a
prefix in the RA is dedicated or not would require protocol changes. We
could consider those in the future, but not in v6ops, because protocol
changes are not something that is in the remit of this WG.

The following addresses some of your inline points. I think the others are
either minor editorial issues with no substantive implications or are
already covered by the two main points above.

8) Section 6, under the heading "Using Stateless Address
>
   Autoconfiguration [RFC4862]." This section does not make
>    a statement as to whether the "dedicated /64 prefix" is
>    to be used only for SLAAC on the interface over which the
>    prefix is advertised, or whether the prefix can be
>    extended to a LAN link as in RFC7278.


I don't think the draft needs to say this. RFC4862 does not contain
anything about extending the prefix to other hosts.

While the draft does cite RFC7278 elsewhere, RFC7278 is specific to only
one type of link layer (3GPP links). So I think the text is unambiguous: if
you're on a 3GPP network, you can use RFC7278, and if not, any ability to
extend the prefix is unspecified. There's ND proxying, but it's
experimental.

Also see my prior point about protocol changes.


> 9) Sectin 6, under the heading "Using Stateful DHCPv6 address
>    assignment [RFC3315]" final sentence in the paragraph says
>    "The number of IPv6 addresses that can be provided in a
>    single DHCPv6 packet is approximately 30." but it does
>    not say where the "30" came from. Is it because of packet
>    size limitations? Some protocol constant? Something else?
>    Suggest adding a trailing phrase giving some rationale
>    for the "30".
>

In section 8 the draft already says "the approximately 30 addresses that
can fit into a single packet". I've modified the text you pointed to with
"The maximum number of IPv6 addresses that can be provided in a single
DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is
approximately 30.".

10) Table 1, "Extend network" is listed as "Yes" for SLAAC,
>    which would seem to imply that SLAAC is intended to extend
>    the prefix to a LAN link as in RFC7278. But, that can only
>    be possible when the host has some way of knowing that the
>    prefix has been "delegated" which is outside the scope of
>    RFC4861. Can be addressed by adding a "**" next to the
>    Yes with the footnote:
>

I've changed that to No+, with "[+] Except on certain networks, e.g.,
[RFC7278]." There is currently no specified way for a host to do this
except ND proxying, which is experimental.

11) Table 1, ""Unlimited" endpoints is listed as "No" for
>    DHCPv6 PD. Shouldn't it be a "Yes"?
>

No. The network cannot provide prefix delegations to an unlimited number of
endpoints. It can only provide prefix delegations to as many endpoints as
it has available /64s. This is different from both SLAAC and IA_NA, where,
absent scaling limitations, an "unlimited" number of endpoints can fit in
one /64. I've changed the row name from "Unlimited" endpoints to Number
"unlimited" endpoints.


> 13) Section 8, "The prefix MAY be provided using DHCPv6 PD,
>    SLAAC with per-device VLANs, or any other means." Two issue
>    with this - first, the text earlier also included "wireless
>    network where every MAC address is placed in its own
>    broadcast domain" which should also be reiterated here.
>

I don't see a reason to reiterate one of the means to do so, given that
this sentence already says "or any other means".


> 14) Section 9.1, rename section as simply "Host Tracking", since
>    the section covers both stateful and SLAAC.
>

Fair enough.


> 15) Section 9.1, paragraph beginning "Many large enterprise
>    networks, including the enterprise networks of the authors'
>    employers" seems to be advocating for a specific approach
>    while the rest of the document is appropriately neutral.
>    IMHO, this paragraph could be removed.
>

The intent of that text is provide an existence proof of networks that do
not use DHCPv6 but still maintain a notion of which MAC addresses
associated with which IPv6 addresses. I've lost count of the number of
times people have told me that this is not possible and that stateful
DHCPv6 address assignment is the only possible way to meet legal
requirements. I've tried to soften this by putting the authors' networks at
the end.


> 16) The document could benefit from adding a section on mobility.
>

I think that mobility is a completely orthogonal problem to how many
addresses are provided to hosts, and that it's out of scope here.

Cheers,
Lorenzo

--001a11c0144ad7b4bb052c7f8ccf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 23, 2016 at 7:31 AM, Templin, Fred L <Fred.L.Templin@boei=
ng.com> wrote:
First, the document throug=
hout uses expressions of the form "networks

provide hosts with multiple global addresses" but IMHO that implies=C2=
=A0 a

sort of "push" operation where the network pushes addresses onto =
the

host which is not the way things work in practice. I think a more appropria=
te

expression form would be "networks provide hosts with a means to obtai=
n

multiple global addresses".

We'=
;ve already gone through the draft to change the terminology once (from &qu=
ot;assign addresses" to the current "provide addresses"). I&=
#39;m not sure that changing it again from "provide addresses" to=
 "provide a means to obtain addresses" provides much value.
=


To me, "provide" does not a imply push operat=
ion. The network can also provide addresses / prefixes on request (e.g., if=
 the host sends an RS or a DHCPv6 solicit.)
=C2=A0

Second, the document seems to imply in several places that SLAAC can

be used as a sort of implicit prefix delegation service; presumably in the<=
br>
same spirit as RFC7278. If that is the intention, then it also needs to say=


that the host needs to have some way of knowing outside of the scope

of the node requirement standards that the prefix is being delegated

for the host's exclusive use. For example, an unmodified host that obey=
s

RFC4861 on a WiFi link would have no way of knowing that a prefix

advertised in a PIO with (A=3D1; L=3D0) is in fact being delegated for its =
own

exclusive use. The document therefore needs to note this rather than

imply that an unmodified host can use SLAAC for prefix delegation.

It is not the intention of the draft to imply t=
his. In fact, it explicitly says the opposite: "If the host is aware t=
hat the prefix is dedicated (e.g., if it was provided via DHCPv6 PD and not=
 SLAAC)..." Knowing that a prefix in the RA is dedicated or not would =
require protocol changes. We could consider those in the future, but not in=
 v6ops, because protocol changes are not something that is in the remit of =
this WG.=C2=A0

The following addresses some of you=
r inline points. I think the others are either minor editorial issues with =
no substantive implications or are already covered by the two main points a=
bove.

8) Section 6, under the heading =
"Using Stateless Address

=C2=A0 =C2=A0Autoconfiguration [RFC4862]." This section does not make<=
br>
=C2=A0 =C2=A0a statement as to whether the "dedicated /64 prefix"=
 is

=C2=A0 =C2=A0to be used only for SLAAC on the interface over which the

=C2=A0 =C2=A0prefix is advertised, or whether the prefix can be

=C2=A0 =C2=A0extended to a LAN link as in RFC7278.

I don't think the draft needs to say this. RFC4862 does not con=
tain anything about extending the prefix to other hosts.

While the draft does cite RFC7278 elsewhere, RFC7278 is specific to =
only one type of link layer (3GPP links). So I think the text is unambiguou=
s: if you're on a 3GPP network, you can use RFC7278, and if not, any ab=
ility to extend the prefix is unspecified. There's ND proxying, but it&=
#39;s experimental.

Also see my prior point about =
protocol changes.
=C2=A0

9) Sectin 6, under the heading "Using Stateful DHCPv6 address

=C2=A0 =C2=A0assignment [RFC3315]" final sentence in the paragraph say=
s

=C2=A0 =C2=A0"The number of IPv6 addresses that can be provided in a
=C2=A0 =C2=A0single DHCPv6 packet is approximately 30." but it does
=C2=A0 =C2=A0not say where the "30" came from. Is it because of p=
acket

=C2=A0 =C2=A0size limitations? Some protocol constant? Something else?

=C2=A0 =C2=A0Suggest adding a trailing phrase giving some rationale

=C2=A0 =C2=A0for the "30".

In=
 section 8 the draft already says "the approximately 30 addresses that=
 can fit into a single packet". I've modified the text you pointed=
 to with "The maximum number of IPv6 addresses that can be provided in=
 a single DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is a=
pproximately 30.".

10) Table 1, &=
quot;Extend network" is listed as "Yes" for SLAAC,

=C2=A0 =C2=A0which would seem to imply that SLAAC is intended to extend

=C2=A0 =C2=A0the prefix to a LAN link as in RFC7278. But, that can only

=C2=A0 =C2=A0be possible when the host has some way of knowing that the

=C2=A0 =C2=A0prefix has been "delegated" which is outside the sco=
pe of

=C2=A0 =C2=A0RFC4861. Can be addressed by adding a "**" next to t=
he

=C2=A0 =C2=A0Yes with the footnote:

I&#=
39;ve changed that to No+, with "[+] Except on certain networks, e.g.,=
 [RFC7278]." There is currently no specified way for a host to do this=
 except ND proxying, which is experimental.


11) Table 1, ""Unlimited" endpoints is listed as "No&qu=
ot; for

=C2=A0 =C2=A0DHCPv6 PD. Shouldn't it be a "Yes"?

No. The network cannot provide prefix delegations t=
o an unlimited number of endpoints. It can only provide prefix delegations =
to as many endpoints as it has available /64s. This is different from both =
SLAAC and IA_NA, where, absent scaling limitations, an "unlimited"=
; number of endpoints can fit in one /64. I've changed the row name fro=
m "Unlimited" endpoints to Number "unlimited" endpoints=
.
=C2=A0
13) Section 8, "The prefix MA=
Y be provided using DHCPv6 PD,

=C2=A0 =C2=A0SLAAC with per-device VLANs, or any other means." Two iss=
ue

=C2=A0 =C2=A0with this - first, the text earlier also included "wirele=
ss

=C2=A0 =C2=A0network where every MAC address is placed in its own

=C2=A0 =C2=A0broadcast domain" which should also be reiterated here.

I don't see a reason to reiterate on=
e of the means to do so, given that this sentence already says "or any=
 other means".
=C2=A0
14) Section 9.1,=
 rename section as simply "Host Tracking", since

=C2=A0 =C2=A0the section covers both stateful and SLAAC.

Fair enough.
=C2=A0
15) S=
ection 9.1, paragraph beginning "Many large enterprise

=C2=A0 =C2=A0networks, including the enterprise networks of the authors'=
;

=C2=A0 =C2=A0employers" seems to be advocating for a specific approach=


=C2=A0 =C2=A0while the rest of the document is appropriately neutral.

=C2=A0 =C2=A0IMHO, this paragraph could be removed.
The intent of that text is provide an existence proof of netwo=
rks that do not use DHCPv6 but still maintain a notion of which MAC address=
es associated with which IPv6 addresses. I've lost count of the number =
of times people have told me that this is not possible and that stateful DH=
CPv6 address assignment is the only=C2=A0possible=C2=A0way to meet legal re=
quirements. I've tried to soften this by putting the authors' netwo=
rks at the end.
=C2=A0

16) The document could benefit from adding a section on mobility.

I think that mobility is a completely orthogonal=
 problem to how many addresses are provided to hosts, and that it's out=
 of scope here.

Cheers,
Lorenzo


--001a11c0144ad7b4bb052c7f8ccf--


From nobody Wed Feb 24 00:12:33 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078B71B331A for ; Wed, 24 Feb 2016 00:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level: 
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yXl0aeRAlJg for ; Wed, 24 Feb 2016 00:12:30 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5652A1B2F93 for ; Wed, 24 Feb 2016 00:12:29 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEX88054; Wed, 24 Feb 2016 08:12:26 +0000 (GMT)
Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 24 Feb 2016 08:12:25 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 24 Feb 2016 08:12:25 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 24 Feb 2016 16:12:19 +0800
From: "Liubing (Leo)" 
To: Fernando Gont , "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" 
Thread-Topic: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
Thread-Index: AQHRbc4WXdeH8AUELEm3F2sYZRE8EJ844qwAgAAQJgCAAeTm8A==
Date: Wed, 24 Feb 2016 08:12:19 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D461C3@nkgeml514-mbx.china.huawei.com>
References: <56CBA254.2090107@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2D45C70@nkgeml514-mbx.china.huawei.com> <56CC3D40.1080007@si6networks.com>
In-Reply-To: <56CC3D40.1080007@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56CD65EB.0086, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 305d5db881a534940e44aa82fa02086e
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 08:12:33 -0000

Hi Fernando,

> >> ** Technical **
> >>
> >> * Section 1, page 3:
> >>> The M and O flags are advisory, not prescriptive.  For example, the
> >>> M flag indicates that addresses are available from DHCPv6, but It
> >>> does not indicate that hosts are required to acquire addresses from
> >>> DHCPv6.  Similar statements can be made about the O flag.  (A flag
> >> is
> >>> also advisory by definition in standard, but it is quite
> >>> prescriptive in implementations according to the test results in the
> >>> appendix.)
> >>
> >> mm.. could you quote something from RFC4862 regarding these bits
> >> "being advisory"?
> > [Bing] In the previous version SLAAC (RFC2462), there was some nice
> > prescriptive processing of the flags, but it was just removed in
> > RFC4862 as stated "Removed the text regarding the M and O flags,
> > considering the maturity of implementations and operational
> > experiences...". I believe that is the main reason of why current
> > OSes' behavior diverts.
>=20
> It would be great if you could elaborate a bit on this.
[Bing] No problem, will do.


> >> * Appendix A, page 12:
> >>>
> >>> The authors from two orgnizations tested different scenarios
> >>> independent of each other.
> >>
> >> It's not clear from this text whether you tested the same thing, or
> >> different things (i.e., no overlap, partial overlap, or full overlap
> >> of the tests).
> >>
> >> While it is valuable to indicate that multiple tests were performed
> >> independently (i.e., they were validated), what's useful from the pov
> >> of the reader is to get the aggregate of the tests, possibly in a
> >> table.
> >>
> >> If all the overlapping text shielded the same result, please say so,
> >> and just publish the aggregate of the results. If the same test
> >> shielded a different result in each of the test scenarios, please
> >> note which ones, and try to explain why the same test shielded a
> >> different result.
> > [Bing] Good point, thanks. The two tests were partial overlapped, and
> > the overlapped part was consistent in results. We just aggregated the
> > results as Section 4, and keep the raw details of the two tests in the
> > Appendix. When people read the document, we assume it is sufficient to
> > get aware of the problems from the main body text; and if somebody
> > interested in the test details, then he/she could get it in the
> > Appendix. Do you think it's ok?
>=20
> I'd just keep the aggregate results. i.e., if both independent test shiel=
ded the
> same results, then there's no need to provide details about the two testi=
ng
> setups.
[Bing] Ok, I'll try to eliminate the redundant cases of the two testing set=
ups. Thanks.

Best regards,
Bing

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


From nobody Wed Feb 24 00:59:37 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B341B4891 for ; Wed, 24 Feb 2016 00:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.607
X-Spam-Level: 
X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLM96se2pTZT for ; Wed, 24 Feb 2016 00:59:34 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BBDCA1B488E for ; Wed, 24 Feb 2016 00:59:33 -0800 (PST)
Received: (qmail 4774 invoked from network); 24 Feb 2016 08:59:30 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Feb 2016 08:59:30 -0000
Date: Wed, 24 Feb 2016 09:59:30 +0100 (CET)
Message-Id: <20160224.095930.74682405.sthaug@nethelp.no>
To: lorenzo@google.com
From: sthaug@nethelp.no
In-Reply-To: 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> 
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 08:59:36 -0000

> 1. I disagree with the statement "It is unclear whether hosts should
> initiate DHCPv6 by themselves if there are no RAs at all." There is not
> really point in using DHCPv6 without RAs. This is because DHCPv6 does not
> configure prefixes, only addresses without prefix lengths, and therefore an
> address assigned by DHCPv6 either has no prefix length or a prefix length
> of /128. See dhcpv6bs ticket 68:
> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
> 
> So starting DHCPv6 without an RA is pointless because even if you get an
> address, you can't use to talk to anything. Thus, I don't think there is
> any ambiguity here, since one of the alternatives doesn't make sense. That
> said, if we do still want to say this is ambiguous, then we should replace
> "ambiguous" with "unspecified", and add something about the fact that
> DHCPv6 without RAs is useless, such as:

I can absolutely see this point of view. On the other hand - given that
the M-bit is only a hint: If I were a CPE manufacturer, I might find it
perfectly rational to *always* start DHCPv6 (for simplicity's sake). I
believe we've seen more than one CPE model doing exactly that.

Steinar Haug, AS2116


From nobody Wed Feb 24 04:15:29 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524401ACC8C for ; Wed, 24 Feb 2016 04:15:27 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeLCiX3oXlJt for ; Wed, 24 Feb 2016 04:15:25 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 792E21AC44B for ; Wed, 24 Feb 2016 04:15:23 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aYYLc-0000I2C; Wed, 24 Feb 2016 13:15:16 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org> <56CCAE79.6040506@gmail.com> <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org> <20160223205336.125bd80b@envy.w5.y.home> <86B8D348-C288-49B9-9CC8-D98AA71FE6C9@employees.org> 
In-reply-to: Your message of "Tue, 23 Feb 2016 21:00:44 +0100 ." <86B8D348-C288-49B9-9CC8-D98AA71FE6C9@employees.org> 
Date: Wed, 24 Feb 2016 13:15:06 +0100
Archived-At: 
Cc: Tore Anderson 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 12:15:27 -0000

>>> router - host: host has state (from router discovery) and can do NUD
>>> if it cares.
>> 
>> Yep. For that to work, though, the router will need to respond to the
>> host's NUD/NS queries with NAs.
>> 
>> My impression from reading this thread has been that some (most?)
>> routers/stacks won't bother to do. Have I misunderstood?
>
>I would consider that implementation broken.

I wonder about the statistics. 

I agree that also on p2p links nodes should respond to a NS with an NA if
the address is configured on the interface.

However, if most systems at the moment don't do that, then it will be an
uphill battle. 


From nobody Wed Feb 24 10:33:07 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6B61B3C18 for ; Wed, 24 Feb 2016 10:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.907
X-Spam-Level: 
X-Spam-Status: No, score=-13.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_MkbfEVfbQ5 for ; Wed, 24 Feb 2016 10:33:04 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290C21B3BEF for ; Wed, 24 Feb 2016 10:33:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2760; q=dns/txt; s=iport; t=1456338781; x=1457548381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ABwkbruAf5AgsVs+D1mJGml2C80fApiOcoxQu7N6VIY=; b=JbEMwu5Z3XS32D6B08FD5r7e1b0k1oGluXdf0u7G5aPqj2KDdegGnWsv JbUNlKfiH7ZCcA9dUqwNm4VGZ32EdMRPW1yX1M8sfA3Y7Ngod4QmyzSQJ sRH0kFoozg5GEngULlMhSfInqREkzSGXcFlZVihr9RcF+NT3UzqizbeVQ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGBQDe9s1W/4oNJK1egzpSbQa7B4FmF?= =?us-ascii?q?wqFbQKBRjoSAQEBAQEBAWQnhEEBAQEDAQEBATc0CwUHBAIBCBEEAQEfCQcnCxQ?= =?us-ascii?q?JCAIEAQ0FCIgPCA69dAEBAQEBAQEBAQEBAQEBAQEBAQEBARWKTIQjOIQUBYdbj?= =?us-ascii?q?ywBhVeIAIIwjEuOSAEnATqCAxmBSGoBhmJ9AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="74359983"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2016 18:33:00 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1OIX078021230 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 18:33:00 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 12:32:59 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 12:32:59 -0600
From: "Bernie Volz (volz)" 
To: "sthaug@nethelp.no" , "lorenzo@google.com" 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbtDYgyxsgc1lDUiVCcDFx3Clvp87SksAgAA5mKA=
Date: Wed, 24 Feb 2016 18:32:59 +0000
Message-ID: 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>
In-Reply-To: <20160224.095930.74682405.sthaug@nethelp.no>
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: [10.131.77.57]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:33:06 -0000

CPE are both hosts and routers. Their specification is defined in RFC 7084.

With respect to the host (address assignment) side:

   WAA-6:   If the IPv6 CE router receives a Router Advertisement
            message (described in [RFC4861]) with the M flag set to 1,
            the IPv6 CE router MUST do DHCPv6 address assignment
            (request an IA_NA option).

With respect to the router (prefix delegation) side:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

Though for the PD case, it doesn't say what to do if there is no RA (out of=
 scope!).

So, for the CPE (with respect to the host side, which is what draft-ietf-v6=
ops-dhcpv6-slaac-problem is about), it agrees with Lorenzo's analysis.

- Bernie

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of sthaug@nethelp.no
Sent: Wednesday, February 24, 2016 4:00 AM
To: lorenzo@google.com
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

> 1. I disagree with the statement "It is unclear whether hosts should=20
> initiate DHCPv6 by themselves if there are no RAs at all." There is=20
> not really point in using DHCPv6 without RAs. This is because DHCPv6=20
> does not configure prefixes, only addresses without prefix lengths,=20
> and therefore an address assigned by DHCPv6 either has no prefix=20
> length or a prefix length of /128. See dhcpv6bs ticket 68:
> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
>=20
> So starting DHCPv6 without an RA is pointless because even if you get=20
> an address, you can't use to talk to anything. Thus, I don't think=20
> there is any ambiguity here, since one of the alternatives doesn't=20
> make sense. That said, if we do still want to say this is ambiguous,=20
> then we should replace "ambiguous" with "unspecified", and add=20
> something about the fact that
> DHCPv6 without RAs is useless, such as:

I can absolutely see this point of view. On the other hand - given that the=
 M-bit is only a hint: If I were a CPE manufacturer, I might find it perfec=
tly rational to *always* start DHCPv6 (for simplicity's sake). I believe we=
've seen more than one CPE model doing exactly that.

Steinar Haug, AS2116

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Feb 24 15:26:39 2016
Return-Path: 
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B101A070E; Wed, 24 Feb 2016 15:26:36 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20160224232636.26818.77672.idtracker@ietfa.amsl.com>
Date: Wed, 24 Feb 2016 15:26:36 -0800
Archived-At: 
Cc: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, joelja@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org
Subject: [v6ops] Last Call:  (Host address availability recommendations) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 23:26:36 -0000

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Host address availability recommendations'
   as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document recommends that networks provide general-purpose end
   hosts with multiple global IPv6 addresses when they attach, and
   describes the benefits of and the options for doing so.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Wed Feb 24 15:29:23 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7091A8904 for ; Wed, 24 Feb 2016 15:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.507
X-Spam-Level: 
X-Spam-Status: No, score=-114.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knqXxLUF1Hsz for ; Wed, 24 Feb 2016 15:29:20 -0800 (PST)
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 000641A88EB for ; Wed, 24 Feb 2016 15:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8839; q=dns/txt; s=iport; t=1456356559; x=1457566159; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ib0oLvVrf/5x19mLHRdYgj/6kw5FvM+92/ezVgUNOg4=; b=Pm5w8cB+MftrN/AE9Xd7sdhwvjWf6cwTtatDyJo36vgnaIGzoWUa1juo mILxLsNyw6VSs/6D2IUS6aYos/mOtW5Dg4YDAStevc7Gvs9dDers/Kv0S CBzaFJ/K1XfXdhJRLpYoJq4539gcxJefJ9AWNSAxB5zF1qeiUoY5wl3vI Y=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAgBEPM5W/49dJa1egzpSbQa6aw6BZ?= =?us-ascii?q?hcKhW0CgT44FAEBAQEBAQFkJ4RBAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FDog?= =?us-ascii?q?JCA69ZwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBId+CIJGhA9egnOBDwWXBwGDC?= =?us-ascii?q?IFkiHKOdI5IAR4BQ4NkagGGJT19AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,495,1449532800";  d="asc'?scan'208";a="76553278"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 23:29:18 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1ONTIQf014599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 23:29: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.1104.5; Wed, 24 Feb 2016 17:29:17 -0600
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.1104.009; Wed, 24 Feb 2016 17:29:17 -0600
From: "Fred Baker (fred)" 
To: Fred Templin 
Thread-Topic: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05
Thread-Index: AQHRb1suDBnjXeZTrUmoeJLOi27mxw==
Date: Wed, 24 Feb 2016 23:29:17 +0000
Message-ID: <5D456DA5-FD4F-4613-9E66-0C4BDB164DB0@cisco.com>
References: <2134F8430051B64F815C691A62D983183396E593@XCH-BLV-105.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D983183396E593@XCH-BLV-105.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.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.101.171]
Content-Type: multipart/signed; boundary="Apple-Mail=_CE0E3B3C-D84C-448A-B4AF-223C8EDA0BFB"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 23:29:22 -0000

--Apple-Mail=_CE0E3B3C-D84C-448A-B4AF-223C8EDA0BFB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for the review. The document was just sent to IETF Last Call by =
the IESG, having finished working group processes some time ago. I might =
suggest you repeat this note in that context.

My personal (as in, not chair) thoughts on the two points are:

On the first point, I can go either way. SLAAC and DHCP/DHCPv6 have the =
device "obtaining" addresses from the network, while DHCP-PD has the =
network "providing" a prefix to the system. In language designed to =
cover both cases, which this is, either wording is arguably right and =
arguably wrong. I'm personally OK with the existing language.

The second, SLAAC delivering knowledge of a non-/64 prefix from which =
the network is requiring to to select addresses, is a protocol change, =
which is out of scope for v6ops. I think I understand what you're =
getting at, and 6man may want to consider that, but I don't believe that =
there is a current consensus in v6ops to make such a change.

The other Fred

> On Feb 22, 2016, at 3:31 PM, Templin, Fred L =
 wrote:
>=20
> Hi,
>=20
> I told Fred B. that I would review this document and post comments.
> Overall, I think the document is in reasonably good shape but I have
> two primary suggested areas for improvement.
>=20
> First, the document throughout uses expressions of the form "networks
> provide hosts with multiple global addresses" but IMHO that implies  a
> sort of "push" operation where the network pushes addresses onto the
> host which is not the way things work in practice. I think a more =
appropriate
> expression form would be "networks provide hosts with a means to =
obtain
> multiple global addresses".
>=20
> Second, the document seems to imply in several places that SLAAC can
> be used as a sort of implicit prefix delegation service; presumably in =
the
> same spirit as RFC7278. If that is the intention, then it also needs =
to say
> that the host needs to have some way of knowing outside of the scope
> of the node requirement standards that the prefix is being delegated
> for the host's exclusive use. For example, an unmodified host that =
obeys
> RFC4861 on a WiFi link would have no way of knowing that a prefix
> advertised in a PIO with (A=3D1; L=3D0) is in fact being delegated for =
its own
> exclusive use. The document therefore needs to note this rather than
> imply that an unmodified host can use SLAAC for prefix delegation.
>=20
> See below for detailed comments, including those related to the two
> primary themes as well as others:
>=20
> Fred
> fred.l.templin@boeing.com
>=20
> ---
>=20
> 1) Introduction, "It recommends that networks provide
>   general-purpose end hosts with multiple global addresses"
>   suggest changing to: "It recommends that networks provide
>   general-purpose end hosts with a means to obtain
>   multiple global addresses".
>=20
> 2) Section 3, "Today there are many host functions that
>   require more than one IP address to be available to
>   the host:" suggest changing to: "Today there are many
>   host functions that require more than one IP address to
>   be available to the to the host, including:"
>=20
> 3) Section 4, "Providing a restricted number of addresses"
>   suggest changing to: "Restricting the number of
>   addresses".
>=20
> 4) Section 4, "e.g., if the network provides only one IPv6
>   address per host" suggest changing to: "e.g., if the
>   network permits only one IPv6 address per host".
>=20
> 5) Section 5, "and even when the decision to provide only
>   one IPv6 address per device ... because devices can
>   share their IPv6 address with other devices." suggest
>   changing to: "and even when the decision to permit only
>   limited numbers of IPv6 addresses per device ... because
>   devices can share their IPv6 addresses with other devices."
>=20
> 6) Section 6, title: "Options for providing more than one
>   address" suggest changing to: "Multi-addressing Options".
>=20
> 7) Section 6, "Multiple IPv6 addresses can be provided in
>   the following ways:" suggest changing to: "Hosts can
>   obtain multiple IPv6 addresses in the following ways:"
>=20
> 8) Section 6, under the heading "Using Stateless Address
>   Autoconfiguration [RFC4862]." This section does not make
>   a statement as to whether the "dedicated /64 prefix" is
>   to be used only for SLAAC on the interface over which the
>   prefix is advertised, or whether the prefix can be
>   extended to a LAN link as in RFC7278. If the intention
>   is the latter, then the host would need to have some
>   means of knowing that the prefix is indeed dedicated,
>   but RFC4861 only says that "L=3D0" means that the PIO
>   contains no information about the on/off-link property
>   of the prefix.
>=20
> 9) Sectin 6, under the heading "Using Stateful DHCPv6 address
>   assignment [RFC3315]" final sentence in the paragraph says
>   "The number of IPv6 addresses that can be provided in a
>   single DHCPv6 packet is approximately 30." but it does
>   not say where the "30" came from. Is it because of packet
>   size limitations? Some protocol constant? Something else?
>   Suggest adding a trailing phrase giving some rationale
>   for the "30".
>=20
> 10) Table 1, "Extend network" is listed as "Yes" for SLAAC,
>   which would seem to imply that SLAAC is intended to extend
>   the prefix to a LAN link as in RFC7278. But, that can only
>   be possible when the host has some way of knowing that the
>   prefix has been "delegated" which is outside the scope of
>   RFC4861. Can be addressed by adding a "**" next to the
>   Yes with the footnote:
>=20
>   (**) If the host has knowledge that the prefix has been
>        dedicated for its own exclusive use.
>=20
> 11) Table 1, ""Unlimited" endpoints is listed as "No" for
>   DHCPv6 PD. Shouldn't it be a "Yes"?
>=20
> 12) Section 8, "it is RECOMMENDED that IPv6 network deployments
>   provide multiple IPv6 addresses from each prefix to general
>   purpose hosts." suggest changing to: "it is RECOMMENDED that
>   IPv6 network deployments provide general-purpose hosts with
>   a means to obtain multiple IPv6 addresses from each prefix".
>=20
> 13) Section 8, "The prefix MAY be provided using DHCPv6 PD,
>   SLAAC with per-device VLANs, or any other means." Two issue
>   with this - first, the text earlier also included "wireless
>   network where every MAC address is placed in its own
>   broadcast domain" which should also be reiterated here.
>   Second (as with comments 8 and 10), for SLAAC-based methods
>   the document needs to say that the host must have some way
>   of knowing that the prefix has been dedicated for its own
>   exclusive use beyond the existing IPv6 node requirements
>   (i.e., beyond RFC4861).
>=20
> 14) Section 9.1, rename section as simply "Host Tracking", since
>   the section covers both stateful and SLAAC.
>=20
> 15) Section 9.1, paragraph beginning "Many large enterprise
>   networks, including the enterprise networks of the authors'
>   employers" seems to be advocating for a specific approach
>   while the rest of the document is appropriately neutral.
>   IMHO, this paragraph could be removed.
>=20
> 16) The document could benefit from adding a section on mobility.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail=_CE0E3B3C-D84C-448A-B4AF-223C8EDA0BFB
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

iQIVAwUBVs48zUayAOS/EQ8MAQJbThAAlL4n8W4MzcUEsmWJMItb683IewVRtRHI
Na90QdsnAhoIdZuLayIzAy3uQquvA2a2yTWKgNu3RsE1uWSqbJd6/3Di9fKSEirC
sGZ5D+hpxGh5ZWj6OJSVtekPsdbHIJa+d1O9ssnkw1zIp0AuVIOJQ0XkeKDzNW4N
BA9Xc0+vCel1ZRFVSmVJVmQNFEP/zQCHbggV1g2N+MuXHvjqzaIX7Aukhbnw/3n8
/uNcUcPJrv3Y+kp6Jgfn2l8EoO4MRY6Dytf2wPX52HgvbZ8rT3GGZg77W4UjjHd8
Hq3QfJhISjJgL0VfNXIa/NY2PWxVs1V9FthgEXOjktnxW7EifvgVuoJvQ7xJyl+r
tbn+MfjK9n8HGZtCs27pip74By5GUNJmo6B9PouyNgSMJpy3nAwK5QECfAQ2SEdd
RoOSgxvOh/xOhiQxXeFhq0+SgjgWCvcpLh9zF5TF6oJ/i42UpUg22nPFi5VDqD+3
UgYX/lFLdXM2s4+Rbb2s8I9iWW0Q4G2hSnL2293Ddvhb0mbz6nQEwSJ11vbD/yDx
cLioa653/dC/MNVIi82ggZOeViDGC/Aoo6mPvK3licDDjgYgyxGu5msdP/dwjXvt
sCHPZoDGKcqnaq4ZrTFaJLlpat8zYKao35Fh9ifK5guV/g0PMnvQIgo0AnPnMm7F
rjOO7RTHzCY=
=DpbU
-----END PGP SIGNATURE-----

--Apple-Mail=_CE0E3B3C-D84C-448A-B4AF-223C8EDA0BFB--


From nobody Wed Feb 24 16:11:59 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6B1A8966 for ; Wed, 24 Feb 2016 16:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.907
X-Spam-Level: 
X-Spam-Status: No, score=-13.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz958-Q_-TXQ for ; Wed, 24 Feb 2016 16:11:56 -0800 (PST)
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 ED0681A1B13 for ; Wed, 24 Feb 2016 16:11:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1456359110; x=1457568710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ze0tutzWFuvpKuiVIl9P2V2ggG6+SWrFzx+uJsOVWuI=; b=JZMwxqqqrBJZAthY/fLpezjX+KZLiATv5atErueMBmhOe6Z/cejjczWx bYICNGfh796wRTagLv6h54HMl2Va9dWUYcl+HJ3zeoWU+2zyYKDaZqh4P 0XthK/s3Qlvw2uPNRFi5gClvbSA09/6QaWqSxFs4tNnOOdnC7XMc6p6rJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgB3Rc5W/5tdJa1egzpSXg+6cQENg?= =?us-ascii?q?WYXCoVtAoE+OBQBAQEBAQEBZCeEQQEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQc?= =?us-ascii?q?nCxQJCAIEDgWIFwgOvW0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKBbIJOhCMQK?= =?us-ascii?q?IMFgQ8Fh1uPLAGFV4gHgimMS45IAR4BAUKCAxmBSGoBh18BAQE?=
X-IronPort-AV: E=Sophos;i="5.22,495,1449532800"; d="scan'208";a="76567265"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2016 00:11:50 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1P0BoJE014112 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2016 00:11:50 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 18:11:49 -0600
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; Wed, 24 Feb 2016 18:11:49 -0600
From: "Rajiv Asati (rajiva)" 
To: "Bernie Volz (volz)" 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbNo04muWj7mmQkeNAnAx3wsjGZ87LGGAgAAh1wCAAKA7gP//+ha5
Date: Thu, 25 Feb 2016 00:11:48 +0000
Message-ID: <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>, 
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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 00:11:58 -0000

I agree that starting DHCPv6 without an RA is pointless / useless. And the =
draft should just state that.=20

But if the draft is referring to any existing RFC, then it is reasonable to=
 say the behavior not being specified (or unclear). Just avoid hair-splitti=
ng.=20

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


> On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz)  wrote:
>=20
> CPE are both hosts and routers. Their specification is defined in RFC 708=
4.
>=20
> With respect to the host (address assignment) side:
>=20
>   WAA-6:   If the IPv6 CE router receives a Router Advertisement
>            message (described in [RFC4861]) with the M flag set to 1,
>            the IPv6 CE router MUST do DHCPv6 address assignment
>            (request an IA_NA option).
>=20
> With respect to the router (prefix delegation) side:
>=20
>   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>           delegation when either the M or O flags are set to 1 in a
>           received Router Advertisement (RA) message.  Behavior of the
>           CE router to use DHCPv6 prefix delegation when the CE router
>           has not received any RA or received an RA with the M and the
>           O bits set to zero is out of scope for this document.
>=20
> Though for the PD case, it doesn't say what to do if there is no RA (out =
of scope!).
>=20
> So, for the CPE (with respect to the host side, which is what draft-ietf-=
v6ops-dhcpv6-slaac-problem is about), it agrees with Lorenzo's analysis.
>=20
> - Bernie
>=20
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of sthaug@nethelp.n=
o
> Sent: Wednesday, February 24, 2016 4:00 AM
> To: lorenzo@google.com
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
>=20
>> 1. I disagree with the statement "It is unclear whether hosts should=20
>> initiate DHCPv6 by themselves if there are no RAs at all." There is=20
>> not really point in using DHCPv6 without RAs. This is because DHCPv6=20
>> does not configure prefixes, only addresses without prefix lengths,=20
>> and therefore an address assigned by DHCPv6 either has no prefix=20
>> length or a prefix length of /128. See dhcpv6bs ticket 68:
>> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
>>=20
>> So starting DHCPv6 without an RA is pointless because even if you get=20
>> an address, you can't use to talk to anything. Thus, I don't think=20
>> there is any ambiguity here, since one of the alternatives doesn't=20
>> make sense. That said, if we do still want to say this is ambiguous,=20
>> then we should replace "ambiguous" with "unspecified", and add=20
>> something about the fact that
>> DHCPv6 without RAs is useless, such as:
>=20
> I can absolutely see this point of view. On the other hand - given that t=
he M-bit is only a hint: If I were a CPE manufacturer, I might find it perf=
ectly rational to *always* start DHCPv6 (for simplicity's sake). I believe =
we've seen more than one CPE model doing exactly that.
>=20
> Steinar Haug, AS2116
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Feb 24 16:46:49 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB51A1A72; Wed, 24 Feb 2016 16:46:48 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCLS38wmcMb2; Wed, 24 Feb 2016 16:46:44 -0800 (PST)
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 ECCCB1A0143; Wed, 24 Feb 2016 16:46:43 -0800 (PST)
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 u1P0khh3056651; Wed, 24 Feb 2016 17:46:43 -0700
Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1P0kZeN056617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 24 Feb 2016 17:46:36 -0700
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.79]) with mapi id 14.03.0235.001; Wed, 24 Feb 2016 16:46:34 -0800
From: "Templin, Fred L" 
To: Lorenzo Colitti 
Thread-Topic: Last Call:  (Host address availability recommendations) to Best Current Practice
Thread-Index: AdFvZC/N+ySF3GaKS7OjPiJBaMC6jg==
Date: Thu, 25 Feb 2016 00:46:34 +0000
Message-ID: <2134F8430051B64F815C691A62D98318339719CE@XCH-BLV-105.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D98318339719CEXCHBLV105nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org WG" , "ietf@ietf.org" 
Subject: Re: [v6ops] Last Call:  (Host address availability recommendations) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 00:46:48 -0000

--_000_2134F8430051B64F815C691A62D98318339719CEXCHBLV105nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2VlIGJlbG93IGZvciBjb21tZW50cyBhbmQgcmVqb2luZGVycyBvbiB0aGlzIGRvY3VtZW50IGZy
b20gYW4gZWFybGllciBkaXNjdXNzaW9uDQp0aHJlYWQgb24gdGhlIHY2b3BzIGxpc3QuIFBsZWFz
ZSB1c2UgdGhpcyB0aHJlYWQgZm9yIGFueSBmb2xsb3ctdXAgZGlzY3Vzc2lvbi4NCg0KVGhhbmtz
IOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206IExvcmVuem8gQ29s
aXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMjQsIDIwMTYgMTI6MDcgQU0NClRvOiBUZW1wbGluLCBGcmVkIEwNCkNjOiB2Nm9wc0BpZXRm
Lm9yZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi12Nm9w
cy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA1DQoNCk9uIFR1ZSwgRmViIDIzLCAyMDE2IGF0IDc6
MzEgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86
RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KRmlyc3QsIHRoZSBkb2N1bWVudCB0
aHJvdWdob3V0IHVzZXMgZXhwcmVzc2lvbnMgb2YgdGhlIGZvcm0gIm5ldHdvcmtzDQpwcm92aWRl
IGhvc3RzIHdpdGggbXVsdGlwbGUgZ2xvYmFsIGFkZHJlc3NlcyIgYnV0IElNSE8gdGhhdCBpbXBs
aWVzICBhDQpzb3J0IG9mICJwdXNoIiBvcGVyYXRpb24gd2hlcmUgdGhlIG5ldHdvcmsgcHVzaGVz
IGFkZHJlc3NlcyBvbnRvIHRoZQ0KaG9zdCB3aGljaCBpcyBub3QgdGhlIHdheSB0aGluZ3Mgd29y
ayBpbiBwcmFjdGljZS4gSSB0aGluayBhIG1vcmUgYXBwcm9wcmlhdGUNCmV4cHJlc3Npb24gZm9y
bSB3b3VsZCBiZSAibmV0d29ya3MgcHJvdmlkZSBob3N0cyB3aXRoIGEgbWVhbnMgdG8gb2J0YWlu
DQptdWx0aXBsZSBnbG9iYWwgYWRkcmVzc2VzIi4NCg0KV2UndmUgYWxyZWFkeSBnb25lIHRocm91
Z2ggdGhlIGRyYWZ0IHRvIGNoYW5nZSB0aGUgdGVybWlub2xvZ3kgb25jZSAoZnJvbSAiYXNzaWdu
IGFkZHJlc3NlcyIgdG8gdGhlIGN1cnJlbnQgInByb3ZpZGUgYWRkcmVzc2VzIikuIEknbSBub3Qg
c3VyZSB0aGF0IGNoYW5naW5nIGl0IGFnYWluIGZyb20gInByb3ZpZGUgYWRkcmVzc2VzIiB0byAi
cHJvdmlkZSBhIG1lYW5zIHRvIG9idGFpbiBhZGRyZXNzZXMiIHByb3ZpZGVzIG11Y2ggdmFsdWUu
DQoNCkZMVD4+PiBDZXJ0YWlubHkg4oCccHJvdmlkZeKAnSBpcyBtdWNoIGJldHRlciB0aGFuIOKA
nGFzc2lnbuKAnSwgYnV0IGl0IGlzIHVwIHRvIHRoZSBob3N0IHRvDQpGTFQ+Pj4gb2J0YWluIChh
bmQgZGVmZW5kKSBpdHMgb3duIGFkZHJlc3NlcyB3aGV0aGVyIGl0IGJlIHRocm91Z2ggU0xBQUMs
DQpGTFQ+Pj4gREhDUHY2LCBtYW51YWwgY29uZmlnLCBvciB3aGF0ZXZlci4gU28sIHRoZSBuZXR3
b3JrIHByb3ZpZGVzIHRoZQ0KRkxUPj4+IG1lYW5zIHRvIG9idGFpbiBhZGRyZXNzZXMgd2hpbGUg
dGhlIGhvc3QgbXVzdCBhY3Qgb24gaXRzIG93biBiZWhhbGYNCkZMVD4+PiB0byBvYnRhaW4gYWRk
cmVzc2VzIChhY3F1aXJlIG1pZ2h0IGV2ZW4gYmUgYSBiZXR0ZXIgd29yZCB0aGFuIG9idGFpbiku
DQoNClRvIG1lLCAicHJvdmlkZSIgZG9lcyBub3QgYSBpbXBseSBwdXNoIG9wZXJhdGlvbi4gVGhl
IG5ldHdvcmsgY2FuIGFsc28gcHJvdmlkZSBhZGRyZXNzZXMgLyBwcmVmaXhlcyBvbiByZXF1ZXN0
IChlLmcuLCBpZiB0aGUgaG9zdCBzZW5kcyBhbiBSUyBvciBhIERIQ1B2NiBzb2xpY2l0LikNCg0K
RkxUPj4+IEkgdGhpbmsgd2Ugc2VlIHRoaXMgaW4gZGlmZmVyZW50IHdheXMsIGJ1dCBJIHVuZGVy
c3RhbmQgdGhlIGRlc2lyZSB0byBub3QNCkZMVD4+PiBvdmVyaGF1bCB0aGUgZG9jdW1lbnQuIEFz
IGEgY29tcHJvbWlzZSwgSSB0aGluayB0aGlzIGNvdWxkIGVhc2lseSBiZQ0KRkxUPj4+IGFkZHJl
c3NlZCBieSBzaW1wbHkgY2hhbmdpbmcgdGhlIGFic3RyYWN0IHRvIHJlYWQ6DQpGTFQ+Pj4NCkZM
VD4+PiAgICAg4oCcVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzIHRoYXQgbmV0d29ya3MgcHJvdmlk
ZSBnZW5lcmFsLXB1cnBvc2UgZW5kDQpGTFQ+Pj4gICAgICAgaG9zdHMgd2l0aCBhIG1lYW5zIHRv
IGFjcXVpcmUgbXVsdGlwbGUgZ2xvYmFsIElQdjYgYWRkcmVzc2VzIHdoZW4gdGhleQ0KRkxUPj4+
ICAgICAgIGF0dGFjaCwgYW5kIGRlc2NyaWJlcyB0aGUgYmVuZWZpdHMgb2YgYW5kIHRoZSBvcHRp
b25zIGZvciBkb2luZyBzby7igJ0NCkZMVD4+Pg0KRkxUPj4+IFRoZW4sIG1ha2Ugbm8gb3RoZXIg
Y2hhbmdlcyBpbiB0aGUgZG9jdW1lbnQsIGFuZCByZWFkZXJzIHdpbGwgc3RpbGwNCkZMVD4+PiB1
bmRlcnN0YW5kIHdoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0Lg0KDQpTZWNvbmQsIHRoZSBkb2N1
bWVudCBzZWVtcyB0byBpbXBseSBpbiBzZXZlcmFsIHBsYWNlcyB0aGF0IFNMQUFDIGNhbg0KYmUg
dXNlZCBhcyBhIHNvcnQgb2YgaW1wbGljaXQgcHJlZml4IGRlbGVnYXRpb24gc2VydmljZTsgcHJl
c3VtYWJseSBpbiB0aGUNCnNhbWUgc3Bpcml0IGFzIFJGQzcyNzguIElmIHRoYXQgaXMgdGhlIGlu
dGVudGlvbiwgdGhlbiBpdCBhbHNvIG5lZWRzIHRvIHNheQ0KdGhhdCB0aGUgaG9zdCBuZWVkcyB0
byBoYXZlIHNvbWUgd2F5IG9mIGtub3dpbmcgb3V0c2lkZSBvZiB0aGUgc2NvcGUNCm9mIHRoZSBu
b2RlIHJlcXVpcmVtZW50IHN0YW5kYXJkcyB0aGF0IHRoZSBwcmVmaXggaXMgYmVpbmcgZGVsZWdh
dGVkDQpmb3IgdGhlIGhvc3QncyBleGNsdXNpdmUgdXNlLiBGb3IgZXhhbXBsZSwgYW4gdW5tb2Rp
ZmllZCBob3N0IHRoYXQgb2JleXMNClJGQzQ4NjEgb24gYSBXaUZpIGxpbmsgd291bGQgaGF2ZSBu
byB3YXkgb2Yga25vd2luZyB0aGF0IGEgcHJlZml4DQphZHZlcnRpc2VkIGluIGEgUElPIHdpdGgg
KEE9MTsgTD0wKSBpcyBpbiBmYWN0IGJlaW5nIGRlbGVnYXRlZCBmb3IgaXRzIG93bg0KZXhjbHVz
aXZlIHVzZS4gVGhlIGRvY3VtZW50IHRoZXJlZm9yZSBuZWVkcyB0byBub3RlIHRoaXMgcmF0aGVy
IHRoYW4NCmltcGx5IHRoYXQgYW4gdW5tb2RpZmllZCBob3N0IGNhbiB1c2UgU0xBQUMgZm9yIHBy
ZWZpeCBkZWxlZ2F0aW9uLg0KDQpJdCBpcyBub3QgdGhlIGludGVudGlvbiBvZiB0aGUgZHJhZnQg
dG8gaW1wbHkgdGhpcy4gSW4gZmFjdCwgaXQgZXhwbGljaXRseSBzYXlzIHRoZSBvcHBvc2l0ZTog
IklmIHRoZSBob3N0IGlzIGF3YXJlIHRoYXQgdGhlIHByZWZpeCBpcyBkZWRpY2F0ZWQgKGUuZy4s
IGlmIGl0IHdhcyBwcm92aWRlZCB2aWEgREhDUHY2IFBEIGFuZCBub3QgU0xBQUMpLi4uIiBLbm93
aW5nIHRoYXQgYSBwcmVmaXggaW4gdGhlIFJBIGlzIGRlZGljYXRlZCBvciBub3Qgd291bGQgcmVx
dWlyZSBwcm90b2NvbCBjaGFuZ2VzLiBXZSBjb3VsZCBjb25zaWRlciB0aG9zZSBpbiB0aGUgZnV0
dXJlLCBidXQgbm90IGluIHY2b3BzLCBiZWNhdXNlIHByb3RvY29sIGNoYW5nZXMgYXJlIG5vdCBz
b21ldGhpbmcgdGhhdCBpcyBpbiB0aGUgcmVtaXQgb2YgdGhpcyBXRy4NCg0KRkxUPj4+IEkgd291
bGQgcHJlZmVyIHRvIHNlZSB0aGUgU2VjdGlvbiA5LjMgc2VudGVuY2UgeW91IGNpdGVkIGFwcGVh
ciBlYXJsaWVyDQpGTFQ+Pj4gaW4gdGhlIGRvY3VtZW50LCBidXQgSSBkb27igJl0IHNlZSB0aGUg
cG9pbnQgaW4gYXJndWluZyBvdmVyIGl0LiBPSyB0byBsZWF2ZQ0KRkxUPj4+IGl0IGFzIGl0IGlz
Lg0KDQpUaGUgZm9sbG93aW5nIGFkZHJlc3NlcyBzb21lIG9mIHlvdXIgaW5saW5lIHBvaW50cy4g
SSB0aGluayB0aGUgb3RoZXJzIGFyZSBlaXRoZXIgbWlub3IgZWRpdG9yaWFsIGlzc3VlcyB3aXRo
IG5vIHN1YnN0YW50aXZlIGltcGxpY2F0aW9ucyBvciBhcmUgYWxyZWFkeSBjb3ZlcmVkIGJ5IHRo
ZSB0d28gbWFpbiBwb2ludHMgYWJvdmUuDQoNCjgpIFNlY3Rpb24gNiwgdW5kZXIgdGhlIGhlYWRp
bmcgIlVzaW5nIFN0YXRlbGVzcyBBZGRyZXNzDQogICBBdXRvY29uZmlndXJhdGlvbiBbUkZDNDg2
Ml0uIiBUaGlzIHNlY3Rpb24gZG9lcyBub3QgbWFrZQ0KICAgYSBzdGF0ZW1lbnQgYXMgdG8gd2hl
dGhlciB0aGUgImRlZGljYXRlZCAvNjQgcHJlZml4IiBpcw0KICAgdG8gYmUgdXNlZCBvbmx5IGZv
ciBTTEFBQyBvbiB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlDQogICBwcmVmaXggaXMgYWR2
ZXJ0aXNlZCwgb3Igd2hldGhlciB0aGUgcHJlZml4IGNhbiBiZQ0KICAgZXh0ZW5kZWQgdG8gYSBM
QU4gbGluayBhcyBpbiBSRkM3Mjc4Lg0KDQpJIGRvbid0IHRoaW5rIHRoZSBkcmFmdCBuZWVkcyB0
byBzYXkgdGhpcy4gUkZDNDg2MiBkb2VzIG5vdCBjb250YWluIGFueXRoaW5nIGFib3V0IGV4dGVu
ZGluZyB0aGUgcHJlZml4IHRvIG90aGVyIGhvc3RzLg0KDQpXaGlsZSB0aGUgZHJhZnQgZG9lcyBj
aXRlIFJGQzcyNzggZWxzZXdoZXJlLCBSRkM3Mjc4IGlzIHNwZWNpZmljIHRvIG9ubHkgb25lIHR5
cGUgb2YgbGluayBsYXllciAoM0dQUCBsaW5rcykuIFNvIEkgdGhpbmsgdGhlIHRleHQgaXMgdW5h
bWJpZ3VvdXM6IGlmIHlvdSdyZSBvbiBhIDNHUFAgbmV0d29yaywgeW91IGNhbiB1c2UgUkZDNzI3
OCwgYW5kIGlmIG5vdCwgYW55IGFiaWxpdHkgdG8gZXh0ZW5kIHRoZSBwcmVmaXggaXMgdW5zcGVj
aWZpZWQuIFRoZXJlJ3MgTkQgcHJveHlpbmcsIGJ1dCBpdCdzIGV4cGVyaW1lbnRhbC4NCg0KQWxz
byBzZWUgbXkgcHJpb3IgcG9pbnQgYWJvdXQgcHJvdG9jb2wgY2hhbmdlcy4NCg0KRkxUPj4+IE9L
Lg0KDQo5KSBTZWN0aW4gNiwgdW5kZXIgdGhlIGhlYWRpbmcgIlVzaW5nIFN0YXRlZnVsIERIQ1B2
NiBhZGRyZXNzDQogICBhc3NpZ25tZW50IFtSRkMzMzE1XSIgZmluYWwgc2VudGVuY2UgaW4gdGhl
IHBhcmFncmFwaCBzYXlzDQogICAiVGhlIG51bWJlciBvZiBJUHY2IGFkZHJlc3NlcyB0aGF0IGNh
biBiZSBwcm92aWRlZCBpbiBhDQogICBzaW5nbGUgREhDUHY2IHBhY2tldCBpcyBhcHByb3hpbWF0
ZWx5IDMwLiIgYnV0IGl0IGRvZXMNCiAgIG5vdCBzYXkgd2hlcmUgdGhlICIzMCIgY2FtZSBmcm9t
LiBJcyBpdCBiZWNhdXNlIG9mIHBhY2tldA0KICAgc2l6ZSBsaW1pdGF0aW9ucz8gU29tZSBwcm90
b2NvbCBjb25zdGFudD8gU29tZXRoaW5nIGVsc2U/DQogICBTdWdnZXN0IGFkZGluZyBhIHRyYWls
aW5nIHBocmFzZSBnaXZpbmcgc29tZSByYXRpb25hbGUNCiAgIGZvciB0aGUgIjMwIi4NCg0KSW4g
c2VjdGlvbiA4IHRoZSBkcmFmdCBhbHJlYWR5IHNheXMgInRoZSBhcHByb3hpbWF0ZWx5IDMwIGFk
ZHJlc3NlcyB0aGF0IGNhbiBmaXQgaW50byBhIHNpbmdsZSBwYWNrZXQiLiBJJ3ZlIG1vZGlmaWVk
IHRoZSB0ZXh0IHlvdSBwb2ludGVkIHRvIHdpdGggIlRoZSBtYXhpbXVtIG51bWJlciBvZiBJUHY2
IGFkZHJlc3NlcyB0aGF0IGNhbiBiZSBwcm92aWRlZCBpbiBhIHNpbmdsZSBESENQdjYgcGFja2V0
LCBnaXZlbiBhIHR5cGljYWwgTVRVIG9mIDE1MDAgYnl0ZXMgb3Igc21hbGxlciwgaXMgYXBwcm94
aW1hdGVseSAzMC4iLg0KDQpGTFQ+Pj4gR29vZC4NCg0KMTApIFRhYmxlIDEsICJFeHRlbmQgbmV0
d29yayIgaXMgbGlzdGVkIGFzICJZZXMiIGZvciBTTEFBQywNCiAgIHdoaWNoIHdvdWxkIHNlZW0g
dG8gaW1wbHkgdGhhdCBTTEFBQyBpcyBpbnRlbmRlZCB0byBleHRlbmQNCiAgIHRoZSBwcmVmaXgg
dG8gYSBMQU4gbGluayBhcyBpbiBSRkM3Mjc4LiBCdXQsIHRoYXQgY2FuIG9ubHkNCiAgIGJlIHBv
c3NpYmxlIHdoZW4gdGhlIGhvc3QgaGFzIHNvbWUgd2F5IG9mIGtub3dpbmcgdGhhdCB0aGUNCiAg
IHByZWZpeCBoYXMgYmVlbiAiZGVsZWdhdGVkIiB3aGljaCBpcyBvdXRzaWRlIHRoZSBzY29wZSBv
Zg0KICAgUkZDNDg2MS4gQ2FuIGJlIGFkZHJlc3NlZCBieSBhZGRpbmcgYSAiKioiIG5leHQgdG8g
dGhlDQogICBZZXMgd2l0aCB0aGUgZm9vdG5vdGU6DQoNCkkndmUgY2hhbmdlZCB0aGF0IHRvIE5v
Kywgd2l0aCAiWytdIEV4Y2VwdCBvbiBjZXJ0YWluIG5ldHdvcmtzLCBlLmcuLCBbUkZDNzI3OF0u
IiBUaGVyZSBpcyBjdXJyZW50bHkgbm8gc3BlY2lmaWVkIHdheSBmb3IgYSBob3N0IHRvIGRvIHRo
aXMgZXhjZXB0IE5EIHByb3h5aW5nLCB3aGljaCBpcyBleHBlcmltZW50YWwuDQoNCkZMVD4+PiBP
Sy4NCg0KMTEpIFRhYmxlIDEsICIiVW5saW1pdGVkIiBlbmRwb2ludHMgaXMgbGlzdGVkIGFzICJO
byIgZm9yDQogICBESENQdjYgUEQuIFNob3VsZG4ndCBpdCBiZSBhICJZZXMiPw0KDQpOby4gVGhl
IG5ldHdvcmsgY2Fubm90IHByb3ZpZGUgcHJlZml4IGRlbGVnYXRpb25zIHRvIGFuIHVubGltaXRl
ZCBudW1iZXIgb2YgZW5kcG9pbnRzLiBJdCBjYW4gb25seSBwcm92aWRlIHByZWZpeCBkZWxlZ2F0
aW9ucyB0byBhcyBtYW55IGVuZHBvaW50cyBhcyBpdCBoYXMgYXZhaWxhYmxlIC82NHMuIFRoaXMg
aXMgZGlmZmVyZW50IGZyb20gYm90aCBTTEFBQyBhbmQgSUFfTkEsIHdoZXJlLCBhYnNlbnQgc2Nh
bGluZyBsaW1pdGF0aW9ucywgYW4gInVubGltaXRlZCIgbnVtYmVyIG9mIGVuZHBvaW50cyBjYW4g
Zml0IGluIG9uZSAvNjQuIEkndmUgY2hhbmdlZCB0aGUgcm93IG5hbWUgZnJvbSAiVW5saW1pdGVk
IiBlbmRwb2ludHMgdG8gTnVtYmVyICJ1bmxpbWl0ZWQiIGVuZHBvaW50cy4NCg0KRkxUPj4+IEkg
d291bGQgYmUgT0sgd2l0aCB0aGlzLCBidXQgaW4gdGhlIGZvb3Rub3RlIHlvdSBzYXkgdGhhdCBT
TEFBQyBhbmQgSUFfTkEgYXJlDQpGTFQ+Pj4g4oCcU3ViamVjdCB0byBuZXR3b3JrIGxpbWl0YXRp
b25z4oCdLCBhbmQg4oCcdW5saW1pdGVkIGJ1dCBsaW1pdGVk4oCdIGlzIGFuIG94eW1vcm9uLg0K
RkxUPj4+IEJ5IHRoYXQgc2FtZSB0b2tlbiB5b3UgY291bGQgc2F5IHRoYXQgREhDUHY2IFBEIGlz
IOKAnHVubGltaXRlZCBidXQgbGltaXRlZA0KRkxUPj4+IGJ5IHRoZSBudW1iZXIgb2YgYXZhaWxh
YmxlIC82NHPigJ0uIEluIHNvbWUgbmV0d29ya3MgKGUuZy4sIG9uZXMgdGhhdCBoYXZlDQpGTFQ+
Pj4gcHJvY3VyZWQgYSAvMzIgb3Igc2hvcnRlcikgdGhhdCBjb3VsZCByZXN1bHQgaW4gbW9yZSBl
bmRwb2ludCBudW1iZXJpbmdzDQpGTFQ+Pj4gdGhhbiBTTEFBQyBvciBJQV9OQS4NCkZMVD4+Pg0K
RkxUPj4+IE15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIHRoZSDigJxOdW1iZXIg4oCcdW5saW1pdGVk
4oCdIGVuZHBvaW50c+KAnSByZXdvcmQgeW91DQpGTFQ+Pj4gaGF2ZSBzdWdnZXN0ZWQsIGJ1dCBh
bHNvIHBsYWNlIGEg4oCcKirigJ0gbmV4dCB0byB0aGUg4oCcTm8qKuKAnSBmb3IgREhDUHY2IFBE
DQpGTFQ+Pj4gYW5kIGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGFmdGVyIHRoZSB0YWJsZToN
CkZMVD4+Pg0KRkxUPj4+4oCdWyoqXSBTdWJqZWN0IHRvIHRoZSBhdmFpbGFibGUgcHJlZml4IHNw
YWNlLiDigJwNCg0KMTMpIFNlY3Rpb24gOCwgIlRoZSBwcmVmaXggTUFZIGJlIHByb3ZpZGVkIHVz
aW5nIERIQ1B2NiBQRCwNCiAgIFNMQUFDIHdpdGggcGVyLWRldmljZSBWTEFOcywgb3IgYW55IG90
aGVyIG1lYW5zLiIgVHdvIGlzc3VlDQogICB3aXRoIHRoaXMgLSBmaXJzdCwgdGhlIHRleHQgZWFy
bGllciBhbHNvIGluY2x1ZGVkICJ3aXJlbGVzcw0KICAgbmV0d29yayB3aGVyZSBldmVyeSBNQUMg
YWRkcmVzcyBpcyBwbGFjZWQgaW4gaXRzIG93bg0KICAgYnJvYWRjYXN0IGRvbWFpbiIgd2hpY2gg
c2hvdWxkIGFsc28gYmUgcmVpdGVyYXRlZCBoZXJlLg0KDQpJIGRvbid0IHNlZSBhIHJlYXNvbiB0
byByZWl0ZXJhdGUgb25lIG9mIHRoZSBtZWFucyB0byBkbyBzbywgZ2l2ZW4gdGhhdCB0aGlzIHNl
bnRlbmNlIGFscmVhZHkgc2F5cyAib3IgYW55IG90aGVyIG1lYW5zIi4NCg0KRkxUPj4+IE9LLg0K
DQoxNCkgU2VjdGlvbiA5LjEsIHJlbmFtZSBzZWN0aW9uIGFzIHNpbXBseSAiSG9zdCBUcmFja2lu
ZyIsIHNpbmNlDQogICB0aGUgc2VjdGlvbiBjb3ZlcnMgYm90aCBzdGF0ZWZ1bCBhbmQgU0xBQUMu
DQoNCkZhaXIgZW5vdWdoLg0KDQpGTFQ+Pj4gT0suDQoNCjE1KSBTZWN0aW9uIDkuMSwgcGFyYWdy
YXBoIGJlZ2lubmluZyAiTWFueSBsYXJnZSBlbnRlcnByaXNlDQogICBuZXR3b3JrcywgaW5jbHVk
aW5nIHRoZSBlbnRlcnByaXNlIG5ldHdvcmtzIG9mIHRoZSBhdXRob3JzJw0KICAgZW1wbG95ZXJz
IiBzZWVtcyB0byBiZSBhZHZvY2F0aW5nIGZvciBhIHNwZWNpZmljIGFwcHJvYWNoDQogICB3aGls
ZSB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgaXMgYXBwcm9wcmlhdGVseSBuZXV0cmFsLg0KICAg
SU1ITywgdGhpcyBwYXJhZ3JhcGggY291bGQgYmUgcmVtb3ZlZC4NCg0KVGhlIGludGVudCBvZiB0
aGF0IHRleHQgaXMgcHJvdmlkZSBhbiBleGlzdGVuY2UgcHJvb2Ygb2YgbmV0d29ya3MgdGhhdCBk
byBub3QgdXNlIERIQ1B2NiBidXQgc3RpbGwgbWFpbnRhaW4gYSBub3Rpb24gb2Ygd2hpY2ggTUFD
IGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggd2hpY2ggSVB2NiBhZGRyZXNzZXMuIEkndmUgbG9z
dCBjb3VudCBvZiB0aGUgbnVtYmVyIG9mIHRpbWVzIHBlb3BsZSBoYXZlIHRvbGQgbWUgdGhhdCB0
aGlzIGlzIG5vdCBwb3NzaWJsZSBhbmQgdGhhdCBzdGF0ZWZ1bCBESENQdjYgYWRkcmVzcyBhc3Np
Z25tZW50IGlzIHRoZSBvbmx5IHBvc3NpYmxlIHdheSB0byBtZWV0IGxlZ2FsIHJlcXVpcmVtZW50
cy4gSSd2ZSB0cmllZCB0byBzb2Z0ZW4gdGhpcyBieSBwdXR0aW5nIHRoZSBhdXRob3JzJyBuZXR3
b3JrcyBhdCB0aGUgZW5kLg0KDQpGTFQ+Pj4gT0sgdG8gdGhlIGFib3ZlIGNoYW5nZSBhbmQgbGVh
dmUgdGhlIHBhcmFncmFwaCBpbiBwbGFjZSwgYnV0IGFsc28gcGxlYXNlDQpGTFQ+Pj4gZG8gbWUg
dGhlIGZhdm9yIG9mIGNoYW5naW5nIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgc2Vjb25kIHBh
cmFncmFwaCB0bzoNCkZMVD4+Pg0KRkxUPj4+ICDigJxESENQdjYgYWRkcmVzcyBhc3NpZ25tZW50
IGlzIHR5cGljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhpcyByZXF1aXJlbWVudCwNCkZMVD4+PiAg
IGJ1dCBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBpdCBjYW4gYWxzbyBiZSBhZGRyZXNzZWQgdGhy
b3VnaCBvdGhlciBtZWFucy7igJ0NCg0KMTYpIFRoZSBkb2N1bWVudCBjb3VsZCBiZW5lZml0IGZy
b20gYWRkaW5nIGEgc2VjdGlvbiBvbiBtb2JpbGl0eS4NCg0KSSB0aGluayB0aGF0IG1vYmlsaXR5
IGlzIGEgY29tcGxldGVseSBvcnRob2dvbmFsIHByb2JsZW0gdG8gaG93IG1hbnkgYWRkcmVzc2Vz
IGFyZSBwcm92aWRlZCB0byBob3N0cywgYW5kIHRoYXQgaXQncyBvdXQgb2Ygc2NvcGUgaGVyZS4N
Cg0KRkxUPj4+IFRoZW4sIGFkZCBhIDEtMiBzZW50ZW5jZSBTZWN0aW9uIDkuNCB0aGF0IHNheXMg
c28sIGUuZy46DQpGTFQ+Pj4NCkZMVD4+PiAg4oCcOS40LiBNb2JpbGl0eSBDb25zaWRlcmF0aW9u
cw0KRkxUPj4+DQpGTFQ+Pj4gICAgTW9iaWxlIGhvc3RzIGFyZSBiZWNvbWluZyBtb3JlIGFuZCBt
b3JlIHByZXZhbGVudCBpbiBtb2Rlcm4gbmV0d29ya3MsDQpGTFQ+Pj4gICAgYW5kIGhvc3QgbW9i
aWxpdHkgbWF5IGhhdmUgaW50ZXJhY3Rpb25zIHdpdGggSVB2NiBhZGRyZXNzIHByb3Zpc2lvbmlu
Zy4NCkZMVD4+PiAgICBNb2JpbGl0eSBpbXBsaWNhdGlvbnMgYXJlIG91dCBvZiBzY29wZSBmb3Ig
dGhpcyBkb2N1bWVudC7igJ0NCg0KRkxUPj4+IE9uZSBmaW5hbCBxdWVzdGlvbuKAkyBkbyB3ZSBu
ZWVkIGEgc2hvcnQgc2VjdGlvbiBvbiBtYW51YWwgYWRkcmVzcyBjb25maWd1cmF0aW9uDQpGTFQ+
Pj4gaW4gYWRkaXRpb24gdG8gU0xBQUMgYW5kIERIQ1B2Nj8NCg0KQ2hlZXJzLA0KTG9yZW56bw0K
DQoNCg==

--_000_2134F8430051B64F815C691A62D98318339719CEXCHBLV105nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VlIGJlbG93IGZvciBjb21tZW50cyBhbmQg
cmVqb2luZGVycyBvbiB0aGlzIGRvY3VtZW50IGZyb20gYW4gZWFybGllciBkaXNjdXNzaW9uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij50aHJlYWQgb24gdGhlIHY2b3BzIGxpc3QuIFBsZWFzZSB1c2UgdGhpcyB0aHJlYWQgZm9yIGFu
eSBmb2xsb3ctdXAgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIOKAkyBGcmVkPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRpIFtt
YWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg
RmVicnVhcnkgMjQsIDIwMTYgMTI6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQg
TDxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmcgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IFt2Nm9wc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxh
YmlsaXR5LTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMjMsIDIwMTYgYXQgNzozMSBBTSwgVGVt
cGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJz
dCwgdGhlIGRvY3VtZW50IHRocm91Z2hvdXQgdXNlcyBleHByZXNzaW9ucyBvZiB0aGUgZm9ybSAm
cXVvdDtuZXR3b3Jrczxicj4NCnByb3ZpZGUgaG9zdHMgd2l0aCBtdWx0aXBsZSBnbG9iYWwgYWRk
cmVzc2VzJnF1b3Q7IGJ1dCBJTUhPIHRoYXQgaW1wbGllcyZuYnNwOyBhPGJyPg0Kc29ydCBvZiAm
cXVvdDtwdXNoJnF1b3Q7IG9wZXJhdGlvbiB3aGVyZSB0aGUgbmV0d29yayBwdXNoZXMgYWRkcmVz
c2VzIG9udG8gdGhlPGJyPg0KaG9zdCB3aGljaCBpcyBub3QgdGhlIHdheSB0aGluZ3Mgd29yayBp
biBwcmFjdGljZS4gSSB0aGluayBhIG1vcmUgYXBwcm9wcmlhdGU8YnI+DQpleHByZXNzaW9uIGZv
cm0gd291bGQgYmUgJnF1b3Q7bmV0d29ya3MgcHJvdmlkZSBob3N0cyB3aXRoIGEgbWVhbnMgdG8g
b2J0YWluPGJyPg0KbXVsdGlwbGUgZ2xvYmFsIGFkZHJlc3NlcyZxdW90Oy48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlJ3ZlIGFs
cmVhZHkgZ29uZSB0aHJvdWdoIHRoZSBkcmFmdCB0byBjaGFuZ2UgdGhlIHRlcm1pbm9sb2d5IG9u
Y2UgKGZyb20gJnF1b3Q7YXNzaWduIGFkZHJlc3NlcyZxdW90OyB0byB0aGUgY3VycmVudCAmcXVv
dDtwcm92aWRlIGFkZHJlc3NlcyZxdW90OykuIEknbSBub3Qgc3VyZSB0aGF0IGNoYW5naW5nIGl0
IGFnYWluIGZyb20gJnF1b3Q7cHJvdmlkZSBhZGRyZXNzZXMmcXVvdDsgdG8gJnF1b3Q7cHJvdmlk
ZSBhIG1lYW5zIHRvIG9idGFpbiBhZGRyZXNzZXMmcXVvdDsgcHJvdmlkZXMNCiBtdWNoIHZhbHVl
LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyBDZXJ0YWlubHkg4oCccHJvdmlkZeKAnSBpcyBtdWNo
IGJldHRlciB0aGFuIOKAnGFzc2lnbuKAnSwgYnV0IGl0IGlzIHVwIHRvIHRoZSBob3N0IHRvPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5GTFQmZ3Q7Jmd0OyZndDsgb2J0YWluIChhbmQgZGVmZW5kKSBpdHMgb3duIGFkZHJlc3NlcyB3
aGV0aGVyIGl0IGJlIHRocm91Z2ggU0xBQUMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgREhDUHY2LCBt
YW51YWwgY29uZmlnLCBvciB3aGF0ZXZlci4gU28sIHRoZSBuZXR3b3JrIHByb3ZpZGVzIHRoZTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+RkxUJmd0OyZndDsmZ3Q7IG1lYW5zIHRvIG9idGFpbiBhZGRyZXNzZXMgd2hpbGUgdGhlIGhv
c3QgbXVzdCBhY3Qgb24gaXRzIG93biBiZWhhbGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyB0byBvYnRh
aW4gYWRkcmVzc2VzIChhY3F1aXJlIG1pZ2h0IGV2ZW4gYmUgYSBiZXR0ZXIgd29yZCB0aGFuIG9i
dGFpbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UbyBtZSwgJnF1b3Q7cHJvdmlkZSZxdW90OyBkb2VzIG5vdCBhIGltcGx5IHB1
c2ggb3BlcmF0aW9uLiBUaGUgbmV0d29yayBjYW4gYWxzbyBwcm92aWRlIGFkZHJlc3NlcyAvIHBy
ZWZpeGVzIG9uIHJlcXVlc3QgKGUuZy4sIGlmIHRoZSBob3N0IHNlbmRzIGFuIFJTIG9yIGEgREhD
UHY2IHNvbGljaXQuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7IEkgdGhp
bmsgd2Ugc2VlIHRoaXMgaW4gZGlmZmVyZW50IHdheXMsIGJ1dCBJIHVuZGVyc3RhbmQgdGhlIGRl
c2lyZSB0byBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyBvdmVyaGF1bCB0aGUgZG9jdW1lbnQuIEFz
IGEgY29tcHJvbWlzZSwgSSB0aGluayB0aGlzIGNvdWxkIGVhc2lseSBiZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZn
dDsmZ3Q7IGFkZHJlc3NlZCBieSBzaW1wbHkgY2hhbmdpbmcgdGhlIGFic3RyYWN0IHRvIHJlYWQ6
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5GTFQmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyDigJxUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgdGhhdCBuZXR3b3JrcyBwcm92aWRl
IGdlbmVyYWwtcHVycG9zZSBlbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDtob3N0cyB3aXRoIGEgbWVhbnMgdG8gYWNxdWlyZSBtdWx0aXBs
ZSBnbG9iYWwgSVB2NiBhZGRyZXNzZXMgd2hlbiB0aGV5PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsmbmJz
cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7YXR0YWNoLCBhbmQgZGVzY3JpYmVzIHRo
ZSBiZW5lZml0cyBvZiBhbmQgdGhlIG9wdGlvbnMgZm9yIGRvaW5nIHNvLuKAnTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0
OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgVGhlbiwgbWFrZSBubyBvdGhlciBjaGFuZ2Vz
IGluIHRoZSBkb2N1bWVudCwgYW5kIHJlYWRlcnMgd2lsbCBzdGlsbDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsm
Z3Q7IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWNv
bmQsIHRoZSBkb2N1bWVudCBzZWVtcyB0byBpbXBseSBpbiBzZXZlcmFsIHBsYWNlcyB0aGF0IFNM
QUFDIGNhbjxicj4NCmJlIHVzZWQgYXMgYSBzb3J0IG9mIGltcGxpY2l0IHByZWZpeCBkZWxlZ2F0
aW9uIHNlcnZpY2U7IHByZXN1bWFibHkgaW4gdGhlPGJyPg0Kc2FtZSBzcGlyaXQgYXMgUkZDNzI3
OC4gSWYgdGhhdCBpcyB0aGUgaW50ZW50aW9uLCB0aGVuIGl0IGFsc28gbmVlZHMgdG8gc2F5PGJy
Pg0KdGhhdCB0aGUgaG9zdCBuZWVkcyB0byBoYXZlIHNvbWUgd2F5IG9mIGtub3dpbmcgb3V0c2lk
ZSBvZiB0aGUgc2NvcGU8YnI+DQpvZiB0aGUgbm9kZSByZXF1aXJlbWVudCBzdGFuZGFyZHMgdGhh
dCB0aGUgcHJlZml4IGlzIGJlaW5nIGRlbGVnYXRlZDxicj4NCmZvciB0aGUgaG9zdCdzIGV4Y2x1
c2l2ZSB1c2UuIEZvciBleGFtcGxlLCBhbiB1bm1vZGlmaWVkIGhvc3QgdGhhdCBvYmV5czxicj4N
ClJGQzQ4NjEgb24gYSBXaUZpIGxpbmsgd291bGQgaGF2ZSBubyB3YXkgb2Yga25vd2luZyB0aGF0
IGEgcHJlZml4PGJyPg0KYWR2ZXJ0aXNlZCBpbiBhIFBJTyB3aXRoIChBPTE7IEw9MCkgaXMgaW4g
ZmFjdCBiZWluZyBkZWxlZ2F0ZWQgZm9yIGl0cyBvd248YnI+DQpleGNsdXNpdmUgdXNlLiBUaGUg
ZG9jdW1lbnQgdGhlcmVmb3JlIG5lZWRzIHRvIG5vdGUgdGhpcyByYXRoZXIgdGhhbjxicj4NCmlt
cGx5IHRoYXQgYW4gdW5tb2RpZmllZCBob3N0IGNhbiB1c2UgU0xBQUMgZm9yIHByZWZpeCBkZWxl
Z2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SXQgaXMgbm90IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRyYWZ0IHRvIGltcGx5
IHRoaXMuIEluIGZhY3QsIGl0IGV4cGxpY2l0bHkgc2F5cyB0aGUgb3Bwb3NpdGU6ICZxdW90O0lm
IHRoZSBob3N0IGlzIGF3YXJlIHRoYXQgdGhlIHByZWZpeCBpcyBkZWRpY2F0ZWQgKGUuZy4sIGlm
IGl0IHdhcyBwcm92aWRlZCB2aWEgREhDUHY2IFBEIGFuZCBub3QgU0xBQUMpLi4uJnF1b3Q7IEtu
b3dpbmcgdGhhdCBhIHByZWZpeCBpbiB0aGUgUkENCiBpcyBkZWRpY2F0ZWQgb3Igbm90IHdvdWxk
IHJlcXVpcmUgcHJvdG9jb2wgY2hhbmdlcy4gV2UgY291bGQgY29uc2lkZXIgdGhvc2UgaW4gdGhl
IGZ1dHVyZSwgYnV0IG5vdCBpbiB2Nm9wcywgYmVjYXVzZSBwcm90b2NvbCBjaGFuZ2VzIGFyZSBu
b3Qgc29tZXRoaW5nIHRoYXQgaXMgaW4gdGhlIHJlbWl0IG9mIHRoaXMgV0cuPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxU
Jmd0OyZndDsmZ3Q7IEkgd291bGQgcHJlZmVyIHRvIHNlZSB0aGUgU2VjdGlvbiA5LjMgc2VudGVu
Y2UgeW91IGNpdGVkIGFwcGVhciBlYXJsaWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgaW4gdGhlIGRv
Y3VtZW50LCBidXQgSSBkb27igJl0IHNlZSB0aGUgcG9pbnQgaW4gYXJndWluZyBvdmVyIGl0LiBP
SyB0byBsZWF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7IGl0IGFzIGl0IGlzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZvbGxv
d2luZyBhZGRyZXNzZXMgc29tZSBvZiB5b3VyIGlubGluZSBwb2ludHMuIEkgdGhpbmsgdGhlIG90
aGVycyBhcmUgZWl0aGVyIG1pbm9yIGVkaXRvcmlhbCBpc3N1ZXMgd2l0aCBubyBzdWJzdGFudGl2
ZSBpbXBsaWNhdGlvbnMgb3IgYXJlIGFscmVhZHkgY292ZXJlZCBieSB0aGUgdHdvIG1haW4gcG9p
bnRzIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj44KSBTZWN0aW9uIDYsIHVuZGVyIHRoZSBoZWFkaW5nICZxdW90O1VzaW5n
IFN0YXRlbGVzcyBBZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0F1dG9jb25maWd1cmF0aW9u
IFtSRkM0ODYyXS4mcXVvdDsgVGhpcyBzZWN0aW9uIGRvZXMgbm90IG1ha2U8YnI+DQombmJzcDsg
Jm5ic3A7YSBzdGF0ZW1lbnQgYXMgdG8gd2hldGhlciB0aGUgJnF1b3Q7ZGVkaWNhdGVkIC82NCBw
cmVmaXgmcXVvdDsgaXM8YnI+DQombmJzcDsgJm5ic3A7dG8gYmUgdXNlZCBvbmx5IGZvciBTTEFB
QyBvbiB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3ByZWZp
eCBpcyBhZHZlcnRpc2VkLCBvciB3aGV0aGVyIHRoZSBwcmVmaXggY2FuIGJlPGJyPg0KJm5ic3A7
ICZuYnNwO2V4dGVuZGVkIHRvIGEgTEFOIGxpbmsgYXMgaW4gUkZDNzI3OC48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qg
dGhpbmsgdGhlIGRyYWZ0IG5lZWRzIHRvIHNheSB0aGlzLiBSRkM0ODYyIGRvZXMgbm90IGNvbnRh
aW4gYW55dGhpbmcgYWJvdXQgZXh0ZW5kaW5nIHRoZSBwcmVmaXggdG8gb3RoZXIgaG9zdHMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxl
IHRoZSBkcmFmdCBkb2VzIGNpdGUgUkZDNzI3OCBlbHNld2hlcmUsIFJGQzcyNzggaXMgc3BlY2lm
aWMgdG8gb25seSBvbmUgdHlwZSBvZiBsaW5rIGxheWVyICgzR1BQIGxpbmtzKS4gU28gSSB0aGlu
ayB0aGUgdGV4dCBpcyB1bmFtYmlndW91czogaWYgeW91J3JlIG9uIGEgM0dQUCBuZXR3b3JrLCB5
b3UgY2FuIHVzZSBSRkM3Mjc4LCBhbmQgaWYgbm90LCBhbnkgYWJpbGl0eSB0byBleHRlbmQgdGhl
IHByZWZpeA0KIGlzIHVuc3BlY2lmaWVkLiBUaGVyZSdzIE5EIHByb3h5aW5nLCBidXQgaXQncyBl
eHBlcmltZW50YWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFsc28gc2VlIG15IHByaW9yIHBvaW50IGFib3V0IHByb3RvY29sIGNoYW5nZXMu
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7IE9LLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OSkgU2VjdGluIDYsIHVuZGVy
IHRoZSBoZWFkaW5nICZxdW90O1VzaW5nIFN0YXRlZnVsIERIQ1B2NiBhZGRyZXNzPGJyPg0KJm5i
c3A7ICZuYnNwO2Fzc2lnbm1lbnQgW1JGQzMzMTVdJnF1b3Q7IGZpbmFsIHNlbnRlbmNlIGluIHRo
ZSBwYXJhZ3JhcGggc2F5czxicj4NCiZuYnNwOyAmbmJzcDsmcXVvdDtUaGUgbnVtYmVyIG9mIElQ
djYgYWRkcmVzc2VzIHRoYXQgY2FuIGJlIHByb3ZpZGVkIGluIGE8YnI+DQombmJzcDsgJm5ic3A7
c2luZ2xlIERIQ1B2NiBwYWNrZXQgaXMgYXBwcm94aW1hdGVseSAzMC4mcXVvdDsgYnV0IGl0IGRv
ZXM8YnI+DQombmJzcDsgJm5ic3A7bm90IHNheSB3aGVyZSB0aGUgJnF1b3Q7MzAmcXVvdDsgY2Ft
ZSBmcm9tLiBJcyBpdCBiZWNhdXNlIG9mIHBhY2tldDxicj4NCiZuYnNwOyAmbmJzcDtzaXplIGxp
bWl0YXRpb25zPyBTb21lIHByb3RvY29sIGNvbnN0YW50PyBTb21ldGhpbmcgZWxzZT88YnI+DQom
bmJzcDsgJm5ic3A7U3VnZ2VzdCBhZGRpbmcgYSB0cmFpbGluZyBwaHJhc2UgZ2l2aW5nIHNvbWUg
cmF0aW9uYWxlPGJyPg0KJm5ic3A7ICZuYnNwO2ZvciB0aGUgJnF1b3Q7MzAmcXVvdDsuPG86cD48
L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
biBzZWN0aW9uIDggdGhlIGRyYWZ0IGFscmVhZHkgc2F5cyAmcXVvdDt0aGUgYXBwcm94aW1hdGVs
eSAzMCBhZGRyZXNzZXMgdGhhdCBjYW4gZml0IGludG8gYSBzaW5nbGUgcGFja2V0JnF1b3Q7LiBJ
J3ZlIG1vZGlmaWVkIHRoZSB0ZXh0IHlvdSBwb2ludGVkIHRvIHdpdGggJnF1b3Q7VGhlIG1heGlt
dW0gbnVtYmVyIG9mIElQdjYgYWRkcmVzc2VzIHRoYXQgY2FuIGJlIHByb3ZpZGVkIGluIGEgc2lu
Z2xlIERIQ1B2NiBwYWNrZXQsIGdpdmVuDQogYSB0eXBpY2FsIE1UVSBvZiAxNTAwIGJ5dGVzIG9y
IHNtYWxsZXIsIGlzIGFwcHJveGltYXRlbHkgMzAuJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7
Jmd0OyBHb29kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+MTApIFRhYmxlIDEsICZxdW90O0V4dGVuZCBuZXR3b3JrJnF1
b3Q7IGlzIGxpc3RlZCBhcyAmcXVvdDtZZXMmcXVvdDsgZm9yIFNMQUFDLDxicj4NCiZuYnNwOyAm
bmJzcDt3aGljaCB3b3VsZCBzZWVtIHRvIGltcGx5IHRoYXQgU0xBQUMgaXMgaW50ZW5kZWQgdG8g
ZXh0ZW5kPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBwcmVmaXggdG8gYSBMQU4gbGluayBhcyBpbiBS
RkM3Mjc4LiBCdXQsIHRoYXQgY2FuIG9ubHk8YnI+DQombmJzcDsgJm5ic3A7YmUgcG9zc2libGUg
d2hlbiB0aGUgaG9zdCBoYXMgc29tZSB3YXkgb2Yga25vd2luZyB0aGF0IHRoZTxicj4NCiZuYnNw
OyAmbmJzcDtwcmVmaXggaGFzIGJlZW4gJnF1b3Q7ZGVsZWdhdGVkJnF1b3Q7IHdoaWNoIGlzIG91
dHNpZGUgdGhlIHNjb3BlIG9mPGJyPg0KJm5ic3A7ICZuYnNwO1JGQzQ4NjEuIENhbiBiZSBhZGRy
ZXNzZWQgYnkgYWRkaW5nIGEgJnF1b3Q7KiomcXVvdDsgbmV4dCB0byB0aGU8YnI+DQombmJzcDsg
Jm5ic3A7WWVzIHdpdGggdGhlIGZvb3Rub3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBjaGFuZ2VkIHRoYXQgdG8gTm8m
IzQzOywgd2l0aCAmcXVvdDtbJiM0MztdIEV4Y2VwdCBvbiBjZXJ0YWluIG5ldHdvcmtzLCBlLmcu
LCBbUkZDNzI3OF0uJnF1b3Q7IFRoZXJlIGlzIGN1cnJlbnRseSBubyBzcGVjaWZpZWQgd2F5IGZv
ciBhIGhvc3QgdG8gZG8gdGhpcyBleGNlcHQgTkQgcHJveHlpbmcsIHdoaWNoIGlzIGV4cGVyaW1l
bnRhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgT0suPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMSkgVGFibGUgMSwg
JnF1b3Q7JnF1b3Q7VW5saW1pdGVkJnF1b3Q7IGVuZHBvaW50cyBpcyBsaXN0ZWQgYXMgJnF1b3Q7
Tm8mcXVvdDsgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO0RIQ1B2NiBQRC4gU2hvdWxkbid0IGl0IGJl
IGEgJnF1b3Q7WWVzJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8uIFRoZSBuZXR3b3JrIGNhbm5vdCBwcm92aWRlIHBy
ZWZpeCBkZWxlZ2F0aW9ucyB0byBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIGVuZHBvaW50cy4gSXQg
Y2FuIG9ubHkgcHJvdmlkZSBwcmVmaXggZGVsZWdhdGlvbnMgdG8gYXMgbWFueSBlbmRwb2ludHMg
YXMgaXQgaGFzIGF2YWlsYWJsZSAvNjRzLiBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIGJvdGggU0xB
QUMgYW5kIElBX05BLCB3aGVyZSwgYWJzZW50IHNjYWxpbmcNCiBsaW1pdGF0aW9ucywgYW4gJnF1
b3Q7dW5saW1pdGVkJnF1b3Q7IG51bWJlciBvZiBlbmRwb2ludHMgY2FuIGZpdCBpbiBvbmUgLzY0
LiBJJ3ZlIGNoYW5nZWQgdGhlIHJvdyBuYW1lIGZyb20gJnF1b3Q7VW5saW1pdGVkJnF1b3Q7IGVu
ZHBvaW50cyB0byBOdW1iZXIgJnF1b3Q7dW5saW1pdGVkJnF1b3Q7IGVuZHBvaW50cy48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5GTFQmZ3Q7Jmd0OyZndDsgSSB3b3VsZCBiZSBPSyB3aXRoIHRoaXMsIGJ1dCBpbiB0aGUgZm9v
dG5vdGUgeW91IHNheSB0aGF0IFNMQUFDIGFuZCBJQV9OQSBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0
OyDigJxTdWJqZWN0IHRvIG5ldHdvcmsgbGltaXRhdGlvbnPigJ0sIGFuZCDigJx1bmxpbWl0ZWQg
YnV0IGxpbWl0ZWTigJ0gaXMgYW4gb3h5bW9yb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgQnkgdGhh
dCBzYW1lIHRva2VuIHlvdSBjb3VsZCBzYXkgdGhhdCBESENQdjYgUEQgaXMg4oCcdW5saW1pdGVk
IGJ1dCBsaW1pdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgYnkgdGhlIG51bWJlciBvZiBhdmFpbGFi
bGUgLzY0c+KAnS4gSW4gc29tZSBuZXR3b3JrcyAoZS5nLiwgb25lcyB0aGF0IGhhdmU8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZM
VCZndDsmZ3Q7Jmd0OyBwcm9jdXJlZCBhIC8zMiBvciBzaG9ydGVyKSB0aGF0IGNvdWxkIHJlc3Vs
dCBpbiBtb3JlIGVuZHBvaW50IG51bWJlcmluZ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyB0aGFuIFNM
QUFDIG9yIElBX05BLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgTXkg
c3VnZ2VzdGlvbiBpcyB0byB1c2UgdGhlIOKAnE51bWJlciDigJx1bmxpbWl0ZWTigJ0gZW5kcG9p
bnRz4oCdIHJld29yZCB5b3U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyBoYXZlIHN1Z2dlc3RlZCwgYnV0
IGFsc28gcGxhY2UgYSDigJwqKuKAnSBuZXh0IHRvIHRoZSDigJxObyoq4oCdIGZvciBESENQdjYg
UEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyBhbmQgYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgYWZ0
ZXIgdGhlIHRhYmxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDvigJ1b
KipdIFN1YmplY3QgdG8gdGhlIGF2YWlsYWJsZSBwcmVmaXggc3BhY2UuIOKAnDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
MTMpIFNlY3Rpb24gOCwgJnF1b3Q7VGhlIHByZWZpeCBNQVkgYmUgcHJvdmlkZWQgdXNpbmcgREhD
UHY2IFBELDxicj4NCiZuYnNwOyAmbmJzcDtTTEFBQyB3aXRoIHBlci1kZXZpY2UgVkxBTnMsIG9y
IGFueSBvdGhlciBtZWFucy4mcXVvdDsgVHdvIGlzc3VlPGJyPg0KJm5ic3A7ICZuYnNwO3dpdGgg
dGhpcyAtIGZpcnN0LCB0aGUgdGV4dCBlYXJsaWVyIGFsc28gaW5jbHVkZWQgJnF1b3Q7d2lyZWxl
c3M8YnI+DQombmJzcDsgJm5ic3A7bmV0d29yayB3aGVyZSBldmVyeSBNQUMgYWRkcmVzcyBpcyBw
bGFjZWQgaW4gaXRzIG93bjxicj4NCiZuYnNwOyAmbmJzcDticm9hZGNhc3QgZG9tYWluJnF1b3Q7
IHdoaWNoIHNob3VsZCBhbHNvIGJlIHJlaXRlcmF0ZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qgc2VlIGEg
cmVhc29uIHRvIHJlaXRlcmF0ZSBvbmUgb2YgdGhlIG1lYW5zIHRvIGRvIHNvLCBnaXZlbiB0aGF0
IHRoaXMgc2VudGVuY2UgYWxyZWFkeSBzYXlzICZxdW90O29yIGFueSBvdGhlciBtZWFucyZxdW90
Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgT0suPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xNCkgU2VjdGlvbiA5LjEs
IHJlbmFtZSBzZWN0aW9uIGFzIHNpbXBseSAmcXVvdDtIb3N0IFRyYWNraW5nJnF1b3Q7LCBzaW5j
ZTxicj4NCiZuYnNwOyAmbmJzcDt0aGUgc2VjdGlvbiBjb3ZlcnMgYm90aCBzdGF0ZWZ1bCBhbmQg
U0xBQUMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5GYWlyIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgT0suPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4xNSkgU2VjdGlvbiA5LjEsIHBhcmFncmFwaCBiZWdpbm5pbmcgJnF1b3Q7TWFueSBsYXJn
ZSBlbnRlcnByaXNlPGJyPg0KJm5ic3A7ICZuYnNwO25ldHdvcmtzLCBpbmNsdWRpbmcgdGhlIGVu
dGVycHJpc2UgbmV0d29ya3Mgb2YgdGhlIGF1dGhvcnMnPGJyPg0KJm5ic3A7ICZuYnNwO2VtcGxv
eWVycyZxdW90OyBzZWVtcyB0byBiZSBhZHZvY2F0aW5nIGZvciBhIHNwZWNpZmljIGFwcHJvYWNo
PGJyPg0KJm5ic3A7ICZuYnNwO3doaWxlIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCBpcyBhcHBy
b3ByaWF0ZWx5IG5ldXRyYWwuPGJyPg0KJm5ic3A7ICZuYnNwO0lNSE8sIHRoaXMgcGFyYWdyYXBo
IGNvdWxkIGJlIHJlbW92ZWQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZW50IG9mIHRoYXQgdGV4dCBpcyBwcm92aWRl
IGFuIGV4aXN0ZW5jZSBwcm9vZiBvZiBuZXR3b3JrcyB0aGF0IGRvIG5vdCB1c2UgREhDUHY2IGJ1
dCBzdGlsbCBtYWludGFpbiBhIG5vdGlvbiBvZiB3aGljaCBNQUMgYWRkcmVzc2VzIGFzc29jaWF0
ZWQgd2l0aCB3aGljaCBJUHY2IGFkZHJlc3Nlcy4gSSd2ZSBsb3N0IGNvdW50IG9mIHRoZSBudW1i
ZXIgb2YgdGltZXMgcGVvcGxlIGhhdmUgdG9sZCBtZQ0KIHRoYXQgdGhpcyBpcyBub3QgcG9zc2li
bGUgYW5kIHRoYXQgc3RhdGVmdWwgREhDUHY2IGFkZHJlc3MgYXNzaWdubWVudCBpcyB0aGUgb25s
eSZuYnNwO3Bvc3NpYmxlJm5ic3A7d2F5IHRvIG1lZXQgbGVnYWwgcmVxdWlyZW1lbnRzLiBJJ3Zl
IHRyaWVkIHRvIHNvZnRlbiB0aGlzIGJ5IHB1dHRpbmcgdGhlIGF1dGhvcnMnIG5ldHdvcmtzIGF0
IHRoZSBlbmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7IE9LIHRvIHRoZSBhYm92ZSBjaGFuZ2Ug
YW5kIGxlYXZlIHRoZSBwYXJhZ3JhcGggaW4gcGxhY2UsIGJ1dCBhbHNvIHBsZWFzZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxU
Jmd0OyZndDsmZ3Q7IGRvIG1lIHRoZSBmYXZvciBvZiBjaGFuZ2luZyB0aGUgZmlyc3Qgc2VudGVu
Y2Ugb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggdG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZM
VCZndDsmZ3Q7Jmd0OyZuYnNwOyDigJxESENQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGlzIHR5cGlj
YWxseSBhc3NvY2lhdGVkIHdpdGggdGhpcyByZXF1aXJlbWVudCw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0
OyZuYnNwOyZuYnNwOyBidXQgaXQgaXMgd29ydGggbm90aW5nIHRoYXQgaXQgY2FuIGFsc28gYmUg
YWRkcmVzc2VkIHRocm91Z2ggb3RoZXIgbWVhbnMu4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjE2KSBUaGUgZG9j
dW1lbnQgY291bGQgYmVuZWZpdCBmcm9tIGFkZGluZyBhIHNlY3Rpb24gb24gbW9iaWxpdHkuPG86
cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5JIHRoaW5rIHRoYXQgbW9iaWxpdHkgaXMgYSBjb21wbGV0ZWx5IG9ydGhvZ29uYWwgcHJvYmxl
bSB0byBob3cgbWFueSBhZGRyZXNzZXMgYXJlIHByb3ZpZGVkIHRvIGhvc3RzLCBhbmQgdGhhdCBp
dCdzIG91dCBvZiBzY29wZSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyBUaGVuLCBhZGQg
YSAxLTIgc2VudGVuY2UgU2VjdGlvbiA5LjQgdGhhdCBzYXlzIHNvLCBlLmcuOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0
OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsmbmJzcDsg4oCcOS40LiBNb2JpbGl0eSBDb25z
aWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsmbmJzcDsm
bmJzcDsmbmJzcDsgTW9iaWxlIGhvc3RzIGFyZSBiZWNvbWluZyBtb3JlIGFuZCBtb3JlIHByZXZh
bGVudCBpbiBtb2Rlcm4gbmV0d29ya3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm
bmJzcDsgYW5kIGhvc3QgbW9iaWxpdHkgbWF5IGhhdmUgaW50ZXJhY3Rpb25zIHdpdGggSVB2NiBh
ZGRyZXNzIHByb3Zpc2lvbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZMVCZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyBNb2JpbGl0eSBpbXBsaWNhdGlvbnMgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVu
dC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RkxUJmd0OyZndDsmZ3Q7IE9uZSBmaW5hbCBxdWVzdGlvbuKA
kyBkbyB3ZSBuZWVkIGEgc2hvcnQgc2VjdGlvbiBvbiBtYW51YWwgYWRkcmVzcyBjb25maWd1cmF0
aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5GTFQmZ3Q7Jmd0OyZndDsgaW4gYWRkaXRpb24gdG8gU0xBQUMgYW5kIERIQ1B2Nj88
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkxvcmVuem88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_2134F8430051B64F815C691A62D98318339719CEXCHBLV105nwnosb_--



From nobody Wed Feb 24 16:51:09 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1158D1A899F for ; Wed, 24 Feb 2016 16:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.607
X-Spam-Level: 
X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAtLwdYchwZ4 for ; Wed, 24 Feb 2016 16:51:06 -0800 (PST)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (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 3B9651A0318 for ; Wed, 24 Feb 2016 16:51:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u1P0p3uu001873; Wed, 24 Feb 2016 18:51:03 -0600
Received: from XCH-BLV-302.nw.nos.boeing.com (xch-blv-302.nw.nos.boeing.com [130.247.25.214]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1P0owgA001720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 24 Feb 2016 18:50:59 -0600
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.50]) with mapi id 14.03.0235.001; Wed, 24 Feb 2016 16:51:00 -0800
From: "Templin, Fred L" 
To: "Rajiv Asati (rajiva)" , "Bernie Volz (volz)" 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbNo04muWj7mmQkeNAnAx3wsjGZ87LGGAgAAh1wCAAKA7gP//+ha5gAAJ2jA=
Date: Thu, 25 Feb 2016 00:50:59 +0000
Message-ID: <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>,  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com>
In-Reply-To: <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 00:51:08 -0000

On some links, invoking DHCPv6 immediately without waiting for an RA is
natural and provides all the configuration information needed by the client=
.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Rajiv Asati (raj=
iva)
> Sent: Wednesday, February 24, 2016 4:12 PM
> To: Bernie Volz (volz)
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
>=20
> I agree that starting DHCPv6 without an RA is pointless / useless. And th=
e draft should just state that.
>=20
> But if the draft is referring to any existing RFC, then it is reasonable =
to say the behavior not being specified (or unclear). Just avoid hair-
> splitting.
>=20
> Cheers,
> Rajiv Asati
> Distinguished Engineer, Cisco Services
>=20
>=20
> > On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz)  wrote:
> >
> > CPE are both hosts and routers. Their specification is defined in RFC 7=
084.
> >
> > With respect to the host (address assignment) side:
> >
> >   WAA-6:   If the IPv6 CE router receives a Router Advertisement
> >            message (described in [RFC4861]) with the M flag set to 1,
> >            the IPv6 CE router MUST do DHCPv6 address assignment
> >            (request an IA_NA option).
> >
> > With respect to the router (prefix delegation) side:
> >
> >   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
> >           delegation when either the M or O flags are set to 1 in a
> >           received Router Advertisement (RA) message.  Behavior of the
> >           CE router to use DHCPv6 prefix delegation when the CE router
> >           has not received any RA or received an RA with the M and the
> >           O bits set to zero is out of scope for this document.
> >
> > Though for the PD case, it doesn't say what to do if there is no RA (ou=
t of scope!).
> >
> > So, for the CPE (with respect to the host side, which is what draft-iet=
f-v6ops-dhcpv6-slaac-problem is about), it agrees with
> Lorenzo's analysis.
> >
> > - Bernie
> >
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of sthaug@nethelp=
.no
> > Sent: Wednesday, February 24, 2016 4:00 AM
> > To: lorenzo@google.com
> > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> >
> >> 1. I disagree with the statement "It is unclear whether hosts should
> >> initiate DHCPv6 by themselves if there are no RAs at all." There is
> >> not really point in using DHCPv6 without RAs. This is because DHCPv6
> >> does not configure prefixes, only addresses without prefix lengths,
> >> and therefore an address assigned by DHCPv6 either has no prefix
> >> length or a prefix length of /128. See dhcpv6bs ticket 68:
> >> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
> >>
> >> So starting DHCPv6 without an RA is pointless because even if you get
> >> an address, you can't use to talk to anything. Thus, I don't think
> >> there is any ambiguity here, since one of the alternatives doesn't
> >> make sense. That said, if we do still want to say this is ambiguous,
> >> then we should replace "ambiguous" with "unspecified", and add
> >> something about the fact that
> >> DHCPv6 without RAs is useless, such as:
> >
> > I can absolutely see this point of view. On the other hand - given that=
 the M-bit is only a hint: If I were a CPE manufacturer, I might
> find it perfectly rational to *always* start DHCPv6 (for simplicity's sak=
e). I believe we've seen more than one CPE model doing exactly
> that.
> >
> > Steinar Haug, AS2116
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



From nobody Wed Feb 24 17:13:48 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0051AD305 for ; Wed, 24 Feb 2016 17:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.784
X-Spam-Level: 
X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYgmDFbSEGyO for ; Wed, 24 Feb 2016 17:13:45 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 F14811AD0C4 for ; Wed, 24 Feb 2016 17:13:44 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id u200so31018604ywf.0 for ; Wed, 24 Feb 2016 17:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sI+BNGYprwcOZKX3O8e+ymuayl1VjYNuvFu1ZpF7FBU=; b=j44Qaotbv3G1cey3m0bUjbMjU3ASlPRjvfqul3TVLgaraVtnuRa6BXOAAv8W6NBvny sBQ1oo3GuIYLZKUMyCKa/m5GxIC8lIVgLt3TyzJaeEice/v8Dhe42k49LS9gQma/rl/5 E+TZbo96PcZtn8vgVd+RnHvKQquupWjLyd1Kldbs60ipuf4OFJGLLoyYJuMHHOsY2+t1 jL0eitAE9fIHQ7804jX/lI+M3QxOvSzQH+H6p8qTQRv2LtbvY/fXmSSwwiJZ0vgmalze 6KkPBoQuq1uQuNyc9svN1gcF4IbCxE8ePFzdBelKp422S4xsRF00Q3/hdMTPVgPFAsHb bdzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sI+BNGYprwcOZKX3O8e+ymuayl1VjYNuvFu1ZpF7FBU=; b=KjaB22I7JWb81ErBY3OnRBLgj+jrSOVe3FmadXEKrCcyTuKq7XPTLlXdtMB+mxNkBM LviY8wl/kOF+OsfEP9/GgZ9eo/S77zfm8loWo4ng+pzWngfmhWNuU92d7EcQlpq53AyN g1G4qV1sxKClSl9Jg3TnIk49r6ujEYxzieJ91LmgGH5DpoNCKgGKlSAVd2+6Ul3upWiI qZHIu2xG0PnzaGcsyMqIQOX+TREQJXPZaapM3s8XNmX58YDJVMWGmSaHyed+fnmH3T6n q1w5QtD25hibEvajo3Q20ia8a9H7m8gVf7W0DO5GifbhOBZh788CusMX2beO8JRWFZms 3dRg==
X-Gm-Message-State: AG10YOR9fyLkfZR7yfbcIVrH4Xb7Nhet8kRfacGU9nKbbpGxbIFquVQohlP3JTIIqFheDtJIsr5i9cFFRxDrc0tv
X-Received: by 10.13.238.194 with SMTP id x185mr23885482ywe.35.1456362824176;  Wed, 24 Feb 2016 17:13:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Wed, 24 Feb 2016 17:13:24 -0800 (PST)
In-Reply-To: <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com> <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com>
From: Lorenzo Colitti 
Date: Thu, 25 Feb 2016 10:13:24 +0900
Message-ID: 
To: "Templin, Fred L" 
Content-Type: multipart/alternative; boundary=94eb2c031094cd209e052c8de48d
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 01:13:47 -0000

--94eb2c031094cd209e052c8de48d
Content-Type: text/plain; charset=UTF-8

Which links? Even on point-to-point links such as PPP interfaces or 3GPP
networks, routing requires an RA.

On Thu, Feb 25, 2016 at 9:50 AM, Templin, Fred L 
wrote:

> On some links, invoking DHCPv6 immediately without waiting for an RA is
> natural and provides all the configuration information needed by the
> client.
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Rajiv Asati
> (rajiva)
> > Sent: Wednesday, February 24, 2016 4:12 PM
> > To: Bernie Volz (volz)
> > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> >
> > I agree that starting DHCPv6 without an RA is pointless / useless. And
> the draft should just state that.
> >
> > But if the draft is referring to any existing RFC, then it is reasonable
> to say the behavior not being specified (or unclear). Just avoid hair-
> > splitting.
> >
> > Cheers,
> > Rajiv Asati
> > Distinguished Engineer, Cisco Services
> >
> >
> > > On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz) 
> wrote:
> > >
> > > CPE are both hosts and routers. Their specification is defined in RFC
> 7084.
> > >
> > > With respect to the host (address assignment) side:
> > >
> > >   WAA-6:   If the IPv6 CE router receives a Router Advertisement
> > >            message (described in [RFC4861]) with the M flag set to 1,
> > >            the IPv6 CE router MUST do DHCPv6 address assignment
> > >            (request an IA_NA option).
> > >
> > > With respect to the router (prefix delegation) side:
> > >
> > >   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
> > >           delegation when either the M or O flags are set to 1 in a
> > >           received Router Advertisement (RA) message.  Behavior of the
> > >           CE router to use DHCPv6 prefix delegation when the CE router
> > >           has not received any RA or received an RA with the M and the
> > >           O bits set to zero is out of scope for this document.
> > >
> > > Though for the PD case, it doesn't say what to do if there is no RA
> (out of scope!).
> > >
> > > So, for the CPE (with respect to the host side, which is what
> draft-ietf-v6ops-dhcpv6-slaac-problem is about), it agrees with
> > Lorenzo's analysis.
> > >
> > > - Bernie
> > >
> > > -----Original Message-----
> > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
> sthaug@nethelp.no
> > > Sent: Wednesday, February 24, 2016 4:00 AM
> > > To: lorenzo@google.com
> > > Cc: v6ops@ietf.org
> > > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> > >
> > >> 1. I disagree with the statement "It is unclear whether hosts should
> > >> initiate DHCPv6 by themselves if there are no RAs at all." There is
> > >> not really point in using DHCPv6 without RAs. This is because DHCPv6
> > >> does not configure prefixes, only addresses without prefix lengths,
> > >> and therefore an address assigned by DHCPv6 either has no prefix
> > >> length or a prefix length of /128. See dhcpv6bs ticket 68:
> > >> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
> > >>
> > >> So starting DHCPv6 without an RA is pointless because even if you get
> > >> an address, you can't use to talk to anything. Thus, I don't think
> > >> there is any ambiguity here, since one of the alternatives doesn't
> > >> make sense. That said, if we do still want to say this is ambiguous,
> > >> then we should replace "ambiguous" with "unspecified", and add
> > >> something about the fact that
> > >> DHCPv6 without RAs is useless, such as:
> > >
> > > I can absolutely see this point of view. On the other hand - given
> that the M-bit is only a hint: If I were a CPE manufacturer, I might
> > find it perfectly rational to *always* start DHCPv6 (for simplicity's
> sake). I believe we've seen more than one CPE model doing exactly
> > that.
> > >
> > > Steinar Haug, AS2116
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--94eb2c031094cd209e052c8de48d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Which links? Even on point-to-point links such as PPP inte=
rfaces or 3GPP networks, routing requires an RA.

On Thu, Feb 25, 2016 at 9:50 AM, Templ=
in, Fred L <Fred.L.Templin@boeing.com> wrote:
On some links, invoking DHCPv6 immediately with=
out waiting for an RA is

natural and provides all the configuration information needed by the client=
.



Thanks - Fred

fred.l.templin@boeing.com<=
br>


> -----Original Message-----

> From: v6ops [mailto:v6ops-bo=
unces@ietf.org] On Behalf Of Rajiv Asati (rajiva)

> Sent: Wednesday, February 24, 2016 4:12 PM

> To: Bernie Volz (volz)

> Cc: v6ops@ietf.org

> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

>


> I agree that starting D=
HCPv6 without an RA is pointless / useless. And the draft should just state=
 that.

>

> But if the draft is referring to any existing RFC, then it is reasonab=
le to say the behavior not being specified (or unclear). Just avoid hair-
> splitting.

>

> Cheers,

> Rajiv Asati

> Distinguished Engineer, Cisco Services

>

>

> > On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz) <volz@cisco.com> wrote:

> >

> > CPE are both hosts and routers. Their specification is defined in=
 RFC 7084.

> >

> > With respect to the host (address assignment) side:

> >

> >=C2=A0 =C2=A0WAA-6:=C2=A0 =C2=A0If the IPv6 CE router receives a R=
outer Advertisement

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message (described in [R=
FC4861]) with the M flag set to 1,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the IPv6 CE router MUST =
do DHCPv6 address assignment

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (request an IA_NA option=
).

> >

> > With respect to the router (prefix delegation) side:

> >

> >=C2=A0 =C2=A0WPD-4:=C2=A0 By default, the IPv6 CE router MUST init=
iate DHCPv6 prefix

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delegation when either th=
e M or O flags are set to 1 in a

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0received Router Advertise=
ment (RA) message.=C2=A0 Behavior of the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CE router to use DHCPv6 p=
refix delegation when the CE router

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has not received any RA o=
r received an RA with the M and the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0O bits set to zero is out=
 of scope for this document.

> >

> > Though for the PD case, it doesn't say what to do if there is=
 no RA (out of scope!).

> >

> > So, for the CPE (with respect to the host side, which is what dra=
ft-ietf-v6ops-dhcpv6-slaac-problem is about), it agrees with

> Lorenzo's analysis.

> >

> > - Bernie

> >

> > -----Original Message-----

> > From: v6ops [mailto:v6o=
ps-bounces@ietf.org] On Behalf Of =
sthaug@nethelp.no

> > Sent: Wednesday, February 24, 2016 4:00 AM

> > To: lorenzo@google.com<=
br>
> > Cc: v6ops@ietf.org

> > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> >

> >> 1. I disagree with the statement "It is unclear whether =
hosts should

> >> initiate DHCPv6 by themselves if there are no RAs at all.&quo=
t; There is

> >> not really point in using DHCPv6 without RAs. This is because=
 DHCPv6

> >> does not configure prefixes, only addresses without prefix le=
ngths,

> >> and therefore an address assigned by DHCPv6 either has no pre=
fix

> >> length or a prefix length of /128. See dhcpv6bs ticket 68:
> >> http://trac.tools.ietf.org/group/d=
hcpv6bis/ticket/68

> >>

> >> So starting DHCPv6 without an RA is pointless because even if=
 you get

> >> an address, you can't use to talk to anything. Thus, I do=
n't think

> >> there is any ambiguity here, since one of the alternatives do=
esn't

> >> make sense. That said, if we do still want to say this is amb=
iguous,

> >> then we should replace "ambiguous" with "unspe=
cified", and add

> >> something about the fact that

> >> DHCPv6 without RAs is useless, such as:

> >

> > I can absolutely see this point of view. On the other hand - give=
n that the M-bit is only a hint: If I were a CPE manufacturer, I might

> find it perfectly rational to *always* start DHCPv6 (for simplicity=
9;s sake). I believe we've seen more than one CPE model doing exactly
> that.

> >

> > Steinar Haug, AS2116

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://www.ietf.org/mailman/listinfo/v6ops=


> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://www.ietf.org/mailman/listinfo/v6ops=


>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.org/mailman/listinfo/v6ops





_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--94eb2c031094cd209e052c8de48d--


From nobody Wed Feb 24 23:25:30 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5791A3BA1 for ; Wed, 24 Feb 2016 23:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.255
X-Spam-Level: 
X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxuLZJcwo1sd for ; Wed, 24 Feb 2016 23:25:26 -0800 (PST)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1902B1A1B98 for ; Wed, 24 Feb 2016 23:25:24 -0800 (PST)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Feb 2016 08:25:23 +0100
X-IronPort-AV: E=Sophos;i="5.22,497,1449529200";  d="scan'208,217";a="1013347853"
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 25 Feb 2016 08:25:22 +0100
Received: from HE100018.emea1.cds.t-internal.com (10.125.65.199) by HE111297.EMEA1.CDS.T-INTERNAL.COM (10.125.90.15) with Microsoft SMTP Server (TLS) id 8.3.377.0; Thu, 25 Feb 2016 08:25:20 +0100
Received: from HE113422.emea1.cds.t-internal.com ([10.125.65.92]) by HE100018.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 25 Feb 2016 08:25:20 +0100
From: 
To: , 
Date: Thu, 25 Feb 2016 08:25:19 +0100
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AdFvadXo3HSxcpkURm+hNjHd/wPUmQAM67Og
Message-ID: 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com> <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_DE552F704C63AC45BA7FAAFFC3D6ED020258A8D69F2EHE113422eme_"
MIME-Version: 1.0
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 07:25:29 -0000

--_000_DE552F704C63AC45BA7FAAFFC3D6ED020258A8D69F2EHE113422eme_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgSSByZW1lbWJlciByaWdodCwgdGhlbiBJIOKAmHZlIHNlZW4gQ1BFIGltcGxlbWVudGF0aW9u
cyB3aGljaCBmaXJlZCBESENQdjYgU29saWNpdHMgYW5kIFJTIGluIHBhcmFsbGVsIGp1c3QgdG8g
c3BlZWQgdXAgdGhlIHByb3Zpc2lvbmluZyBwcm9jZXNzLg0KT0JvDQoNCkZyb206IHY2b3BzIFtt
YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0
aQ0KU2VudDogRG9ubmVyc3RhZywgMjUuIEZlYnJ1YXIgMjAxNiAwMjoxMw0KVG86IFRlbXBsaW4s
IEZyZWQgTA0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1p
ZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtIFdHTEMNCg0KV2hpY2ggbGlua3M/IEV2ZW4g
b24gcG9pbnQtdG8tcG9pbnQgbGlua3Mgc3VjaCBhcyBQUFAgaW50ZXJmYWNlcyBvciAzR1BQIG5l
dHdvcmtzLCByb3V0aW5nIHJlcXVpcmVzIGFuIFJBLg0KDQpPbiBUaHUsIEZlYiAyNSwgMjAxNiBh
dCA5OjUwIEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFp
bHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCk9uIHNvbWUgbGlua3MsIGlu
dm9raW5nIERIQ1B2NiBpbW1lZGlhdGVseSB3aXRob3V0IHdhaXRpbmcgZm9yIGFuIFJBIGlzDQpu
YXR1cmFsIGFuZCBwcm92aWRlcyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVl
ZGVkIGJ5IHRoZSBjbGllbnQuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWlu
Zy5jb208bWFpbHRvOmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20+DQoNCj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJhaml2IEFz
YXRpIChyYWppdmEpDQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgNDoxMiBQ
TQ0KPiBUbzogQmVybmllIFZvbHogKHZvbHopDQo+IENjOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86
djZvcHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMt
ZGhjcHY2LXNsYWFjLXByb2JsZW0gV0dMQw0KPg0KPiBJIGFncmVlIHRoYXQgc3RhcnRpbmcgREhD
UHY2IHdpdGhvdXQgYW4gUkEgaXMgcG9pbnRsZXNzIC8gdXNlbGVzcy4gQW5kIHRoZSBkcmFmdCBz
aG91bGQganVzdCBzdGF0ZSB0aGF0Lg0KPg0KPiBCdXQgaWYgdGhlIGRyYWZ0IGlzIHJlZmVycmlu
ZyB0byBhbnkgZXhpc3RpbmcgUkZDLCB0aGVuIGl0IGlzIHJlYXNvbmFibGUgdG8gc2F5IHRoZSBi
ZWhhdmlvciBub3QgYmVpbmcgc3BlY2lmaWVkIChvciB1bmNsZWFyKS4gSnVzdCBhdm9pZCBoYWly
LQ0KPiBzcGxpdHRpbmcuDQo+DQo+IENoZWVycywNCj4gUmFqaXYgQXNhdGkNCj4gRGlzdGluZ3Vp
c2hlZCBFbmdpbmVlciwgQ2lzY28gU2VydmljZXMNCj4NCj4NCj4gPiBPbiBGZWIgMjQsIDIwMTYs
IGF0IDE6MzMgUE0sIEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRvOnZv
bHpAY2lzY28uY29tPj4gd3JvdGU6DQo+ID4NCj4gPiBDUEUgYXJlIGJvdGggaG9zdHMgYW5kIHJv
dXRlcnMuIFRoZWlyIHNwZWNpZmljYXRpb24gaXMgZGVmaW5lZCBpbiBSRkMgNzA4NC4NCj4gPg0K
PiA+IFdpdGggcmVzcGVjdCB0byB0aGUgaG9zdCAoYWRkcmVzcyBhc3NpZ25tZW50KSBzaWRlOg0K
PiA+DQo+ID4gICBXQUEtNjogICBJZiB0aGUgSVB2NiBDRSByb3V0ZXIgcmVjZWl2ZXMgYSBSb3V0
ZXIgQWR2ZXJ0aXNlbWVudA0KPiA+ICAgICAgICAgICAgbWVzc2FnZSAoZGVzY3JpYmVkIGluIFtS
RkM0ODYxXSkgd2l0aCB0aGUgTSBmbGFnIHNldCB0byAxLA0KPiA+ICAgICAgICAgICAgdGhlIElQ
djYgQ0Ugcm91dGVyIE1VU1QgZG8gREhDUHY2IGFkZHJlc3MgYXNzaWdubWVudA0KPiA+ICAgICAg
ICAgICAgKHJlcXVlc3QgYW4gSUFfTkEgb3B0aW9uKS4NCj4gPg0KPiA+IFdpdGggcmVzcGVjdCB0
byB0aGUgcm91dGVyIChwcmVmaXggZGVsZWdhdGlvbikgc2lkZToNCj4gPg0KPiA+ICAgV1BELTQ6
ICBCeSBkZWZhdWx0LCB0aGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBpbml0aWF0ZSBESENQdjYgcHJl
Zml4DQo+ID4gICAgICAgICAgIGRlbGVnYXRpb24gd2hlbiBlaXRoZXIgdGhlIE0gb3IgTyBmbGFn
cyBhcmUgc2V0IHRvIDEgaW4gYQ0KPiA+ICAgICAgICAgICByZWNlaXZlZCBSb3V0ZXIgQWR2ZXJ0
aXNlbWVudCAoUkEpIG1lc3NhZ2UuICBCZWhhdmlvciBvZiB0aGUNCj4gPiAgICAgICAgICAgQ0Ug
cm91dGVyIHRvIHVzZSBESENQdjYgcHJlZml4IGRlbGVnYXRpb24gd2hlbiB0aGUgQ0Ugcm91dGVy
DQo+ID4gICAgICAgICAgIGhhcyBub3QgcmVjZWl2ZWQgYW55IFJBIG9yIHJlY2VpdmVkIGFuIFJB
IHdpdGggdGhlIE0gYW5kIHRoZQ0KPiA+ICAgICAgICAgICBPIGJpdHMgc2V0IHRvIHplcm8gaXMg
b3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gVGhvdWdoIGZvciB0aGUg
UEQgY2FzZSwgaXQgZG9lc24ndCBzYXkgd2hhdCB0byBkbyBpZiB0aGVyZSBpcyBubyBSQSAob3V0
IG9mIHNjb3BlISkuDQo+ID4NCj4gPiBTbywgZm9yIHRoZSBDUEUgKHdpdGggcmVzcGVjdCB0byB0
aGUgaG9zdCBzaWRlLCB3aGljaCBpcyB3aGF0IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFj
LXByb2JsZW0gaXMgYWJvdXQpLCBpdCBhZ3JlZXMgd2l0aA0KPiBMb3JlbnpvJ3MgYW5hbHlzaXMu
DQo+ID4NCj4gPiAtIEJlcm5pZQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2
b3BzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Ygc3RoYXVnQG5ldGhlbHAubm88bWFp
bHRvOnN0aGF1Z0BuZXRoZWxwLm5vPg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQs
IDIwMTYgNDowMCBBTQ0KPiA+IFRvOiBsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9A
Z29vZ2xlLmNvbT4NCj4gPiBDYzogdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3Jn
Pg0KPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFj
LXByb2JsZW0gV0dMQw0KPiA+DQo+ID4+IDEuIEkgZGlzYWdyZWUgd2l0aCB0aGUgc3RhdGVtZW50
ICJJdCBpcyB1bmNsZWFyIHdoZXRoZXIgaG9zdHMgc2hvdWxkDQo+ID4+IGluaXRpYXRlIERIQ1B2
NiBieSB0aGVtc2VsdmVzIGlmIHRoZXJlIGFyZSBubyBSQXMgYXQgYWxsLiIgVGhlcmUgaXMNCj4g
Pj4gbm90IHJlYWxseSBwb2ludCBpbiB1c2luZyBESENQdjYgd2l0aG91dCBSQXMuIFRoaXMgaXMg
YmVjYXVzZSBESENQdjYNCj4gPj4gZG9lcyBub3QgY29uZmlndXJlIHByZWZpeGVzLCBvbmx5IGFk
ZHJlc3NlcyB3aXRob3V0IHByZWZpeCBsZW5ndGhzLA0KPiA+PiBhbmQgdGhlcmVmb3JlIGFuIGFk
ZHJlc3MgYXNzaWduZWQgYnkgREhDUHY2IGVpdGhlciBoYXMgbm8gcHJlZml4DQo+ID4+IGxlbmd0
aCBvciBhIHByZWZpeCBsZW5ndGggb2YgLzEyOC4gU2VlIGRoY3B2NmJzIHRpY2tldCA2ODoNCj4g
Pj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvZGhjcHY2YmlzL3RpY2tldC82OA0K
PiA+Pg0KPiA+PiBTbyBzdGFydGluZyBESENQdjYgd2l0aG91dCBhbiBSQSBpcyBwb2ludGxlc3Mg
YmVjYXVzZSBldmVuIGlmIHlvdSBnZXQNCj4gPj4gYW4gYWRkcmVzcywgeW91IGNhbid0IHVzZSB0
byB0YWxrIHRvIGFueXRoaW5nLiBUaHVzLCBJIGRvbid0IHRoaW5rDQo+ID4+IHRoZXJlIGlzIGFu
eSBhbWJpZ3VpdHkgaGVyZSwgc2luY2Ugb25lIG9mIHRoZSBhbHRlcm5hdGl2ZXMgZG9lc24ndA0K
PiA+PiBtYWtlIHNlbnNlLiBUaGF0IHNhaWQsIGlmIHdlIGRvIHN0aWxsIHdhbnQgdG8gc2F5IHRo
aXMgaXMgYW1iaWd1b3VzLA0KPiA+PiB0aGVuIHdlIHNob3VsZCByZXBsYWNlICJhbWJpZ3VvdXMi
IHdpdGggInVuc3BlY2lmaWVkIiwgYW5kIGFkZA0KPiA+PiBzb21ldGhpbmcgYWJvdXQgdGhlIGZh
Y3QgdGhhdA0KPiA+PiBESENQdjYgd2l0aG91dCBSQXMgaXMgdXNlbGVzcywgc3VjaCBhczoNCj4g
Pg0KPiA+IEkgY2FuIGFic29sdXRlbHkgc2VlIHRoaXMgcG9pbnQgb2Ygdmlldy4gT24gdGhlIG90
aGVyIGhhbmQgLSBnaXZlbiB0aGF0IHRoZSBNLWJpdCBpcyBvbmx5IGEgaGludDogSWYgSSB3ZXJl
IGEgQ1BFIG1hbnVmYWN0dXJlciwgSSBtaWdodA0KPiBmaW5kIGl0IHBlcmZlY3RseSByYXRpb25h
bCB0byAqYWx3YXlzKiBzdGFydCBESENQdjYgKGZvciBzaW1wbGljaXR5J3Mgc2FrZSkuIEkgYmVs
aWV2ZSB3ZSd2ZSBzZWVuIG1vcmUgdGhhbiBvbmUgQ1BFIG1vZGVsIGRvaW5nIGV4YWN0bHkNCj4g
dGhhdC4NCj4gPg0KPiA+IFN0ZWluYXIgSGF1ZywgQVMyMTE2DQo+ID4NCj4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcg
bGlzdA0KPiA+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCj4gPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxp
bmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcg
bGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9w
c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg==

--_000_DE552F704C63AC45BA7FAAFFC3D6ED020258A8D69F2EHE113422eme_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFu
LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5
Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVT
IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPklmIEkgcmVtZW1iZXIgcmlnaHQsIHRoZW4gSSDigJh2ZSBzZWVuIENQRSBpbXBsZW1lbnRh
dGlvbnMgd2hpY2ggZmlyZWQgREhDUHY2IFNvbGljaXRzIGFuZCBSUyBpbiBwYXJhbGxlbCBqdXN0
IHRvIHNwZWVkIHVwIHRoZSBwcm92aXNpb25pbmcgcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPk9Cbzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtj
b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5
bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g
MGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHY2b3BzIFttYWlsdG86
djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0
dGk8YnI+PGI+U2VudDo8L2I+IERvbm5lcnN0YWcsIDI1LiBGZWJydWFyIDIwMTYgMDI6MTM8YnI+
PGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEw8YnI+PGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxi
cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xh
YWMtcHJvYmxlbSBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz
PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5X
aGljaCBsaW5rcz8gRXZlbiBvbiBwb2ludC10by1wb2ludCBsaW5rcyBzdWNoIGFzIFBQUCBpbnRl
cmZhY2VzIG9yIDNHUFAgbmV0d29ya3MsIHJvdXRpbmcgcmVxdWlyZXMgYW4gUkEuPG86cD48L286
cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgOTo1MCBBTSwg
VGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5n
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+T24gc29tZSBsaW5rcywgaW52
b2tpbmcgREhDUHY2IGltbWVkaWF0ZWx5IHdpdGhvdXQgd2FpdGluZyBmb3IgYW4gUkEgaXM8YnI+
bmF0dXJhbCBhbmQgcHJvdmlkZXMgYWxsIHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIG5l
ZWRlZCBieSB0aGUgY2xpZW50Ljxicj48YnI+VGhhbmtzIC0gRnJlZDxicj48YSBocmVmPSJtYWls
dG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTwv
YT48YnI+PGJyPjxzcGFuIGNsYXNzPWltPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWltPiZndDsgRnJvbTogdjZvcHMgW21haWx0bzo8YSBocmVm
PSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIE9uIEJlaGFsZiBPZiBSYWppdiBBc2F0aSAocmFqaXZhKTwvc3Bhbj48YnI+PHNwYW4gY2xh
c3M9aW0+Jmd0OyBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDQ6MTIgUE08L3Nw
YW4+PGJyPjxzcGFuIGNsYXNzPWltPiZndDsgVG86IEJlcm5pZSBWb2x6ICh2b2x6KTwvc3Bhbj48
YnI+PHNwYW4gY2xhc3M9aW0+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn
Ij52Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWltPiZndDsgU3ViamVj
dDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xD
PC9zcGFuPjxicj48c3BhbiBjbGFzcz1pbT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyBJIGFncmVlIHRoYXQgc3RhcnRpbmcgREhDUHY2
IHdpdGhvdXQgYW4gUkEgaXMgcG9pbnRsZXNzIC8gdXNlbGVzcy4gQW5kIHRoZSBkcmFmdCBzaG91
bGQganVzdCBzdGF0ZSB0aGF0Ljxicj4mZ3Q7PGJyPiZndDsgQnV0IGlmIHRoZSBkcmFmdCBpcyBy
ZWZlcnJpbmcgdG8gYW55IGV4aXN0aW5nIFJGQywgdGhlbiBpdCBpcyByZWFzb25hYmxlIHRvIHNh
eSB0aGUgYmVoYXZpb3Igbm90IGJlaW5nIHNwZWNpZmllZCAob3IgdW5jbGVhcikuIEp1c3QgYXZv
aWQgaGFpci08YnI+Jmd0OyBzcGxpdHRpbmcuPGJyPiZndDs8YnI+Jmd0OyBDaGVlcnMsPGJyPiZn
dDsgUmFqaXYgQXNhdGk8YnI+Jmd0OyBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2
aWNlczxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAmZ3Q7IE9uIEZlYiAyNCwgMjAxNiwgYXQgMToz
MyBQTSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5j
b20iPnZvbHpAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZn
dDsgQ1BFIGFyZSBib3RoIGhvc3RzIGFuZCByb3V0ZXJzLiBUaGVpciBzcGVjaWZpY2F0aW9uIGlz
IGRlZmluZWQgaW4gUkZDIDcwODQuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgV2l0aCByZXNw
ZWN0IHRvIHRoZSBob3N0IChhZGRyZXNzIGFzc2lnbm1lbnQpIHNpZGU6PGJyPiZndDsgJmd0Ozxi
cj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7V0FBLTY6Jm5ic3A7ICZuYnNwO0lmIHRoZSBJUHY2IENF
IHJvdXRlciByZWNlaXZlcyBhIFJvdXRlciBBZHZlcnRpc2VtZW50PGJyPiZndDsgJmd0OyZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2UgKGRlc2NyaWJlZCBp
biBbUkZDNDg2MV0pIHdpdGggdGhlIE0gZmxhZyBzZXQgdG8gMSw8YnI+Jmd0OyAmZ3Q7Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIElQdjYgQ0Ugcm91dGVyIE1V
U1QgZG8gREhDUHY2IGFkZHJlc3MgYXNzaWdubWVudDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAocmVxdWVzdCBhbiBJQV9OQSBvcHRpb24pLjxi
cj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFdpdGggcmVzcGVjdCB0byB0aGUgcm91dGVyIChwcmVm
aXggZGVsZWdhdGlvbikgc2lkZTo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyZuYnNwOyAmbmJz
cDtXUEQtNDombmJzcDsgQnkgZGVmYXVsdCwgdGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgaW5pdGlh
dGUgREhDUHY2IHByZWZpeDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO2RlbGVnYXRpb24gd2hlbiBlaXRoZXIgdGhlIE0gb3IgTyBmbGFncyBhcmUg
c2V0IHRvIDEgaW4gYTxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3JlY2VpdmVkIFJvdXRlciBBZHZlcnRpc2VtZW50IChSQSkgbWVzc2FnZS4mbmJz
cDsgQmVoYXZpb3Igb2YgdGhlPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7Q0Ugcm91dGVyIHRvIHVzZSBESENQdjYgcHJlZml4IGRlbGVnYXRpb24g
d2hlbiB0aGUgQ0Ugcm91dGVyPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7aGFzIG5vdCByZWNlaXZlZCBhbnkgUkEgb3IgcmVjZWl2ZWQgYW4gUkEg
d2l0aCB0aGUgTSBhbmQgdGhlPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7TyBiaXRzIHNldCB0byB6ZXJvIGlzIG91dCBvZiBzY29wZSBmb3IgdGhp
cyBkb2N1bWVudC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaG91Z2ggZm9yIHRoZSBQRCBj
YXNlLCBpdCBkb2Vzbid0IHNheSB3aGF0IHRvIGRvIGlmIHRoZXJlIGlzIG5vIFJBIChvdXQgb2Yg
c2NvcGUhKS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBTbywgZm9yIHRoZSBDUEUgKHdpdGgg
cmVzcGVjdCB0byB0aGUgaG9zdCBzaWRlLCB3aGljaCBpcyB3aGF0IGRyYWZ0LWlldGYtdjZvcHMt
ZGhjcHY2LXNsYWFjLXByb2JsZW0gaXMgYWJvdXQpLCBpdCBhZ3JlZXMgd2l0aDxicj4mZ3Q7IExv
cmVuem8ncyBhbmFseXNpcy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAtIEJlcm5pZTxicj4m
Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsg
Jmd0OyBGcm9tOiB2Nm9wcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGll
dGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIDxhIGhyZWY9
Im1haWx0bzpzdGhhdWdAbmV0aGVscC5ubyI+c3RoYXVnQG5ldGhlbHAubm88L2E+PGJyPiZndDsg
Jmd0OyBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDQ6MDAgQU08YnI+Jmd0OyAm
Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIj5sb3JlbnpvQGdvb2ds
ZS5jb208L2E+PGJyPiZndDsgJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn
Ij52Nm9wc0BpZXRmLm9yZzwvYT48YnI+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRy
YWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0gV0dMQzxicj4mZ3Q7ICZndDs8YnI+
Jmd0OyAmZ3Q7Jmd0OyAxLiBJIGRpc2FncmVlIHdpdGggdGhlIHN0YXRlbWVudCAmcXVvdDtJdCBp
cyB1bmNsZWFyIHdoZXRoZXIgaG9zdHMgc2hvdWxkPGJyPiZndDsgJmd0OyZndDsgaW5pdGlhdGUg
REhDUHY2IGJ5IHRoZW1zZWx2ZXMgaWYgdGhlcmUgYXJlIG5vIFJBcyBhdCBhbGwuJnF1b3Q7IFRo
ZXJlIGlzPGJyPiZndDsgJmd0OyZndDsgbm90IHJlYWxseSBwb2ludCBpbiB1c2luZyBESENQdjYg
d2l0aG91dCBSQXMuIFRoaXMgaXMgYmVjYXVzZSBESENQdjY8YnI+Jmd0OyAmZ3Q7Jmd0OyBkb2Vz
IG5vdCBjb25maWd1cmUgcHJlZml4ZXMsIG9ubHkgYWRkcmVzc2VzIHdpdGhvdXQgcHJlZml4IGxl
bmd0aHMsPGJyPiZndDsgJmd0OyZndDsgYW5kIHRoZXJlZm9yZSBhbiBhZGRyZXNzIGFzc2lnbmVk
IGJ5IERIQ1B2NiBlaXRoZXIgaGFzIG5vIHByZWZpeDxicj4mZ3Q7ICZndDsmZ3Q7IGxlbmd0aCBv
ciBhIHByZWZpeCBsZW5ndGggb2YgLzEyOC4gU2VlIGRoY3B2NmJzIHRpY2tldCA2ODo8YnI+Jmd0
OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9kaGNw
djZiaXMvdGlja2V0LzY4IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v
cmcvZ3JvdXAvZGhjcHY2YmlzL3RpY2tldC82ODwvYT48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7
ICZndDsmZ3Q7IFNvIHN0YXJ0aW5nIERIQ1B2NiB3aXRob3V0IGFuIFJBIGlzIHBvaW50bGVzcyBi
ZWNhdXNlIGV2ZW4gaWYgeW91IGdldDxicj4mZ3Q7ICZndDsmZ3Q7IGFuIGFkZHJlc3MsIHlvdSBj
YW4ndCB1c2UgdG8gdGFsayB0byBhbnl0aGluZy4gVGh1cywgSSBkb24ndCB0aGluazxicj4mZ3Q7
ICZndDsmZ3Q7IHRoZXJlIGlzIGFueSBhbWJpZ3VpdHkgaGVyZSwgc2luY2Ugb25lIG9mIHRoZSBh
bHRlcm5hdGl2ZXMgZG9lc24ndDxicj4mZ3Q7ICZndDsmZ3Q7IG1ha2Ugc2Vuc2UuIFRoYXQgc2Fp
ZCwgaWYgd2UgZG8gc3RpbGwgd2FudCB0byBzYXkgdGhpcyBpcyBhbWJpZ3VvdXMsPGJyPiZndDsg
Jmd0OyZndDsgdGhlbiB3ZSBzaG91bGQgcmVwbGFjZSAmcXVvdDthbWJpZ3VvdXMmcXVvdDsgd2l0
aCAmcXVvdDt1bnNwZWNpZmllZCZxdW90OywgYW5kIGFkZDxicj4mZ3Q7ICZndDsmZ3Q7IHNvbWV0
aGluZyBhYm91dCB0aGUgZmFjdCB0aGF0PGJyPiZndDsgJmd0OyZndDsgREhDUHY2IHdpdGhvdXQg
UkFzIGlzIHVzZWxlc3MsIHN1Y2ggYXM6PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgSSBjYW4g
YWJzb2x1dGVseSBzZWUgdGhpcyBwb2ludCBvZiB2aWV3LiBPbiB0aGUgb3RoZXIgaGFuZCAtIGdp
dmVuIHRoYXQgdGhlIE0tYml0IGlzIG9ubHkgYSBoaW50OiBJZiBJIHdlcmUgYSBDUEUgbWFudWZh
Y3R1cmVyLCBJIG1pZ2h0PGJyPiZndDsgZmluZCBpdCBwZXJmZWN0bHkgcmF0aW9uYWwgdG8gKmFs
d2F5cyogc3RhcnQgREhDUHY2IChmb3Igc2ltcGxpY2l0eSdzIHNha2UpLiBJIGJlbGlldmUgd2Un
dmUgc2VlbiBtb3JlIHRoYW4gb25lIENQRSBtb2RlbCBkb2luZyBleGFjdGx5PGJyPiZndDsgdGhh
dC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBTdGVpbmFyIEhhdWcsIEFTMjExNjxicj4mZ3Q7
ICZndDs8YnI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPiZndDsgJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7IDxh
IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPiZndDsg
Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92
Nm9wczwvYT48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgdjZvcHMgbWFpbGluZyBsaXN0
PGJyPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYu
b3JnPC9hPjxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IHY2b3BzIG1haWxpbmcgbGlz
dDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8
L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdjZvcHM8L2E+PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+djZvcHMgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0
bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9w
PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv
cD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_DE552F704C63AC45BA7FAAFFC3D6ED020258A8D69F2EHE113422eme_--


From nobody Wed Feb 24 23:58:55 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8A51A1AE3 for ; Wed, 24 Feb 2016 23:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vryL4Z0gmN_f for ; Wed, 24 Feb 2016 23:58:52 -0800 (PST)
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 744E01A01A9 for ; Wed, 24 Feb 2016 23:58:52 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (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 A767080D52; Thu, 25 Feb 2016 08:58:47 +0100 (CET)
To: Lorenzo Colitti , Fred Baker 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56CEB3F2.8060101@si6networks.com>
Date: Thu, 25 Feb 2016 04:57:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 07:58:54 -0000

Hi, Lorenzo,

On 02/24/2016 03:58 AM, Lorenzo Colitti wrote:
> Substantive points:
> 
> 1. I disagree with the statement "It is unclear whether hosts should
> initiate DHCPv6 by themselves if there are no RAs at all." There is not
> really point in using DHCPv6 without RAs. This is because DHCPv6 does
> not configure prefixes, only addresses without prefix lengths, and
> therefore an address assigned by DHCPv6 either has no prefix length or a
> prefix length of /128. See dhcpv6bs ticket 68:
> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
> 
> So starting DHCPv6 without an RA is pointless because even if you get an
> address, you can't use to talk to anything.

Yes, we should close that gap. Sad that a religious war essentially ends
up with *two* mandatory protocols. Because in many scenarios, you need both.


> Thus, I don't think there is
> any ambiguity here, since one of the alternatives doesn't make sense.
> That said, if we do still want to say this is ambiguous, then we should
> replace "ambiguous" with "unspecified", and add something about the fact
> that DHCPv6 without RAs is useless, such as:
> 
> ===
> It should be noted that DHCPv6 by itself only communicates address
> information, not reachability information. The fact that an address was
> received from DHCPv6 does not imply that that address can reach any
> destination outside the host itself. Therefore, even if DHCPv6 succeeds
> without an RA, the resulting configuration is not useful for network
> communication.
> ===

This is fine, although "reachability" can be misleading.



> 3. Where the draft says "It could be reasonably deduced that M flag
> should be independent from A flag" - again, the text should mention that
> for a client following draft-ietf-dhc-anonymity-profile, that's not true.

Which again brings the question of why such document is not updating the
corresponding spec.



> 7. The draft makes no mention of Android. Perhaps it should say that
> Android does not have this problem because it does not implement DHCPv6?

That's kind of misleading ;-).  That could be read to mean that it's
actually a good thing that android does not support ipv6.
(FWIW, Nodes that don't do v6 don't have this problem, either.)



> Minor issues:
> 
> 1. In the introduction, but SLAAC first and DHCPv6 second, because in
> the IPv6 node requirements, SLAAC is MUST and DHCPv6 is a SHOULD.

+1 (after s/but/put/)

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





From nobody Thu Feb 25 00:05:18 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172091A1BBC for ; Thu, 25 Feb 2016 00:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joFGdQXwvnMr for ; Thu, 25 Feb 2016 00:05:15 -0800 (PST)
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 BF2381A1B8C for ; Thu, 25 Feb 2016 00:05:15 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id g127so36846990ywf.2 for ; Thu, 25 Feb 2016 00:05:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QR2JeXoLTAK4pIAiZiEyb31ij9kzHu5ENHszFwAdfz4=; b=hA27mcalqWr4UwafI8sIxfowcjtYE7dkQ/nbHhtY37cly5CGC43pny+f0BfvgvzzTg aZyFDSyakSh/HyuHXkwtAT+PNwBoQLIl1zDvr2/2Xst7iphK+yYpRlV/eryKDspmftpS JgBzX3DssbiEZCQKwGJfcghMFQ7cYqlX/AU+o+Q3WaRHPv1RY4/cQZO+djPiMxRDKpFZ uhrJshXBHXsWuDgL8LFBYbII1NnhTXUb5leNfxwCBbF3TJU7HcBfK2c1rF4F33l6lfs+ nSuFf3HexS83HmcVfYXMFtp7HIO5mpRceyDF2HmtpjNZ4s9lyTk7ELquRcDrFxiZzTG+ rEXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QR2JeXoLTAK4pIAiZiEyb31ij9kzHu5ENHszFwAdfz4=; b=C4xxHHj+HXpAMWFlmJtW5ycgt0Llg2Kq2ZauH2H8GP7q4IpxJtOKZ/g65qReHsTNsj KLeytHeTsgE+o/NEPwgVsaQURzN6kmMNEtHuPj7wWgDYdTmBOiz7yi7SiScYwwHt/DLb DaaTMZtMweXteompUYj+A9SWpnyKqAZfSWxsqtueNDcdqiRIW33otG/hSYBt885bzEMr /BFKnN7uyFIkRstySPKb0Zf0+s4i2sQHY+UNNQ5NPzfg/5UFGQLFUKMMWybTK5C/3Isx cXLS2v/5BNcu4rKbi6UETr/gu4DxBF6xa/xcx6gud/+UFSB9tqDI9r2vRheexoYWKLiO OJHQ==
X-Gm-Message-State: AG10YOR0HF4G19i/1ccsHSUPZwyqLe1aCWE3syk/KTDfKUaOi6AhdYz1C0RYZS0NXJ+Cd/wUFYoMIUaHGMaWs3Te
X-Received: by 10.129.52.203 with SMTP id b194mr24026959ywa.337.1456387514975;  Thu, 25 Feb 2016 00:05:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Thu, 25 Feb 2016 00:04:55 -0800 (PST)
In-Reply-To: <56CEB3F2.8060101@si6networks.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <56CEB3F2.8060101@si6networks.com>
From: Lorenzo Colitti 
Date: Thu, 25 Feb 2016 17:04:55 +0900
Message-ID: 
To: Fernando Gont 
Content-Type: multipart/alternative; boundary=001a114141c67cbea6052c93a409
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 08:05:17 -0000

--001a114141c67cbea6052c93a409
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 25, 2016 at 4:57 PM, Fernando Gont 
wrote:

> > So starting DHCPv6 without an RA is pointless because even if you get an
> > address, you can't use to talk to anything.
>
> Yes, we should close that gap. Sad that a religious war essentially ends
> up with *two* mandatory protocols. Because in many scenarios, you need
> both.
>

Well, that's not something we can do in this WG.


> > 3. Where the draft says "It could be reasonably deduced that M flag
> > should be independent from A flag" - again, the text should mention that
> > for a client following draft-ietf-dhc-anonymity-profile, that's not true.
>
> Which again brings the question of why such document is not updating the
> corresponding spec.
>

I think you'll have to take that up with the IESG at this point. Obviously
they took the position that doing so was not necessary; I suspect that
position is far from conteroversial.


> > 7. The draft makes no mention of Android. Perhaps it should say that
> > Android does not have this problem because it does not implement DHCPv6?
>
> That's kind of misleading ;-).  That could be read to mean that it's
> actually a good thing that android does not support ipv6.
> (FWIW, Nodes that don't do v6 don't have this problem, either.)
>

We can say whatever we can get WG consensus on, but I think we have to say
something about Android, because there are more Android devices than most
of the platforms that you do say something about.

--001a114141c67cbea6052c93a409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Feb 25, 2016 at 4:57 PM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
> S=
o starting DHCPv6 without an RA is pointless because even if you get an

> address, you can't use to talk to anything.



Yes, we should close that gap. Sad that a religious war essentially =
ends

up with *two* mandatory protocols. Because in many scenarios, you need both=
.

Well, that's not something we can=
 do in this WG.
=C2=A0
> 3. Where the draft says "It could be reasonably deduce=
d that M flag

> should be independent from A flag" - again, the text should menti=
on that

> for a client following draft-ietf-dhc-anonymity-profile, that's no=
t true.



Which again brings the question of why such document is not updating=
 the

corresponding spec.

I think you'll =
have to take that up with the IESG at this point. Obviously they took the p=
osition that doing so was not necessary; I suspect that position is far fro=
m conteroversial.
=C2=A0
> 7. The draft makes no mention of Android. Perhaps it shou=
ld say that

> Android does not have this problem because it does not implement DHCPv=
6?



That's kind of misleading ;-).=C2=A0 That could be read to mean =
that it's

actually a good thing that android does not support ipv6.

(FWIW, Nodes that don't do v6 don't have this problem, either.)
=


We can say whatever we can get WG consensu=
s on, but I think we have to say something about Android, because there are=
 more Android devices than most of the platforms that you do say something =
about.


--001a114141c67cbea6052c93a409--


From nobody Thu Feb 25 03:51:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6471A1BB5 for ; Thu, 25 Feb 2016 03:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.982
X-Spam-Level: 
X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt-iJjI4CvHD for ; Thu, 25 Feb 2016 03:51:12 -0800 (PST)
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 0D6E61A1BB0 for ; Thu, 25 Feb 2016 03:51:11 -0800 (PST)
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 u1PBp9FW003794 for ; Thu, 25 Feb 2016 12:51:09 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 77B9C202584 for ; Thu, 25 Feb 2016 12:51:19 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 66633200B4D for ; Thu, 25 Feb 2016 12:51:19 +0100 (CET)
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 u1PBp92d030842 for ; Thu, 25 Feb 2016 12:51:09 +0100
From: Alexandre Petrescu 
To: "v6ops@ietf.org" 
Message-ID: <56CEEAAD.2070807@gmail.com>
Date: Thu, 25 Feb 2016 12:51:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030703050605090209030107"
Archived-At: 
Subject: [v6ops] Is VINLI/TMobile supporting IPv6?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 11:51:14 -0000

This is a multi-part message in MIME format.
--------------030703050605090209030107
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

Is VINLI in-car hotspot device supporting IPv6?

This device is recently announced.  It wouldnt be a scoop because there 
are many other such OBD-WiFi devices in the market.  But VINLI says 
tmobile which seems to be offering IPv6 to end users.

Alex

--------------030703050605090209030107
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Hello,

      

      Is VINLI in-car hotspot device supporting IPv6?

      

      This device is recently announced.  It wouldnt be a scoop because
      there are many other such OBD-WiFi devices in the market.  But
      VINLI says tmobile which seems to be offering IPv6 to end users.

      

      Alex

    
  


--------------030703050605090209030107--


From nobody Thu Feb 25 07:28:03 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1951B2A90 for ; Thu, 25 Feb 2016 07:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.606
X-Spam-Level: 
X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EzDKtX77Mil for ; Thu, 25 Feb 2016 07:27:49 -0800 (PST)
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 EBE451B2A75 for ; Thu, 25 Feb 2016 07:27:48 -0800 (PST)
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 u1PFRtTD012503; Thu, 25 Feb 2016 07:27:55 -0800
Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1PFRqXv012485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Feb 2016 07:27:53 -0800
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-PHX-512.sw.nos.boeing.com ([10.57.37.29]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 07:27:45 -0800
From: "Templin, Fred L" 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbNo04muWj7mmQkeNAnAx3wsjGZ87LGGAgAAh1wCAAKA7gP//+ha5gAAJ2jCAAI13AIAAZ9fw
Date: Thu, 25 Feb 2016 15:27:44 +0000
Message-ID: <2134F8430051B64F815C691A62D9831833972F7E@XCH-BLV-105.nw.nos.boeing.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com> <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831833972F7EXCHBLV105nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:27:55 -0000

--_000_2134F8430051B64F815C691A62D9831833972F7EXCHBLV105nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTG9yZW56bywNCg0KT24gQUVSTyBsaW5rcywgdGhlIGRlZmF1bHQgcm91dGVyIGFuZCBESENQ
djYgc2VydmVyIGFyZSBhbHdheXMgb25lIGFuZCB0aGUgc2FtZS4NClNvLCB3aGVuIHRoZSBESENQ
djYgc2VydmVyIGRlbGVnYXRlcyBhIHByZWZpeCwgdGhlIGNsaWVudCBhbHJlYWR5IGtub3dzIHRo
YXQgaXQgaXMNCnRoZSBkZWZhdWx0IHJvdXRlciB3aXRob3V0IGhhdmluZyB0byByZWNlaXZlIGFu
IFJBLg0KDQpUaGFua3Mg4oCTIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KRnJv
bTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogV2Vk
bmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA1OjEzIFBNDQpUbzogVGVtcGxpbiwgRnJlZCBMDQpD
YzogUmFqaXYgQXNhdGkgKHJhaml2YSk7IEJlcm5pZSBWb2x6ICh2b2x6KTsgdjZvcHNAaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXBy
b2JsZW0gV0dMQw0KDQpXaGljaCBsaW5rcz8gRXZlbiBvbiBwb2ludC10by1wb2ludCBsaW5rcyBz
dWNoIGFzIFBQUCBpbnRlcmZhY2VzIG9yIDNHUFAgbmV0d29ya3MsIHJvdXRpbmcgcmVxdWlyZXMg
YW4gUkEuDQoNCk9uIFRodSwgRmViIDI1LCAyMDE2IGF0IDk6NTAgQU0sIFRlbXBsaW4sIEZyZWQg
TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5n
LmNvbT4+IHdyb3RlOg0KT24gc29tZSBsaW5rcywgaW52b2tpbmcgREhDUHY2IGltbWVkaWF0ZWx5
IHdpdGhvdXQgd2FpdGluZyBmb3IgYW4gUkEgaXMNCm5hdHVyYWwgYW5kIHByb3ZpZGVzIGFsbCB0
aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhlIGNsaWVudC4NCg0KVGhh
bmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86ZnJlZC5sLnRlbXBs
aW5AYm9laW5nLmNvbT4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2
Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNA
aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUmFqaXYgQXNhdGkgKHJhaml2YSkNCj4gU2VudDogV2Vk
bmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA0OjEyIFBNDQo+IFRvOiBCZXJuaWUgVm9seiAodm9s
eikNCj4gQ2M6IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gU3ViamVj
dDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xD
DQo+DQo+IEkgYWdyZWUgdGhhdCBzdGFydGluZyBESENQdjYgd2l0aG91dCBhbiBSQSBpcyBwb2lu
dGxlc3MgLyB1c2VsZXNzLiBBbmQgdGhlIGRyYWZ0IHNob3VsZCBqdXN0IHN0YXRlIHRoYXQuDQo+
DQo+IEJ1dCBpZiB0aGUgZHJhZnQgaXMgcmVmZXJyaW5nIHRvIGFueSBleGlzdGluZyBSRkMsIHRo
ZW4gaXQgaXMgcmVhc29uYWJsZSB0byBzYXkgdGhlIGJlaGF2aW9yIG5vdCBiZWluZyBzcGVjaWZp
ZWQgKG9yIHVuY2xlYXIpLiBKdXN0IGF2b2lkIGhhaXItDQo+IHNwbGl0dGluZy4NCj4NCj4gQ2hl
ZXJzLA0KPiBSYWppdiBBc2F0aQ0KPiBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2
aWNlcw0KPg0KPg0KPiA+IE9uIEZlYiAyNCwgMjAxNiwgYXQgMTozMyBQTSwgQmVybmllIFZvbHog
KHZvbHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCj4g
Pg0KPiA+IENQRSBhcmUgYm90aCBob3N0cyBhbmQgcm91dGVycy4gVGhlaXIgc3BlY2lmaWNhdGlv
biBpcyBkZWZpbmVkIGluIFJGQyA3MDg0Lg0KPiA+DQo+ID4gV2l0aCByZXNwZWN0IHRvIHRoZSBo
b3N0IChhZGRyZXNzIGFzc2lnbm1lbnQpIHNpZGU6DQo+ID4NCj4gPiAgIFdBQS02OiAgIElmIHRo
ZSBJUHY2IENFIHJvdXRlciByZWNlaXZlcyBhIFJvdXRlciBBZHZlcnRpc2VtZW50DQo+ID4gICAg
ICAgICAgICBtZXNzYWdlIChkZXNjcmliZWQgaW4gW1JGQzQ4NjFdKSB3aXRoIHRoZSBNIGZsYWcg
c2V0IHRvIDEsDQo+ID4gICAgICAgICAgICB0aGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBkbyBESENQ
djYgYWRkcmVzcyBhc3NpZ25tZW50DQo+ID4gICAgICAgICAgICAocmVxdWVzdCBhbiBJQV9OQSBv
cHRpb24pLg0KPiA+DQo+ID4gV2l0aCByZXNwZWN0IHRvIHRoZSByb3V0ZXIgKHByZWZpeCBkZWxl
Z2F0aW9uKSBzaWRlOg0KPiA+DQo+ID4gICBXUEQtNDogIEJ5IGRlZmF1bHQsIHRoZSBJUHY2IENF
IHJvdXRlciBNVVNUIGluaXRpYXRlIERIQ1B2NiBwcmVmaXgNCj4gPiAgICAgICAgICAgZGVsZWdh
dGlvbiB3aGVuIGVpdGhlciB0aGUgTSBvciBPIGZsYWdzIGFyZSBzZXQgdG8gMSBpbiBhDQo+ID4g
ICAgICAgICAgIHJlY2VpdmVkIFJvdXRlciBBZHZlcnRpc2VtZW50IChSQSkgbWVzc2FnZS4gIEJl
aGF2aW9yIG9mIHRoZQ0KPiA+ICAgICAgICAgICBDRSByb3V0ZXIgdG8gdXNlIERIQ1B2NiBwcmVm
aXggZGVsZWdhdGlvbiB3aGVuIHRoZSBDRSByb3V0ZXINCj4gPiAgICAgICAgICAgaGFzIG5vdCBy
ZWNlaXZlZCBhbnkgUkEgb3IgcmVjZWl2ZWQgYW4gUkEgd2l0aCB0aGUgTSBhbmQgdGhlDQo+ID4g
ICAgICAgICAgIE8gYml0cyBzZXQgdG8gemVybyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9j
dW1lbnQuDQo+ID4NCj4gPiBUaG91Z2ggZm9yIHRoZSBQRCBjYXNlLCBpdCBkb2Vzbid0IHNheSB3
aGF0IHRvIGRvIGlmIHRoZXJlIGlzIG5vIFJBIChvdXQgb2Ygc2NvcGUhKS4NCj4gPg0KPiA+IFNv
LCBmb3IgdGhlIENQRSAod2l0aCByZXNwZWN0IHRvIHRoZSBob3N0IHNpZGUsIHdoaWNoIGlzIHdo
YXQgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBpcyBhYm91dCksIGl0IGFn
cmVlcyB3aXRoDQo+IExvcmVuem8ncyBhbmFseXNpcy4NCj4gPg0KPiA+IC0gQmVybmllDQo+ID4N
Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHY2b3BzIFttYWlsdG86
djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz5dIE9u
IEJlaGFsZiBPZiBzdGhhdWdAbmV0aGVscC5ubzxtYWlsdG86c3RoYXVnQG5ldGhlbHAubm8+DQo+
ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA0OjAwIEFNDQo+ID4gVG86IGxv
cmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPg0KPiA+IENjOiB2Nm9w
c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFt2Nm9w
c10gZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDDQo+ID4NCj4gPj4g
MS4gSSBkaXNhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnQgIkl0IGlzIHVuY2xlYXIgd2hldGhlciBo
b3N0cyBzaG91bGQNCj4gPj4gaW5pdGlhdGUgREhDUHY2IGJ5IHRoZW1zZWx2ZXMgaWYgdGhlcmUg
YXJlIG5vIFJBcyBhdCBhbGwuIiBUaGVyZSBpcw0KPiA+PiBub3QgcmVhbGx5IHBvaW50IGluIHVz
aW5nIERIQ1B2NiB3aXRob3V0IFJBcy4gVGhpcyBpcyBiZWNhdXNlIERIQ1B2Ng0KPiA+PiBkb2Vz
IG5vdCBjb25maWd1cmUgcHJlZml4ZXMsIG9ubHkgYWRkcmVzc2VzIHdpdGhvdXQgcHJlZml4IGxl
bmd0aHMsDQo+ID4+IGFuZCB0aGVyZWZvcmUgYW4gYWRkcmVzcyBhc3NpZ25lZCBieSBESENQdjYg
ZWl0aGVyIGhhcyBubyBwcmVmaXgNCj4gPj4gbGVuZ3RoIG9yIGEgcHJlZml4IGxlbmd0aCBvZiAv
MTI4LiBTZWUgZGhjcHY2YnMgdGlja2V0IDY4Og0KPiA+PiBodHRwOi8vdHJhYy50b29scy5pZXRm
Lm9yZy9ncm91cC9kaGNwdjZiaXMvdGlja2V0LzY4DQo+ID4+DQo+ID4+IFNvIHN0YXJ0aW5nIERI
Q1B2NiB3aXRob3V0IGFuIFJBIGlzIHBvaW50bGVzcyBiZWNhdXNlIGV2ZW4gaWYgeW91IGdldA0K
PiA+PiBhbiBhZGRyZXNzLCB5b3UgY2FuJ3QgdXNlIHRvIHRhbGsgdG8gYW55dGhpbmcuIFRodXMs
IEkgZG9uJ3QgdGhpbmsNCj4gPj4gdGhlcmUgaXMgYW55IGFtYmlndWl0eSBoZXJlLCBzaW5jZSBv
bmUgb2YgdGhlIGFsdGVybmF0aXZlcyBkb2Vzbid0DQo+ID4+IG1ha2Ugc2Vuc2UuIFRoYXQgc2Fp
ZCwgaWYgd2UgZG8gc3RpbGwgd2FudCB0byBzYXkgdGhpcyBpcyBhbWJpZ3VvdXMsDQo+ID4+IHRo
ZW4gd2Ugc2hvdWxkIHJlcGxhY2UgImFtYmlndW91cyIgd2l0aCAidW5zcGVjaWZpZWQiLCBhbmQg
YWRkDQo+ID4+IHNvbWV0aGluZyBhYm91dCB0aGUgZmFjdCB0aGF0DQo+ID4+IERIQ1B2NiB3aXRo
b3V0IFJBcyBpcyB1c2VsZXNzLCBzdWNoIGFzOg0KPiA+DQo+ID4gSSBjYW4gYWJzb2x1dGVseSBz
ZWUgdGhpcyBwb2ludCBvZiB2aWV3LiBPbiB0aGUgb3RoZXIgaGFuZCAtIGdpdmVuIHRoYXQgdGhl
IE0tYml0IGlzIG9ubHkgYSBoaW50OiBJZiBJIHdlcmUgYSBDUEUgbWFudWZhY3R1cmVyLCBJIG1p
Z2h0DQo+IGZpbmQgaXQgcGVyZmVjdGx5IHJhdGlvbmFsIHRvICphbHdheXMqIHN0YXJ0IERIQ1B2
NiAoZm9yIHNpbXBsaWNpdHkncyBzYWtlKS4gSSBiZWxpZXZlIHdlJ3ZlIHNlZW4gbW9yZSB0aGFu
IG9uZSBDUEUgbW9kZWwgZG9pbmcgZXhhY3RseQ0KPiB0aGF0Lg0KPiA+DQo+ID4gU3RlaW5hciBI
YXVnLCBBUzIxMTYNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmc8
bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdjZvcHMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5v
cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdjZvcHMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnPG1h
aWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby92Nm9wcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0Bp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K

--_000_2134F8430051B64F815C691A62D9831833972F7EXCHBLV105nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmltDQoJe21zby1zdHls
ZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5
N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPk9uIEFFUk8gbGlua3MsIHRoZSBkZWZhdWx0IHJvdXRlciBhbmQgREhDUHY2IHNlcnZlciBh
cmUgYWx3YXlzIG9uZSBhbmQgdGhlIHNhbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCB3aGVuIHRo
ZSBESENQdjYgc2VydmVyIGRlbGVnYXRlcyBhIHByZWZpeCwgdGhlIGNsaWVudCBhbHJlYWR5IGtu
b3dzIHRoYXQgaXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIGRlZmF1bHQgcm91dGVyIHdpdGhv
dXQgaGF2aW5nIHRvIHJlY2VpdmUgYW4gUkEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRl
bXBsaW5AYm9laW5nLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVu
em9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0
LCAyMDE2IDU6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTDxicj4NCjxiPkNj
OjwvYj4gUmFqaXYgQXNhdGkgKHJhaml2YSk7IEJlcm5pZSBWb2x6ICh2b2x6KTsgdjZvcHNAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1k
aGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWNoIGxpbmtzPyBFdmVuIG9uIHBvaW50LXRvLXBvaW50
IGxpbmtzIHN1Y2ggYXMgUFBQIGludGVyZmFjZXMgb3IgM0dQUCBuZXR3b3Jrcywgcm91dGluZyBy
ZXF1aXJlcyBhbiBSQS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIFRodSwgRmViIDI1LCAyMDE2IGF0IDk6NTAgQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5r
Ij5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gc29tZSBsaW5rcywgaW52b2tp
bmcgREhDUHY2IGltbWVkaWF0ZWx5IHdpdGhvdXQgd2FpdGluZyBmb3IgYW4gUkEgaXM8YnI+DQpu
YXR1cmFsIGFuZCBwcm92aWRlcyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVl
ZGVkIGJ5IHRoZSBjbGllbnQuPGJyPg0KPGJyPg0KVGhhbmtzIC0gRnJlZDxicj4NCjxhIGhyZWY9
Im1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tIj5mcmVkLmwudGVtcGxpbkBib2Vpbmcu
Y29tPC9hPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgRnJvbTogdjZvcHMg
W21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91
bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBSYWppdiBBc2F0aSAocmFqaXZhKTwvc3Bh
bj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAy
NCwgMjAxNiA0OjEyIFBNPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBUbzogQmVy
bmllIFZvbHogKHZvbHopPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBDYzogPGEg
aHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJy
Pg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYt
djZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0gV0dMQzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i
aW0iPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDsgSSBhZ3JlZSB0aGF0IHN0YXJ0aW5nIERIQ1B2NiB3aXRob3V0IGFuIFJB
IGlzIHBvaW50bGVzcyAvIHVzZWxlc3MuIEFuZCB0aGUgZHJhZnQgc2hvdWxkIGp1c3Qgc3RhdGUg
dGhhdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCdXQgaWYgdGhlIGRyYWZ0IGlzIHJlZmVycmluZyB0
byBhbnkgZXhpc3RpbmcgUkZDLCB0aGVuIGl0IGlzIHJlYXNvbmFibGUgdG8gc2F5IHRoZSBiZWhh
dmlvciBub3QgYmVpbmcgc3BlY2lmaWVkIChvciB1bmNsZWFyKS4gSnVzdCBhdm9pZCBoYWlyLTxi
cj4NCiZndDsgc3BsaXR0aW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7
IFJhaml2IEFzYXRpPGJyPg0KJmd0OyBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2
aWNlczxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIEZlYiAyNCwgMjAxNiwg
YXQgMTozMyBQTSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBj
aXNjby5jb20iPnZvbHpAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7IENQRSBhcmUgYm90aCBob3N0cyBhbmQgcm91dGVycy4gVGhlaXIgc3BlY2lm
aWNhdGlvbiBpcyBkZWZpbmVkIGluIFJGQyA3MDg0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0OyBXaXRoIHJlc3BlY3QgdG8gdGhlIGhvc3QgKGFkZHJlc3MgYXNzaWdubWVudCkgc2lkZTo8
YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7V0FBLTY6Jm5ic3A7ICZu
YnNwO0lmIHRoZSBJUHY2IENFIHJvdXRlciByZWNlaXZlcyBhIFJvdXRlciBBZHZlcnRpc2VtZW50
PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
bWVzc2FnZSAoZGVzY3JpYmVkIGluIFtSRkM0ODYxXSkgd2l0aCB0aGUgTSBmbGFnIHNldCB0byAx
LDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IHRoZSBJUHY2IENFIHJvdXRlciBNVVNUIGRvIERIQ1B2NiBhZGRyZXNzIGFzc2lnbm1lbnQ8YnI+
DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAocmVx
dWVzdCBhbiBJQV9OQSBvcHRpb24pLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXaXRo
IHJlc3BlY3QgdG8gdGhlIHJvdXRlciAocHJlZml4IGRlbGVnYXRpb24pIHNpZGU6PGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO1dQRC00OiZuYnNwOyBCeSBkZWZhdWx0
LCB0aGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBpbml0aWF0ZSBESENQdjYgcHJlZml4PGJyPg0KJmd0
OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZWxlZ2F0aW9u
IHdoZW4gZWl0aGVyIHRoZSBNIG9yIE8gZmxhZ3MgYXJlIHNldCB0byAxIGluIGE8YnI+DQomZ3Q7
ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlY2VpdmVkIFJv
dXRlciBBZHZlcnRpc2VtZW50IChSQSkgbWVzc2FnZS4mbmJzcDsgQmVoYXZpb3Igb2YgdGhlPGJy
Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDRSBy
b3V0ZXIgdG8gdXNlIERIQ1B2NiBwcmVmaXggZGVsZWdhdGlvbiB3aGVuIHRoZSBDRSByb3V0ZXI8
YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hh
cyBub3QgcmVjZWl2ZWQgYW55IFJBIG9yIHJlY2VpdmVkIGFuIFJBIHdpdGggdGhlIE0gYW5kIHRo
ZTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
TyBiaXRzIHNldCB0byB6ZXJvIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC48YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhvdWdoIGZvciB0aGUgUEQgY2FzZSwgaXQgZG9l
c24ndCBzYXkgd2hhdCB0byBkbyBpZiB0aGVyZSBpcyBubyBSQSAob3V0IG9mIHNjb3BlISkuPGJy
Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNvLCBmb3IgdGhlIENQRSAod2l0aCByZXNwZWN0
IHRvIHRoZSBob3N0IHNpZGUsIHdoaWNoIGlzIHdoYXQgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYt
c2xhYWMtcHJvYmxlbSBpcyBhYm91dCksIGl0IGFncmVlcyB3aXRoPGJyPg0KJmd0OyBMb3Jlbnpv
J3MgYW5hbHlzaXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0gQmVybmllPGJyPg0K
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K
Jmd0OyAmZ3Q7IEZyb206IHY2b3BzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5j
ZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YNCjxh
IGhyZWY9Im1haWx0bzpzdGhhdWdAbmV0aGVscC5ubyI+c3RoYXVnQG5ldGhlbHAubm88L2E+PGJy
Pg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgNDowMCBBTTxi
cj4NCiZndDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bG9y
ZW56b0Bnb29nbGUuY29tPC9hPjxicj4NCiZndDsgJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2
b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDog
UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDPGJy
Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAxLiBJIGRpc2FncmVlIHdpdGggdGhlIHN0
YXRlbWVudCAmcXVvdDtJdCBpcyB1bmNsZWFyIHdoZXRoZXIgaG9zdHMgc2hvdWxkPGJyPg0KJmd0
OyAmZ3Q7Jmd0OyBpbml0aWF0ZSBESENQdjYgYnkgdGhlbXNlbHZlcyBpZiB0aGVyZSBhcmUgbm8g
UkFzIGF0IGFsbC4mcXVvdDsgVGhlcmUgaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG5vdCByZWFsbHkg
cG9pbnQgaW4gdXNpbmcgREhDUHY2IHdpdGhvdXQgUkFzLiBUaGlzIGlzIGJlY2F1c2UgREhDUHY2
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBkb2VzIG5vdCBjb25maWd1cmUgcHJlZml4ZXMsIG9ubHkgYWRk
cmVzc2VzIHdpdGhvdXQgcHJlZml4IGxlbmd0aHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgdGhl
cmVmb3JlIGFuIGFkZHJlc3MgYXNzaWduZWQgYnkgREhDUHY2IGVpdGhlciBoYXMgbm8gcHJlZml4
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBsZW5ndGggb3IgYSBwcmVmaXggbGVuZ3RoIG9mIC8xMjguIFNl
ZSBkaGNwdjZicyB0aWNrZXQgNjg6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8v
dHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9kaGNwdjZiaXMvdGlja2V0LzY4IiB0YXJnZXQ9Il9i
bGFuayI+DQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9kaGNwdjZiaXMvdGlja2V0
LzY4PC9hPjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNvIHN0YXJ0aW5n
IERIQ1B2NiB3aXRob3V0IGFuIFJBIGlzIHBvaW50bGVzcyBiZWNhdXNlIGV2ZW4gaWYgeW91IGdl
dDxicj4NCiZndDsgJmd0OyZndDsgYW4gYWRkcmVzcywgeW91IGNhbid0IHVzZSB0byB0YWxrIHRv
IGFueXRoaW5nLiBUaHVzLCBJIGRvbid0IHRoaW5rPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGVyZSBp
cyBhbnkgYW1iaWd1aXR5IGhlcmUsIHNpbmNlIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmVzIGRvZXNu
J3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IG1ha2Ugc2Vuc2UuIFRoYXQgc2FpZCwgaWYgd2UgZG8gc3Rp
bGwgd2FudCB0byBzYXkgdGhpcyBpcyBhbWJpZ3VvdXMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGVu
IHdlIHNob3VsZCByZXBsYWNlICZxdW90O2FtYmlndW91cyZxdW90OyB3aXRoICZxdW90O3Vuc3Bl
Y2lmaWVkJnF1b3Q7LCBhbmQgYWRkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzb21ldGhpbmcgYWJvdXQg
dGhlIGZhY3QgdGhhdDxicj4NCiZndDsgJmd0OyZndDsgREhDUHY2IHdpdGhvdXQgUkFzIGlzIHVz
ZWxlc3MsIHN1Y2ggYXM6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgY2FuIGFic29s
dXRlbHkgc2VlIHRoaXMgcG9pbnQgb2Ygdmlldy4gT24gdGhlIG90aGVyIGhhbmQgLSBnaXZlbiB0
aGF0IHRoZSBNLWJpdCBpcyBvbmx5IGEgaGludDogSWYgSSB3ZXJlIGEgQ1BFIG1hbnVmYWN0dXJl
ciwgSSBtaWdodDxicj4NCiZndDsgZmluZCBpdCBwZXJmZWN0bHkgcmF0aW9uYWwgdG8gKmFsd2F5
cyogc3RhcnQgREhDUHY2IChmb3Igc2ltcGxpY2l0eSdzIHNha2UpLiBJIGJlbGlldmUgd2UndmUg
c2VlbiBtb3JlIHRoYW4gb25lIENQRSBtb2RlbCBkb2luZyBleGFjdGx5PGJyPg0KJmd0OyB0aGF0
Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTdGVpbmFyIEhhdWcsIEFTMjExNjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwv
YT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7
IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNA
aWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQomZ3Q7
PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86
djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJy
Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5v
cmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_2134F8430051B64F815C691A62D9831833972F7EXCHBLV105nwnosb_--


From nobody Thu Feb 25 10:56:40 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1581B3177 for ; Thu, 25 Feb 2016 10:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olYLRu03jCLh for ; Thu, 25 Feb 2016 10:56:36 -0800 (PST)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 ACF0A1B3124 for ; Thu, 25 Feb 2016 10:56:36 -0800 (PST)
Received: by mail-vk0-x236.google.com with SMTP id c3so56433940vkb.3 for ; Thu, 25 Feb 2016 10:56:36 -0800 (PST)
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-type:content-transfer-encoding; bh=ACHaCIdAiIXluuNw9ohzb7aO55zgumH+C1U1ke0mKuM=; b=w4aHBDYNVav08XgXDUhOSs3ZmYcXpOGzOGfy224C65q2ofBfRdN3H/WqD0Wo8n1Ezx sM6vMpUr8qzeWYzxLOTBDN5fsNkNJN7PeV5FS3Ax61POktJGb9pZ+PBmeYncESL5NVNk EV1OSgNmcXZTy3IHOxyn0rJ/Ot2T5OsvyHf3njxHmHkiQsYRZszXp3VqBM6gm9RvQjEh 65fKZlY1/vByHgA5SO8oNkFXBypLAbN7Y0tToZyv7VUGoYbM4NA/3aswLaZqSOD5aioF xcQPumY7DU2H4ozMewajmbNsdeHasrhdZgrOFqkhgsl1zSrW2xEIStOcntbs7uTz1zYd x+JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ACHaCIdAiIXluuNw9ohzb7aO55zgumH+C1U1ke0mKuM=; b=i2EZ4OMCPnKxm72devdMZw9Qv1cOxuUeW/k5WQKiuH9Zc670NoR6zPnkzkLBAjjcAA cOWsSJiIRNkABtTETyB3Mkqew5omkpn6uD07lcTOCI+HG3RW9/PViSBqQ5isq4NgzyVH AJoFWTV1c6F+RwH3G92ES0vbdjo+fc5n6Kot3T5U3TWvh106fDf4oLqPdF8nZ54I18gu Kw7js5BSYBD8z1AfnUdwZIQZ/1TSP1c3ad6b7xoFYzLSefVkMuYXty5UpiW5lwxWYO86 qzrV5I9teLP4+UKuhCQlioqLFDNSzc3Py2NyiiwGpJKoahOfQeGv8KlikMqZtck/0IKn AbwQ==
X-Gm-Message-State: AG10YOQRalP7h2pM14ySS62YgJOfRYyuYcLLUG2fO3meAxlbBjJ4a4P3/I9vwmJGtLjRU0vqmuWeSPXGTZSLTA==
X-Received: by 10.31.167.195 with SMTP id q186mr37046261vke.113.1456426595714;  Thu, 25 Feb 2016 10:56:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.5.68 with HTTP; Thu, 25 Feb 2016 10:56:06 -0800 (PST)
In-Reply-To: <2134F8430051B64F815C691A62D9831833972F7E@XCH-BLV-105.nw.nos.boeing.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com> <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com>  <2134F8430051B64F815C691A62D9831833972F7E@XCH-BLV-105.nw.nos.boeing.com>
From: Mark Smith 
Date: Fri, 26 Feb 2016 05:56:06 +1100
Message-ID: 
To: "Templin, Fred L" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 18:56:38 -0000

On 26 February 2016 at 02:27, Templin, Fred L  w=
rote:
> Hi Lorenzo,
>
>
>
> On AERO links, the default router and DHCPv6 server are always one and th=
e
> same.
>
> So, when the DHCPv6 server delegates a prefix, the client already knows t=
hat
> it is
>
> the default router without having to receive an RA.
>
>

Which I suppose means:

- default router redundancy is achieved by having multiple DHCPv6 servers

- DHCPv6 servers MUST be on the same link as the AERO clients, in
other words, there is no place in the AERO for DHCPv6 relays


One concern I have with binding DHCPv6 server and default router
functionality is that upgrading the DHCPv6 server software (e.g., to
support a new option) will typically also disrupt all of the clients
traffic being forwarded by the co-located router, including clients
that will get no benefit from the new option.

I've thought that one of the benefits of decoupling application
protocol understanding from the network (i.e., application protocol
traffic rides over the top of the Internet to between the edges) is
that upgrading applications and their protocols doesn't require
upgrading the network to support them.

I've subsequently thought that the same model should be applied to and
deployed for higher layer and application configuration, not just the
application protocols themselves. It has been to DHCPv6, in the sense
that DHCPv6 relays are DHCPv6 option transparent. However, when a
DHCPv6 client and server are colocated as an alternative to a DHCPv6
relay, then the DHCPv6 option transparency has gone.

https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#sec=
tion-2


Regards,
Mark.

>
> Thanks =E2=80=93 Fred
>
> fred.l.templin@boeing.com
>
>
>
> From: Lorenzo Colitti [mailto:lorenzo@google.com]
> Sent: Wednesday, February 24, 2016 5:13 PM
> To: Templin, Fred L
> Cc: Rajiv Asati (rajiva); Bernie Volz (volz); v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
>
>
>
> Which links? Even on point-to-point links such as PPP interfaces or 3GPP
> networks, routing requires an RA.
>
>
>
> On Thu, Feb 25, 2016 at 9:50 AM, Templin, Fred L 
> wrote:
>
> On some links, invoking DHCPv6 immediately without waiting for an RA is
> natural and provides all the configuration information needed by the clie=
nt.
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Rajiv Asati
>> (rajiva)
>> Sent: Wednesday, February 24, 2016 4:12 PM
>> To: Bernie Volz (volz)
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
>>
>
>> I agree that starting DHCPv6 without an RA is pointless / useless. And t=
he
>> draft should just state that.
>>
>> But if the draft is referring to any existing RFC, then it is reasonable
>> to say the behavior not being specified (or unclear). Just avoid hair-
>> splitting.
>>
>> Cheers,
>> Rajiv Asati
>> Distinguished Engineer, Cisco Services
>>
>>
>> > On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz)  wrote=
:
>> >
>> > CPE are both hosts and routers. Their specification is defined in RFC
>> > 7084.
>> >
>> > With respect to the host (address assignment) side:
>> >
>> >   WAA-6:   If the IPv6 CE router receives a Router Advertisement
>> >            message (described in [RFC4861]) with the M flag set to 1,
>> >            the IPv6 CE router MUST do DHCPv6 address assignment
>> >            (request an IA_NA option).
>> >
>> > With respect to the router (prefix delegation) side:
>> >
>> >   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>> >           delegation when either the M or O flags are set to 1 in a
>> >           received Router Advertisement (RA) message.  Behavior of the
>> >           CE router to use DHCPv6 prefix delegation when the CE router
>> >           has not received any RA or received an RA with the M and the
>> >           O bits set to zero is out of scope for this document.
>> >
>> > Though for the PD case, it doesn't say what to do if there is no RA (o=
ut
>> > of scope!).
>> >
>> > So, for the CPE (with respect to the host side, which is what
>> > draft-ietf-v6ops-dhcpv6-slaac-problem is about), it agrees with
>> Lorenzo's analysis.
>> >
>> > - Bernie
>> >
>> > -----Original Message-----
>> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
>> > sthaug@nethelp.no
>> > Sent: Wednesday, February 24, 2016 4:00 AM
>> > To: lorenzo@google.com
>> > Cc: v6ops@ietf.org
>> > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
>> >
>> >> 1. I disagree with the statement "It is unclear whether hosts should
>> >> initiate DHCPv6 by themselves if there are no RAs at all." There is
>> >> not really point in using DHCPv6 without RAs. This is because DHCPv6
>> >> does not configure prefixes, only addresses without prefix lengths,
>> >> and therefore an address assigned by DHCPv6 either has no prefix
>> >> length or a prefix length of /128. See dhcpv6bs ticket 68:
>> >> http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68
>> >>
>> >> So starting DHCPv6 without an RA is pointless because even if you get
>> >> an address, you can't use to talk to anything. Thus, I don't think
>> >> there is any ambiguity here, since one of the alternatives doesn't
>> >> make sense. That said, if we do still want to say this is ambiguous,
>> >> then we should replace "ambiguous" with "unspecified", and add
>> >> something about the fact that
>> >> DHCPv6 without RAs is useless, such as:
>> >
>> > I can absolutely see this point of view. On the other hand - given tha=
t
>> > the M-bit is only a hint: If I were a CPE manufacturer, I might
>> find it perfectly rational to *always* start DHCPv6 (for simplicity's
>> sake). I believe we've seen more than one CPE model doing exactly
>> that.
>> >
>> > Steinar Haug, AS2116
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Thu Feb 25 11:24:18 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1F91B3282 for ; Thu, 25 Feb 2016 11:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dstpvlIIewtt for ; Thu, 25 Feb 2016 11:24:14 -0800 (PST)
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 A051C1B327D for ; Thu, 25 Feb 2016 11:24:14 -0800 (PST)
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 u1PJOE1T011087; Thu, 25 Feb 2016 12:24:14 -0700
Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u1PJO8fG011016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Feb 2016 12:24:09 -0700
Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.221]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.41]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 11:24:08 -0800
From: "Templin, Fred L" 
To: Mark Smith 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbNo04muWj7mmQkeNAnAx3wsjGZ87LGGAgAAh1wCAAKA7gP//+ha5gAAJ2jCAAI13AIAAZ9fwgADBEwD//3txcA==
Date: Thu, 25 Feb 2016 19:24:07 +0000
Message-ID: <2134F8430051B64F815C691A62D98318339734E5@XCH-BLV-105.nw.nos.boeing.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <20160224.095930.74682405.sthaug@nethelp.no>  <782F873D-387B-4F65-9E34-934DE58DD1A5@cisco.com> <2134F8430051B64F815C691A62D98318339719F2@XCH-BLV-105.nw.nos.boeing.com>  <2134F8430051B64F815C691A62D9831833972F7E@XCH-BLV-105.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:24:17 -0000

SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt
aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZl
YnJ1YXJ5IDI1LCAyMDE2IDEwOjU2IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4gQ2M6IExv
cmVuem8gQ29saXR0aTsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJh
ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDDQo+IA0KPiBPbiAyNiBGZWJy
dWFyeSAyMDE2IGF0IDAyOjI3LCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu
Zy5jb20+IHdyb3RlOg0KPiA+IEhpIExvcmVuem8sDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gQUVS
TyBsaW5rcywgdGhlIGRlZmF1bHQgcm91dGVyIGFuZCBESENQdjYgc2VydmVyIGFyZSBhbHdheXMg
b25lIGFuZCB0aGUNCj4gPiBzYW1lLg0KPiA+DQo+ID4gU28sIHdoZW4gdGhlIERIQ1B2NiBzZXJ2
ZXIgZGVsZWdhdGVzIGEgcHJlZml4LCB0aGUgY2xpZW50IGFscmVhZHkga25vd3MgdGhhdA0KPiA+
IGl0IGlzDQo+ID4NCj4gPiB0aGUgZGVmYXVsdCByb3V0ZXIgd2l0aG91dCBoYXZpbmcgdG8gcmVj
ZWl2ZSBhbiBSQS4NCj4gPg0KPiA+DQo+IA0KPiBXaGljaCBJIHN1cHBvc2UgbWVhbnM6DQo+IA0K
PiAtIGRlZmF1bHQgcm91dGVyIHJlZHVuZGFuY3kgaXMgYWNoaWV2ZWQgYnkgaGF2aW5nIG11bHRp
cGxlIERIQ1B2NiBzZXJ2ZXJzDQo+IA0KPiAtIERIQ1B2NiBzZXJ2ZXJzIE1VU1QgYmUgb24gdGhl
IHNhbWUgbGluayBhcyB0aGUgQUVSTyBjbGllbnRzLCBpbg0KPiBvdGhlciB3b3JkcywgdGhlcmUg
aXMgbm8gcGxhY2UgaW4gdGhlIEFFUk8gZm9yIERIQ1B2NiByZWxheXMNCg0KQWN0dWFsbHksIEkg
bWlzLXNwb2tlLiBJdCBpcyB0aGUgY2xpZW50J3MgcmVsYXRpb25zaGlwIHdpdGggdGhlIERIQ1B2
NiByZWxheSB0aGF0DQptYXR0ZXJzLiBJdCBqdXN0IHNvIGhhcHBlbnMgaW4gdGhlIEFFUk8gZGVz
aWduIHRoYXQgTGlnaHR3ZWlnaHQgREhDUHY2IFJlbGF5DQpBZ2VudCBwZXIgUkZDNjIyMSBpcyB1
c2VkLiBTbywgZnJvbSB0aGUgY2xpZW50J3MgcGVyc3BlY3RpdmUgaXQgbG9va3MgbGlrZSB0aGUN
CkRIQ1B2NiBzZXJ2ZXIgaXMgb24gdGhlIHNhbWUgbGluayBidXQgaW4gZmFjdCB0aGVyZSBpcyBh
IExEUkEgYXMgYnVtcC1pbi10aGUtDQpzdGFjayBpbiB0aGUgcGF0aC4gU28sIHRvIGFuc3dlciB5
b3VyIGZpcnN0IHF1ZXN0aW9uLCBkZWZhdWx0IHJvdXRlcg0KcmVkdW5kYW5jeSBpcyBhY2hpZXZl
ZCBieSBoYXZpbmcgbXVsdGlwbGUgREhDUHY2IHJlbGF5cyB3aGljaCBpbiB0aGUNCmNhc2Ugb2Yg
QUVSTyB1c3VhbGx5IHJlc3VsdHMgaW4gbXVsdGlwbGUgREhDUHY2IHNlcnZlcnMgKG9uZSBmb3Ig
ZWFjaCByZWxheSkuDQogDQo+IE9uZSBjb25jZXJuIEkgaGF2ZSB3aXRoIGJpbmRpbmcgREhDUHY2
IHNlcnZlciBhbmQgZGVmYXVsdCByb3V0ZXINCj4gZnVuY3Rpb25hbGl0eSBpcyB0aGF0IHVwZ3Jh
ZGluZyB0aGUgREhDUHY2IHNlcnZlciBzb2Z0d2FyZSAoZS5nLiwgdG8NCj4gc3VwcG9ydCBhIG5l
dyBvcHRpb24pIHdpbGwgdHlwaWNhbGx5IGFsc28gZGlzcnVwdCBhbGwgb2YgdGhlIGNsaWVudHMN
Cj4gdHJhZmZpYyBiZWluZyBmb3J3YXJkZWQgYnkgdGhlIGNvLWxvY2F0ZWQgcm91dGVyLCBpbmNs
dWRpbmcgY2xpZW50cw0KPiB0aGF0IHdpbGwgZ2V0IG5vIGJlbmVmaXQgZnJvbSB0aGUgbmV3IG9w
dGlvbi4NCg0KSXQgaXMgdGhlIElBX1BEIGxpZmV0aW1lIG9mIHRoZSBkZWxlZ2F0ZWQgcHJlZml4
IGZyb20gdGhlIERIQ1B2NiBzZXJ2ZXINCnRoYXQgdGhlIGNsaWVudCB1c2VzIHRvIGRldGVybWlu
ZSB0aGUgZGVmYXVsdCByb3V0ZXIgbGlmZXRpbWUuIElmIHRoZQ0KREhDUHY2IHNlcnZlciBuZWVk
cyB0byBiZSB1cGdyYWRlZCwgd29uJ3QgaXQgaXNzdWUgYSBSZWNvbmZpZ3VyZQ0Kb3Igc29tZXRo
aW5nIGxpa2UgdGhhdD8gQW5kLCB0aGVuIHRoZSBjbGllbnQgd2lsbCBvbmNlIGFnYWluIHJlY2Vp
dmUNCmEgdmFsaWQgSUFfUEQgbGlmZXRpbWUuDQoNCj4gSSd2ZSB0aG91Z2h0IHRoYXQgb25lIG9m
IHRoZSBiZW5lZml0cyBvZiBkZWNvdXBsaW5nIGFwcGxpY2F0aW9uDQo+IHByb3RvY29sIHVuZGVy
c3RhbmRpbmcgZnJvbSB0aGUgbmV0d29yayAoaS5lLiwgYXBwbGljYXRpb24gcHJvdG9jb2wNCj4g
dHJhZmZpYyByaWRlcyBvdmVyIHRoZSB0b3Agb2YgdGhlIEludGVybmV0IHRvIGJldHdlZW4gdGhl
IGVkZ2VzKSBpcw0KPiB0aGF0IHVwZ3JhZGluZyBhcHBsaWNhdGlvbnMgYW5kIHRoZWlyIHByb3Rv
Y29scyBkb2Vzbid0IHJlcXVpcmUNCj4gdXBncmFkaW5nIHRoZSBuZXR3b3JrIHRvIHN1cHBvcnQg
dGhlbS4NCg0KTm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0aGF0LCBidXQgd291bGRuJ3QgcmVi
b290aW5nIHRoZSBoeWJyaWQNCnJvdXRlci9yZWxheS9zZXJ2ZXIgYW1vdW50IHRvIHRoZSBzYW1l
IHRoaW5nIGFzIHJlYm9vdGluZyBhbmQNCm9yZGluYXJ5IElQdjYgcm91dGVyPw0KDQo+IEkndmUg
c3Vic2VxdWVudGx5IHRob3VnaHQgdGhhdCB0aGUgc2FtZSBtb2RlbCBzaG91bGQgYmUgYXBwbGll
ZCB0byBhbmQNCj4gZGVwbG95ZWQgZm9yIGhpZ2hlciBsYXllciBhbmQgYXBwbGljYXRpb24gY29u
ZmlndXJhdGlvbiwgbm90IGp1c3QgdGhlDQo+IGFwcGxpY2F0aW9uIHByb3RvY29scyB0aGVtc2Vs
dmVzLiBJdCBoYXMgYmVlbiB0byBESENQdjYsIGluIHRoZSBzZW5zZQ0KPiB0aGF0IERIQ1B2NiBy
ZWxheXMgYXJlIERIQ1B2NiBvcHRpb24gdHJhbnNwYXJlbnQuIEhvd2V2ZXIsIHdoZW4gYQ0KPiBE
SENQdjYgY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIGNvbG9jYXRlZCBhcyBhbiBhbHRlcm5hdGl2ZSB0
byBhIERIQ1B2Ng0KPiByZWxheSwgdGhlbiB0aGUgREhDUHY2IG9wdGlvbiB0cmFuc3BhcmVuY3kg
aGFzIGdvbmUuDQoNClJpZ2h0LCBhbmQgc2VlIGFib3ZlIGZvciBteSByZXZpc2VkIGV4cGxhbmF0
aW9uLiBUaGUgREhDUHY2IHJlbGF5DQppcyBpbmRlZWQgaW5jbHVkZWQgZXZlbiB3aGVuIGl0IGlz
IGp1c3QgYSBidW1wLWluLXRoZS1zdGFjay4NCg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtc21pdGgtdjZvcHMtY2UtZGhjcHY2LXRyYW5zcGFyZW5jeS0wMCNzZWN0aW9uLTIN
Cg0KSSBzZWUgd2hhdCB5b3UgbWVhbi4gV2l0aCBBRVJPLCB0aGUgREhDUHY2IHNlcnZlciBtYWlu
dGFpbnMgb25seSB0aGUNCklBX1BEIGxlYXNlIGRhdGFiYXNlIHRoZSBzYW1lIGFzIGFueSBvcmRp
bmFyeSBESENQdjYgc2VydmVyLCBhbmQgdGhlDQpyZWxheSBpcyB0cmFuc3BhcmVudCBpbiB0aGUg
bmV0d29yay4gSWYgdGhlIERIQ1B2NiBzZXJ2ZXIgbmVlZHMgdG8gYmUNCnJlc3RhcnRlZCwgdGhl
biB0aGUgbGVhc2UgZGF0YWJhc2UgbmVlZHMgdG8gYmUgcmV0YWluZWQgYnV0IHRoZQ0KY2xpZW50
cyBhbmQgcm91dGVyIHdpbGwgY29udGludWUgdG8gZnVuY3Rpb24gbm9ybWFsbHkgdW50aWwgdGhl
IHNlcnZlcg0KY29tZXMgYmFjayBvbmxpbmUuIE9yLCBpZiB0aGUgcm91dGVyL3JlbGF5L3NlcnZl
ciBjcmFzaGVzIGFsdG9nZXRoZXIsDQp0aGUgY2xpZW50cyBjYW4gc2ltcGx5IGZhaWwgb3ZlciB0
byBhbm90aGVyIHJvdXRlci9yZWxheS9zZXJ2ZXIuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50
ZW1wbGluQGJvZWluZy5jb20NCg0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiANCj4gPg0KPiA+IFRo
YW5rcyDigJMgRnJlZA0KPiA+DQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+
ID4NCj4gPg0KPiA+IEZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xl
LmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDU6MTMgUE0NCj4g
PiBUbzogVGVtcGxpbiwgRnJlZCBMDQo+ID4gQ2M6IFJhaml2IEFzYXRpIChyYWppdmEpOyBCZXJu
aWUgVm9seiAodm9seik7IHY2b3BzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFt2Nm9wc10g
ZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDDQo+ID4NCj4gPg0KPiA+
DQo+ID4gV2hpY2ggbGlua3M/IEV2ZW4gb24gcG9pbnQtdG8tcG9pbnQgbGlua3Mgc3VjaCBhcyBQ
UFAgaW50ZXJmYWNlcyBvciAzR1BQDQo+ID4gbmV0d29ya3MsIHJvdXRpbmcgcmVxdWlyZXMgYW4g
UkEuDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgOTo1MCBBTSwg
VGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+IHdyb3RlOg0K
PiA+DQo+ID4gT24gc29tZSBsaW5rcywgaW52b2tpbmcgREhDUHY2IGltbWVkaWF0ZWx5IHdpdGhv
dXQgd2FpdGluZyBmb3IgYW4gUkEgaXMNCj4gPiBuYXR1cmFsIGFuZCBwcm92aWRlcyBhbGwgdGhl
IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVlZGVkIGJ5IHRoZSBjbGllbnQuDQo+ID4NCj4g
PiBUaGFua3MgLSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHY2b3BzIFttYWlsdG86djZv
cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhaml2IEFzYXRpDQo+ID4+IChyYWpp
dmEpDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgNDoxMiBQTQ0KPiA+
PiBUbzogQmVybmllIFZvbHogKHZvbHopDQo+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBT
dWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVt
IFdHTEMNCj4gPj4NCj4gPg0KPiA+PiBJIGFncmVlIHRoYXQgc3RhcnRpbmcgREhDUHY2IHdpdGhv
dXQgYW4gUkEgaXMgcG9pbnRsZXNzIC8gdXNlbGVzcy4gQW5kIHRoZQ0KPiA+PiBkcmFmdCBzaG91
bGQganVzdCBzdGF0ZSB0aGF0Lg0KPiA+Pg0KPiA+PiBCdXQgaWYgdGhlIGRyYWZ0IGlzIHJlZmVy
cmluZyB0byBhbnkgZXhpc3RpbmcgUkZDLCB0aGVuIGl0IGlzIHJlYXNvbmFibGUNCj4gPj4gdG8g
c2F5IHRoZSBiZWhhdmlvciBub3QgYmVpbmcgc3BlY2lmaWVkIChvciB1bmNsZWFyKS4gSnVzdCBh
dm9pZCBoYWlyLQ0KPiA+PiBzcGxpdHRpbmcuDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gUmFq
aXYgQXNhdGkNCj4gPj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwgQ2lzY28gU2VydmljZXMNCj4g
Pj4NCj4gPj4NCj4gPj4gPiBPbiBGZWIgMjQsIDIwMTYsIGF0IDE6MzMgUE0sIEJlcm5pZSBWb2x6
ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4gQ1BFIGFyZSBi
b3RoIGhvc3RzIGFuZCByb3V0ZXJzLiBUaGVpciBzcGVjaWZpY2F0aW9uIGlzIGRlZmluZWQgaW4g
UkZDDQo+ID4+ID4gNzA4NC4NCj4gPj4gPg0KPiA+PiA+IFdpdGggcmVzcGVjdCB0byB0aGUgaG9z
dCAoYWRkcmVzcyBhc3NpZ25tZW50KSBzaWRlOg0KPiA+PiA+DQo+ID4+ID4gICBXQUEtNjogICBJ
ZiB0aGUgSVB2NiBDRSByb3V0ZXIgcmVjZWl2ZXMgYSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudA0KPiA+
PiA+ICAgICAgICAgICAgbWVzc2FnZSAoZGVzY3JpYmVkIGluIFtSRkM0ODYxXSkgd2l0aCB0aGUg
TSBmbGFnIHNldCB0byAxLA0KPiA+PiA+ICAgICAgICAgICAgdGhlIElQdjYgQ0Ugcm91dGVyIE1V
U1QgZG8gREhDUHY2IGFkZHJlc3MgYXNzaWdubWVudA0KPiA+PiA+ICAgICAgICAgICAgKHJlcXVl
c3QgYW4gSUFfTkEgb3B0aW9uKS4NCj4gPj4gPg0KPiA+PiA+IFdpdGggcmVzcGVjdCB0byB0aGUg
cm91dGVyIChwcmVmaXggZGVsZWdhdGlvbikgc2lkZToNCj4gPj4gPg0KPiA+PiA+ICAgV1BELTQ6
ICBCeSBkZWZhdWx0LCB0aGUgSVB2NiBDRSByb3V0ZXIgTVVTVCBpbml0aWF0ZSBESENQdjYgcHJl
Zml4DQo+ID4+ID4gICAgICAgICAgIGRlbGVnYXRpb24gd2hlbiBlaXRoZXIgdGhlIE0gb3IgTyBm
bGFncyBhcmUgc2V0IHRvIDEgaW4gYQ0KPiA+PiA+ICAgICAgICAgICByZWNlaXZlZCBSb3V0ZXIg
QWR2ZXJ0aXNlbWVudCAoUkEpIG1lc3NhZ2UuICBCZWhhdmlvciBvZiB0aGUNCj4gPj4gPiAgICAg
ICAgICAgQ0Ugcm91dGVyIHRvIHVzZSBESENQdjYgcHJlZml4IGRlbGVnYXRpb24gd2hlbiB0aGUg
Q0Ugcm91dGVyDQo+ID4+ID4gICAgICAgICAgIGhhcyBub3QgcmVjZWl2ZWQgYW55IFJBIG9yIHJl
Y2VpdmVkIGFuIFJBIHdpdGggdGhlIE0gYW5kIHRoZQ0KPiA+PiA+ICAgICAgICAgICBPIGJpdHMg
c2V0IHRvIHplcm8gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50Lg0KPiA+PiA+DQo+
ID4+ID4gVGhvdWdoIGZvciB0aGUgUEQgY2FzZSwgaXQgZG9lc24ndCBzYXkgd2hhdCB0byBkbyBp
ZiB0aGVyZSBpcyBubyBSQSAob3V0DQo+ID4+ID4gb2Ygc2NvcGUhKS4NCj4gPj4gPg0KPiA+PiA+
IFNvLCBmb3IgdGhlIENQRSAod2l0aCByZXNwZWN0IHRvIHRoZSBob3N0IHNpZGUsIHdoaWNoIGlz
IHdoYXQNCj4gPj4gPiBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtIGlzIGFi
b3V0KSwgaXQgYWdyZWVzIHdpdGgNCj4gPj4gTG9yZW56bydzIGFuYWx5c2lzLg0KPiA+PiA+DQo+
ID4+ID4gLSBCZXJuaWUNCj4gPj4gPg0KPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4+ID4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YNCj4gPj4gPiBzdGhhdWdAbmV0aGVscC5ubw0KPiA+PiA+IFNlbnQ6IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMjQsIDIwMTYgNDowMCBBTQ0KPiA+PiA+IFRvOiBsb3JlbnpvQGdvb2dsZS5j
b20NCj4gPj4gPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPj4gPiBTdWJqZWN0OiBSZTogW3Y2b3Bz
XSBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtIFdHTEMNCj4gPj4gPg0KPiA+
PiA+PiAxLiBJIGRpc2FncmVlIHdpdGggdGhlIHN0YXRlbWVudCAiSXQgaXMgdW5jbGVhciB3aGV0
aGVyIGhvc3RzIHNob3VsZA0KPiA+PiA+PiBpbml0aWF0ZSBESENQdjYgYnkgdGhlbXNlbHZlcyBp
ZiB0aGVyZSBhcmUgbm8gUkFzIGF0IGFsbC4iIFRoZXJlIGlzDQo+ID4+ID4+IG5vdCByZWFsbHkg
cG9pbnQgaW4gdXNpbmcgREhDUHY2IHdpdGhvdXQgUkFzLiBUaGlzIGlzIGJlY2F1c2UgREhDUHY2
DQo+ID4+ID4+IGRvZXMgbm90IGNvbmZpZ3VyZSBwcmVmaXhlcywgb25seSBhZGRyZXNzZXMgd2l0
aG91dCBwcmVmaXggbGVuZ3RocywNCj4gPj4gPj4gYW5kIHRoZXJlZm9yZSBhbiBhZGRyZXNzIGFz
c2lnbmVkIGJ5IERIQ1B2NiBlaXRoZXIgaGFzIG5vIHByZWZpeA0KPiA+PiA+PiBsZW5ndGggb3Ig
YSBwcmVmaXggbGVuZ3RoIG9mIC8xMjguIFNlZSBkaGNwdjZicyB0aWNrZXQgNjg6DQo+ID4+ID4+
IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2RoY3B2NmJpcy90aWNrZXQvNjgNCj4g
Pj4gPj4NCj4gPj4gPj4gU28gc3RhcnRpbmcgREhDUHY2IHdpdGhvdXQgYW4gUkEgaXMgcG9pbnRs
ZXNzIGJlY2F1c2UgZXZlbiBpZiB5b3UgZ2V0DQo+ID4+ID4+IGFuIGFkZHJlc3MsIHlvdSBjYW4n
dCB1c2UgdG8gdGFsayB0byBhbnl0aGluZy4gVGh1cywgSSBkb24ndCB0aGluaw0KPiA+PiA+PiB0
aGVyZSBpcyBhbnkgYW1iaWd1aXR5IGhlcmUsIHNpbmNlIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmVz
IGRvZXNuJ3QNCj4gPj4gPj4gbWFrZSBzZW5zZS4gVGhhdCBzYWlkLCBpZiB3ZSBkbyBzdGlsbCB3
YW50IHRvIHNheSB0aGlzIGlzIGFtYmlndW91cywNCj4gPj4gPj4gdGhlbiB3ZSBzaG91bGQgcmVw
bGFjZSAiYW1iaWd1b3VzIiB3aXRoICJ1bnNwZWNpZmllZCIsIGFuZCBhZGQNCj4gPj4gPj4gc29t
ZXRoaW5nIGFib3V0IHRoZSBmYWN0IHRoYXQNCj4gPj4gPj4gREhDUHY2IHdpdGhvdXQgUkFzIGlz
IHVzZWxlc3MsIHN1Y2ggYXM6DQo+ID4+ID4NCj4gPj4gPiBJIGNhbiBhYnNvbHV0ZWx5IHNlZSB0
aGlzIHBvaW50IG9mIHZpZXcuIE9uIHRoZSBvdGhlciBoYW5kIC0gZ2l2ZW4gdGhhdA0KPiA+PiA+
IHRoZSBNLWJpdCBpcyBvbmx5IGEgaGludDogSWYgSSB3ZXJlIGEgQ1BFIG1hbnVmYWN0dXJlciwg
SSBtaWdodA0KPiA+PiBmaW5kIGl0IHBlcmZlY3RseSByYXRpb25hbCB0byAqYWx3YXlzKiBzdGFy
dCBESENQdjYgKGZvciBzaW1wbGljaXR5J3MNCj4gPj4gc2FrZSkuIEkgYmVsaWV2ZSB3ZSd2ZSBz
ZWVuIG1vcmUgdGhhbiBvbmUgQ1BFIG1vZGVsIGRvaW5nIGV4YWN0bHkNCj4gPj4gdGhhdC4NCj4g
Pj4gPg0KPiA+PiA+IFN0ZWluYXIgSGF1ZywgQVMyMTE2DQo+ID4+ID4NCj4gPj4gPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IHY2b3BzIG1h
aWxpbmcgbGlzdA0KPiA+PiA+IHY2b3BzQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiB2Nm9wcyBtYWlsaW5n
IGxpc3QNCj4gPj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+
IHY2b3BzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdjZvcHMNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9y
Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0K
PiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCg0K


From nobody Thu Feb 25 15:32:36 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963951B37B0 for ; Thu, 25 Feb 2016 15:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB_Mgh_wEgmz for ; Thu, 25 Feb 2016 15:32:33 -0800 (PST)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 B9EB71B37AF for ; Thu, 25 Feb 2016 15:32:33 -0800 (PST)
Received: by mail-pa0-x233.google.com with SMTP id fl4so40061785pad.0 for ; Thu, 25 Feb 2016 15:32:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=QmnsSGgTiuBmoQkXWqFlLwn4r9NvtfdIbF9CX83vySE=; b=xUnUGUOXPQnzo8C9KwPphUSnUKROIvVcaxjkEaPoqnn327E586ZZv46cU5Ary6k37e hb9f/MVr7PxKL9RVKOIY5pBKvaIVC7LNc2B8UGolNLj2MA4BYJkCW1wMNbMH4mUVQy34 TiNt5jZIQubd5hLQwCRnq9SLHdEU5vt1+9DCcp98bidQ6zyMraLkpjQoa2ZvCMHeE/Y2 MeDCe6RwQONc5e6qC48dxwBrI1dr0KCpr2FsbeI8hR/WAq3FkPwkdxLk0K2BIC7YsyMf yHW6lmw6QWz6es+D9D4lA8KR1+dRFEsXB+jxJwllNzMetyPaF6jlaec6wldt7nc+eqEi drdw==
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 :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QmnsSGgTiuBmoQkXWqFlLwn4r9NvtfdIbF9CX83vySE=; b=LVG3KGjQjCyQZ9qbKZmZDZfCOet8XHEtrIHlHe/hRiJGVGP952jz29scyb20m1qpeq M5hs2Y1I8uYoGuqxEV90Wjk615ZGkX3K0QnNQekBygun+OsFIkF/Xrs9LfdXsMFktxmJ mA+WDMtPXLOuc+EEE5jeK26zsoihvc/4KoP7UwM6VSXumVlqbZ6cDtIkkShqW+Ek1JsM X0rA7fuviGOFMmWiad4XNdTMYqDzRaxJeeDowezKUWl2eTNUgImquJgF0vbMP/axSvHA huqk2AuLrwtBgOgXXEaxtcKx7lYpjVj0dt+9W66+SkPZZS1datqbd0qMp9uxJRDbhXea yPdg==
X-Gm-Message-State: AG10YOQef7GtW86ixamqTYvf56/4yD5mgdFJSfg7F08yfLk+GeajcNsWzwEEpgsFPbhe1A==
X-Received: by 10.66.90.199 with SMTP id by7mr66775745pab.113.1456443153352; Thu, 25 Feb 2016 15:32:33 -0800 (PST)
Received: from [10.16.75.156] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id qy7sm14578401pab.34.2016.02.25.15.32.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 15:32:32 -0800 (PST)
To: otroan@employees.org
References:  <20160221225835.779c0de7@envy.w5.y.home> <82996F65-AE3E-4C8E-A144-5828503B3D16@employees.org> <56CB7C3C.9090506@gmail.com> <0A26AB2A-36C3-44F4-95CF-A8E11E57A6D3@employees.org> <56CCAE79.6040506@gmail.com> <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org>
From: Jouni Korhonen 
Message-ID: <56CF8F10.2090509@gmail.com>
Date: Thu, 25 Feb 2016 15:32:32 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <05D26604-63EA-4F86-BC88-D5ABE10B1575@employees.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] p2p links without ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 23:32:35 -0000

2/23/2016, 11:24 AM, otroan@employees.org kirjoitti:
> Jouni,
>
>>>>>> Ťp2p links without NDť sounds like a rather shoddy implementation to
>>>>>> me. Even though you won't need ND to discover link-layer addreses on
>>>>>> p2p links, you're still going to need it for DAD, NUD, SLAAC, default
>>>>>> router discovery, more-specific routes discovery, RDNSS discovery, etc.
>>>>>> etc. etc.
>>>>>
>>>>> at least with regards to the implementations I'm familiar with, that means no ND addreans we don't do NUD.
>>>>ss resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication that also me
>>>> NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still usable as IP layer reachability detection of your next hop, right.
>>>
>>> yes, but typically in this case the router wouldn't keep state for its neighbours. no state no NUD.
>>
>> The case I was after here is where the p2p link is up (thus no link-specific information to indicate anything is wrong) but the next hop IP layer is dead and the upper layer traffic one is using does not provide "positive reachability confirmation". Eventually failing NUD determines the next hop is unreachable. Not that this would fix the situation but atleast the stack now knows the (only) next hop it has to send all its packets through is unreachable..
>
> router - router: BFD, routing protocol keepalives

Agree, though BFD or routing protocols cannot be universally assumed to 
be on all router - router links.

> router - host: host has state (from router discovery) and can do NUD if it cares.

Right, this is acually case what I mainly had in mind.

- Jouni

> (assuming no L2 keepalives).
>
> cheers,
> Ole
>


From nobody Fri Feb 26 14:18:18 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF301B31A0 for ; Fri, 26 Feb 2016 14:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pra67pzjm5uc for ; Fri, 26 Feb 2016 14:18:14 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 6C52D1B319F for ; Fri, 26 Feb 2016 14:18:14 -0800 (PST)
Received: by mail-ig0-x232.google.com with SMTP id y8so47546936igp.0 for ; Fri, 26 Feb 2016 14:18:14 -0800 (PST)
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=pcP9mt1t1AQPJKBFUlkSryibVp3Fba13qtaYXWIXbx8=; b=qSHiQkQ7tfxcndPyxXV1EQCQHDOdyp4r2mWAIl25aTJ71UUg7kjA3NmWneN75OIZJp Up6qKh4wDMGhYAGNbe6+o5x78sf7haBDVYRrYcH1CJOcOYzbyNLMPFCVWTDowxVlVlcC ZfhLoT2dQkgeXGxeoxxA7/KVfeek0qlJhnn/mZidivjaHF2pDVZ9B4iqQZmUZcrAQjWq YSZ0Ql2B756KxhSLJXlvDdnoWyBceB4dF4TxnnXVfmfiGe8Yt0WMSySSInXuZmP7qRGS 44fgTaTxQw16EyhPGLXiL+ZwY6p3Ddp5Wqxc0bJtwWfz8NmMg6ERpSMxrqaXchIYuF8W aEVg==
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=pcP9mt1t1AQPJKBFUlkSryibVp3Fba13qtaYXWIXbx8=; b=JpupnOvMSJrGd2Wm2NuV300uF+7UaVtXh+3jpIbe8UmFCZXdnEv89Pri7MfIH02jh0 7LPKC1RlN35wM6RyVIrrkHmfo5/KO+nGDL10VGSP7xVw5axReZYdX/M7XeIbxb2OntEb ORxq3m6YEWXqSUsk0wJmUS2oOBqFbtm2t5Ui1/y6jZT1e+QPFTZ+ignfv2HdZ8Ljriiy B/v+35vwz8+y+15vqdrS0ftk44O/Rv7Q/eVEkTLi23Gt7RYcQVwsPdE09Eyt9rKPTJ1V 9ceoLwZhocqFsIC1u7RTCoVeQiWrDgl2bScIX9Yb5LKSCjKCBw7QscEDHlE0ERQgtfPc 38OA==
X-Gm-Message-State: AD7BkJK3cG34E2UoSkinXj9Ie8VLHCMhYcbV7ULhops0B74ESAHgNB38sDzrt0idFsUHZaQ0KqsJmLAXG7OmcQ==
MIME-Version: 1.0
X-Received: by 10.50.85.6 with SMTP id d6mr198922igz.41.1456525093714; Fri, 26 Feb 2016 14:18:13 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Fri, 26 Feb 2016 14:18:13 -0800 (PST)
In-Reply-To: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>
Date: Fri, 26 Feb 2016 14:18:13 -0800
X-Google-Sender-Auth: wXxGJ4huhHA79TmCFDDI7ZeGVWc
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: "Fred Baker (fred)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 22:18:17 -0000

On Sun, Feb 21, 2016 at 11:00 AM,   wrote:

> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.

I've read the 06 version of the draft.  I don't think this document is
ready for publication, yet.  (I'm feeling dejavu of repeating the same
comments I made many months ago...) while I see potential of this doc
to be useful, it seems to have many issues in its current form such as
technically inaccurate (to me at least) statements or the mixture of
possibly useful information and very minor and operationally
unrealistic/hypothetical nit picking.  IMO, publishing it with these
issues would rather introduce confusion and/or misunderstanding.  More
specific comments follow.

- General: it's true that there's spec ambiguity regarding the M/O
  flags.  I also see different implementations can behave differently,
  possibly because of such ambiguity.  But simply because there's some
  ambiguity or behavior difference doesn't immediately mean these
  should be officially described in a document like an RFC (whose
  publication cost is expensive).  IMO, the ambiguity and/or behavior
  difference must lead to actual operational issues that matter in
  practice.  In that sense most of the points described in this
  document seem to be too minor (see specific discussions below).  I
  see at least a couple of points that may have real operational
  impact, such as Divergence 1-3 in Section 4.1 (which would make
  coexistence of SLAAC and DHCPv6-based address allocation impossible
  for some implementations, and I heard some operators want this type
  of operation).  My personal suggestion is to focus on such real
  issues, removing all minor points.  The resulting document might
  become very thin, but could be much more useful and readable.

- Abstract

   [...]  These are
   the M, O, and A flags, which by definition are advisory, not
   prescriptive.

  I don't think the A flag is "advisory", and I believe it's pretty
  clear from the specification (even if there might be an
  implementation that misunderstands it).  Will discuss this in more
  detail below.

- Section 1

   (A flag is
   also advisory by definition in standard, but it is quite prescriptive
   in implementations according to the test results in the appendix.)

  I'd like to know exactly what "advisory by definition in standard"
  means since IMO A flag is perfectly "prescriptive".  Section 5.5 of
  RFC4862 states:

   [...] Creation of
   global addresses as described in this section SHOULD be locally
   configurable.  However, the processing described below MUST be
   enabled by default.

  and subsection 5.5.3 specifies:

    a)  If the Autonomous flag is not set, silently ignore the Prefix
      Information option.

  and how to configure a global address from the prefix (the
  corresponding PIO should have the A flag on because of "a)").

  And, in fact, the draft itself seems to admit it's actually
  prescriptive and well understood by implementors accordingly.

- Section 3, item 1)

      [...]  More specifically, it is
      unclear whether RA (with M=1) is required to trigger DHCPv6; in
      other words, It is unclear whether hosts should initiate DHCPv6 by
      themselves if there are no RAs at all.

  The latter half of this looks a bit awkward.  "in other words"
  suggests rephrasing the same thing, but "whether hosts should
  initiate DHCPv6 without RA" is not really the same thing as
  "whether RA (with M=1) is required for DHCPv6".  perhaps "for
  example" or "in particular" might be a better phrase here.

  And, one minor nit: s/It is/it is/

- Section 3, item 3)

         When flags are in transition, e.g. the host is already SLAAC-
         configured, then M flag changes from FALSE to TRUE, it is not
         clear whether the host should start DHCPv6 or not; or vise
         versa, the host is already configured by both SLAAC and DHCPv6,
         then M flag change from TRUE to FALSE, it is also not clear
         whether the host should turn DHCPv6 off or not.

  I don't understand why we need the condition of "the host is already
  SLAAC-configured".  With or without, it's already (intentionally)
  clear per RFC4861/4862 whether the host should start DHCPv6 or not.
  Same for the latter part (regarding SLAAC).

  I'd also note that the very original intent of RFC2461/2462 was
  clear on this point: a change of M flag from FALSE to TRUE means the
  host should start DHCPv6; a change of M flag from TRUE to FALSE
  should not affect ongoing DHCPv6 sessions.  While it's true that
  RFC4861/4862 are (again, intentionally) silent on these, I'd say if
  an implementor actually wants to use this flag it's most natural to
  follow what 2461/2462 stated.

- Section 3, item 3)

         When one address configuration method is off, that is, the A
         flag or M flag changes from TRUE to FALSE, it is not clear
         whether one host should immediately release the corresponding
         address or just retain it until the lifetime expires.

  At least for the A flag, I'd say it's pretty obvious that host MUST
  NOT do that.  Otherwise the two-hour rule introduced in RFC4862
  would simply be pointless; an on-link attacker could easily force
  hosts to invalidate addresses by sending forged RAs with the PIO
  clearing the A flag.  True, it's not explicitly documented in the
  RFCs, but that doesn't immediately mean "it's not clear".  Is there
  actually an implementation that invalidates SLAAC-configured address
  on receiving a corresponding PIO with the A flag being 0?

- Section 3, item 4)

      But for A flag and O flag, ambiguity could possibly happen.  For
      example, when A is FALSE (when M is also FALSE) and O is TRUE, it
      is not clear whether the host should initiate a stand-alone
      stateless DHCPv6 session.

  Personally, I would consider a mere implementation defect.  I don't
  think any of the spec ambiguity can lead to this awkward behavior.
  For some kind of information document especially in the O&M area, it
  might note there is such a broken implementation.  But in this
  particular case I don't see it very useful in a practical sense
  either, since if both A and M are FALSE this network is almost
  unusable anyway.  This topic rather seems to be an artificial
  nitpicking.  (I vaguely recall we discussed this point on an earlier
  version of the draft, but I don't remember the conclusion, if any)

- Section 4.2, Divergence 2-1: same as the previous point.

- Section 4.2, Divergence 2-2

         1) Getting RDNSS from both the RAs and the DHCPv6 server, and
         the RDNSS obtained from the router has a higher priority.

  This doesn't seem to be very relevant to the main subject of this
  draft, i.e, it doesn't seem to be related to the M/O/A flags.  And,
  as this draft itself points out, RFC6106 (and its bis) clearly
  specifies the precedence on this point; this implementation is
  simply and clearly broken in terms of the spec conformance, and I
  don't see much value in pointing it out in this document.

- Section 4.2, Divergence 2-2

  It's not clear to me whether this is really about DNS
  configuration.  Isn't it just a variant of Divergence 1-3 of Section
  4.1, i.e., some implementation doesn't start DHCPv6 if it
  receives/has received PIO with A being TRUE?

- Section 5.2

   Ideally, these steps could be initiated by multicasting RA messages
   onto the link that is being renumbered.  Sadly, this is not possible,
   because the RA messages may elicit a different behavior from each
   host.

  This description is vague to me.  Can the problem(s) be more
  specific?

- Section 6

  Overall, I don't understand how this is specific to the main subject
  of this document (unclear specification of M/O flags, and some
  deviant implementation behavior regarding these, sometimes also
  related to the value of the A flag).  The security considerations in
  this section generally seem to be applicable with or without the
  M/O/A issues.  That is, an on-link attacker can do many bad things
  when RA or DHCPv6 isn't protected.

- Section 6

   If an attacker wants to perform MiTM (Man in The Middle) using a
   rogue DNS while legitimates RAs with the O flag set are sent to
   enforce the use of a DHCPv6 server, the attacker can spoof RAs with
   the same settings with the legitimate prefix (in order to remain
   undetectable) but advertising the attacker's DNS using RDNSS.

  I'm not sure if this is explicitly worth noting in the context of
  this document (see also the previous general point).  This type of
  attacker could also spoof DHCPv6 responses, so with or without the
  ambiguity of the RA flags and implementation variation, the attacker
  can force victim hosts to use forged RDNSS.

- Section 6

   Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack
   using a rogue DNS information either, since the one obtained by the
   RAs of the first router has a higher priority.

  I don't understand this sentence (btw, I guess s/explored/exploited/).

- Appendix: to be honest I've not closely read the appendices.  But
  I guess that could actually be a point to be addressed: the
  information provided here seemed to be too unorganized, just listing
  random things, possibly including many duplicates.  I hope this
  section will be more well-organized and readable.  Also, even though
  I understand it doesn't have to be a comprehensive implementation
  list, I would consider it biased (and even possibly misleading) that
  it doesn't include any of open source BSD variants, while it talks
  about result of multiple flavors of Linux.  BSDs are also widely
  deployed IPv6 implementation developed differently from Linux, and
  anyone can examine the behavior at source-code level (like Linux,
  but not like Windows or MacOS or iOS).  If we keep this appendix,
  I'd strongly suggest including at least one open-source BSD variant.

--
JINMEI, Tatuya


From nobody Sat Feb 27 20:29:15 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE71B31EF for ; Sat, 27 Feb 2016 20:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level: 
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpouMs54fJCm for ; Sat, 27 Feb 2016 20:29:13 -0800 (PST)
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 25CDA1B31EE for ; Sat, 27 Feb 2016 20:29:13 -0800 (PST)
Received: from mb-2.local (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1S4T7Pv020699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Feb 2016 04:29:08 GMT (envelope-from joelja@bogus.com)
To: Lorenzo Colitti , Fernando Gont 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  <56CEB3F2.8060101@si6networks.com> 
From: joel jaeggli 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Sat, 27 Feb 2016 20:29:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ir2UucKLbGpev9TCOij5GpUNurjGU7Eou"
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 04:29:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ir2UucKLbGpev9TCOij5GpUNurjGU7Eou
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2/25/16 12:04 AM, Lorenzo Colitti wrote:
> On Thu, Feb 25, 2016 at 4:57 PM, Fernando Gont  > wrote:
>=20
>     > So starting DHCPv6 without an RA is pointless because even if you=
 get an
>     > address, you can't use to talk to anything.
>=20
>     Yes, we should close that gap. Sad that a religious war essentially=
 ends
>     up with *two* mandatory protocols. Because in many scenarios, you
>     need both.
>=20
>=20
> Well, that's not something we can do in this WG.
> =20
>=20
>     > 3. Where the draft says "It could be reasonably deduced that M fl=
ag
>     > should be independent from A flag" - again, the text should menti=
on that
>     > for a client following draft-ietf-dhc-anonymity-profile, that's n=
ot true.
>=20
>     Which again brings the question of why such document is not updatin=
g the
>     corresponding spec.
>=20
>=20
> I think you'll have to take that up with the IESG at this point.
> Obviously they took the position that doing so was not necessary; I
> suspect that position is far from conteroversial.
> =20
>=20
>     > 7. The draft makes no mention of Android. Perhaps it should say t=
hat
>     > Android does not have this problem because it does not implement =
DHCPv6?
>=20
>     That's kind of misleading ;-).  That could be read to mean that it'=
s
>     actually a good thing that android does not support ipv6.
>     (FWIW, Nodes that don't do v6 don't have this problem, either.)
>=20
>=20
> We can say whatever we can get WG consensus on, but I think we have to
> say something about Android, because there are more Android devices tha=
n
> most of the platforms that you do say something about.

implemntors are under no obligation to do anything in particular by the
IETF. if a citation of differences is useful then by all means add it.


>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20



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

iEYEARECAAYFAlbSd44ACgkQ8AA1q7Z/VrJISQCfYMfMBrJwavcsj25IuVV1VpdA
WnAAni/Pz4IMQcVm7YD+RVY7icGvL+KY
=3k5k
-----END PGP SIGNATURE-----

--Ir2UucKLbGpev9TCOij5GpUNurjGU7Eou--


From nobody Sat Feb 27 20:58:37 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6DD1A1A4D for ; Sat, 27 Feb 2016 20:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y8cOAcziGjG for ; Sat, 27 Feb 2016 20:58:35 -0800 (PST)
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 68C1D1A1A4C for ; Sat, 27 Feb 2016 20:58:35 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id k196so109090238vka.0 for ; Sat, 27 Feb 2016 20:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=6ZZ3PPUU19u3LwtMNx4j7IxGYCVmnfiPDk+dN8FMHu4=; b=aEFWwwtL96dxPEnxodb+4auojG+dSHDpog23lshoyNPASpoH4/G5iLSGXSvlX9kcRq 9BVqadvolE8N+XppGJCmf4Eqot8P6Lho3Hh7+CA33nEeJcyOInIrXEzWMvHTpnELGIib S6+V3wGoiIJ+eJ2IzoYXraSrRpKZjbokSr7erGbAi5twO1gsAtMjbBCBF5gZAkM49SMP W/kpfx+A9VLZTMWrYDz89YnTwq4xRMsXHHKslYcZKPaB/3D5sJL+0PeWEaS4OFY2BnRX UNWyfdkzhqsUQenI81SLFNSL41y35yrbMMJIoaaPnwTxM8oTqfLo5uHairjqukw7cqQd SqKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6ZZ3PPUU19u3LwtMNx4j7IxGYCVmnfiPDk+dN8FMHu4=; b=TWhw357g81hMv+F4XehMqijAdKcMY077HjGrKJoLROoVy5yS1TyX3gwvqivuAlZKCm 3LYCxECQBtWUeRqxUTkDv7mjqejRzybA3Zhrq6dC95xmuVy6Ucvem3Ohs7qHN5Gsp/22 89NDZCmN+IZf0Z/Ywdf+F80YzJf+VzhBdCd6+lwGTwmTJ7GGljWDycRGA9XV6jPPuXX7 z6P9DIZGhNk1ksaYj3ize9KpmRY/uEs3Uh3i5YRj/Ssci9rHGErvGXMKkUGT309Vnfja BqvtI0nlodLP1GD/JnFbZ2nBhQDwqJSuXAml7tA+EUEqcSXJoHB/EUadGKuZYQsi8QW0 1mUQ==
X-Gm-Message-State: AD7BkJJZPeHTQcnReAgsoVPjY7KDLReAbWEk786yPMIDZVrT67XGT6puDuZJ37ghGXip4w4FdgPp4B3xQu+AZQ==
X-Received: by 10.31.128.82 with SMTP id b79mr6931906vkd.47.1456635514546; Sat, 27 Feb 2016 20:58:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.5.68 with HTTP; Sat, 27 Feb 2016 20:58:05 -0800 (PST)
From: Mark Smith 
Date: Sun, 28 Feb 2016 15:58:05 +1100
Message-ID: 
To: v6ops list 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [v6ops] "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership" -03 version
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 04:58:36 -0000

Hi,

New version with some additions based on Ray Hunter's feedback. Review
and comments much appreciated.

Thanks very much,
Mark.


---------- Forwarded message ----------
From:  
Date: 28 February 2016 at 15:54
Subject: New Version Notification for
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02.txt
To: "markzzzsmith+ietf-dt@gmail.com" 



A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
Revision:       02
Title:          Further Mitigating Router ND Cache Exhaustion DoS
Attacks Using Solicited-Node Group Membership
Document date:  2016-02-27
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
Htmlized:
https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02

Abstract:
   For each of their IPv6 unicast or anycast addresses, nodes join a
   Solicited-Node multicast group, formed using the lower 24 bits of the
   address.  This Solicited-Node group membership could be used by
   routers to further mitigate a Neighbor Discovery cache Denial of
   Service attack.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From nobody Sun Feb 28 16:32:58 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE221ACEC9 for ; Sun, 28 Feb 2016 16:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.084
X-Spam-Level: 
X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA6kgMIaXcpq for ; Sun, 28 Feb 2016 16:32:55 -0800 (PST)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 2CC9D1ACEC1 for ; Sun, 28 Feb 2016 16:32:55 -0800 (PST)
Received: by mail-yk0-x22f.google.com with SMTP id r207so57086608ykd.2 for ; Sun, 28 Feb 2016 16:32:55 -0800 (PST)
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=RF2ZyCef+Yr4W1Kv8Xkj3srZcxZrGdreIbGgck7MH9M=; b=XZ+HY4qxRMEK+R50Pjs6JwdptK9Wj8pOWo48iFOi4VekpJitwFMcW4gMjD7JYPvWSG RGb9Shzbmtj3giX3kxGalSj9XMGhsVrGpHNsvn3wS+wSs+W5Aqmv+AvB+PfUkcgji1Yt 2xF3zO4o5SaNOsd8j6Vz/Snfds4TnGN8Qm3CN9GogwMT4uDjWTveB6pWesM09c/zakV3 Sb3ohYgNF8g4NLQVNLb8bk6+kCpBCBQSZ1sWuVjw3NjmvkbtYIb+hZLHvyimJrbahyys y4jWa6IMS6xmHCS74xJxP0+hefU7Z1dXBm/GaIj789bfX36FLLDZl3IhW4+8Cd/yLA0/ 9KUA==
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=RF2ZyCef+Yr4W1Kv8Xkj3srZcxZrGdreIbGgck7MH9M=; b=Fxsh8Z7RCZ2TFxW0rAhv0QcvslkFnst1zfzHUVEVoqCF562ImEimwziyxh+Rhze2/U 2ja5Sxso0l2hfFtw5oSj9rkMZp7WNzMT76tm3uigwiKkPezDw5q4W++IbnaAHYo3oADM FLvS2kwakNNqJTBkyhE9h1pH0GxjEt+Yw3NWf6fh+WkDuZ3T/Urp2vOscQFlwzdRY/7c AUaDiv6rTipbjEfNFG7AVR/ZPeaSki5JHBQMiPpz7pLvAuZ1HNSL0TQgaSMOwSFUxmm4 autyggQl0ph21dFTuNWYUKUqIVwlIWUy/HMjLVQbu0xtvkN0UEHLGHH0ekxsk9esfJXa 9jEA==
X-Gm-Message-State: AD7BkJIea4K1Nea9FzZdHrRN0NwMqLVloihToRaY3Esf9MnmUSVCR+TiAJVn4m0M0MAL0iWBRk2NGzIWbKJpy3H7
X-Received: by 10.37.13.131 with SMTP id 125mr7420154ybn.49.1456705974344; Sun, 28 Feb 2016 16:32:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.19.65 with HTTP; Sun, 28 Feb 2016 16:32:34 -0800 (PST)
In-Reply-To: 
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com> 
From: Lorenzo Colitti 
Date: Mon, 29 Feb 2016 09:32:34 +0900
Message-ID: 
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=001a11c0144a252dc9052cddca93
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 00:32:56 -0000

--001a11c0144a252dc9052cddca93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 27, 2016 at 7:18 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89  wrote:
>
> (I'm feeling dejavu of repeating the same comments I made many months
> ago...)


That's does tend to happen when a document is resubmitted without
substantial changes.

while I see potential of this doc to be useful, it seems to have many
> issues in its current form such as technically inaccurate (to me at least=
)
> statements or the mixture of possibly useful information and very minor a=
nd
> operationally
> unrealistic/hypothetical nit picking.  IMO, publishing it with
> these issues would rather introduce confusion and/or misunderstanding.
> More specific comments follow.
>

What Jinmei said.

More concerningly - as Jinmei points out, these comments were exactly the
same on previous versions of the draft, and nothing was done to address
them. I think this is not the first time, either. It's like a
merry-go-round: the draft gets submitted, gathers the same substantial
objections, goes away, gets resubmitted with minor changes. What's the plan
here? Keep doing that until folks get tired of objecting?

Cheers,
Lorenzo

--001a11c0144a252dc9052cddca93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, Feb 27, 2016 at 7:18 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@=
wide.ad.jp> wrote:
(I'm fee=
ling dejavu of repeating the same=C2=A0comments I made many months ago...)<=
/blockquote>

That's does tend to happen when a docum=
ent is resubmitted without substantial changes.

 while I see potential of this doc=C2=A0to be usefu=
l, it seems to have many issues in its current form such as=C2=A0technicall=
y inaccurate (to me at least) statements or the mixture of=C2=A0possibly us=
eful information and very minor and operationally

unrealistic/hypothetical nit picking.=C2=A0 IMO, publishing it with these=
=C2=A0issues would rather introduce confusion and/or misunderstanding.=C2=
=A0 More=C2=A0specific comments follow.

What Jinmei said.

More concerningly - as Jinmei p=
oints out, these comments were exactly the same on previous versions of the=
 draft, and nothing was done to address them. I think this is not the first=
 time, either. It's like a merry-go-round: the draft gets submitted, ga=
thers the same substantial objections, goes away, gets resubmitted with min=
or changes. What's the plan here? Keep doing that until folks get tired=
 of objecting?

Cheers,
Lorenzo


--001a11c0144a252dc9052cddca93--


From nobody Mon Feb 29 01:32:35 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD201B2EC2 for ; Mon, 29 Feb 2016 01:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.906
X-Spam-Level: 
X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8r5iHyaNzwK for ; Mon, 29 Feb 2016 01:32:28 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036AC1B2EBE for ; Mon, 29 Feb 2016 01:32:26 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFC84982; Mon, 29 Feb 2016 09:32:24 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Feb 2016 09:32:23 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Mon, 29 Feb 2016 17:32:17 +0800
From: "Liubing (Leo)" 
To: Lorenzo Colitti , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
Thread-Index: AQHRbNo4gqEUER8qq0SFTIVdqXX6nZ8+Z1mAgANKMwCAAKD3cA==
Date: Mon, 29 Feb 2016 09:32:16 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BB@nkgeml514-mbx.china.huawei.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.117]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BBnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56D41029.0064, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 02e6a58bbaa8f1c50d61a173e198b23b
Archived-At: 
Cc: "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 09:32:32 -0000

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BBnkgeml514mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTG9yZW56bywNCg0KUmVwbGllcyBpbmxpbmUuDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZv
cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDog
TW9uZGF5LCBGZWJydWFyeSAyOSwgMjAxNiA4OjMzIEFNDQpUbzog56We5piO6YGU5ZOJDQpDYzog
djZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhj
cHY2LXNsYWFjLXByb2JsZW0gV0dMQw0KDQpPbiBTYXQsIEZlYiAyNywgMjAxNiBhdCA3OjE4IEFN
LCDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0bzpqaW5tZWlAd2lkZS5hZC5q
cD4+IHdyb3RlOg0KKEknbSBmZWVsaW5nIGRlamF2dSBvZiByZXBlYXRpbmcgdGhlIHNhbWUgY29t
bWVudHMgSSBtYWRlIG1hbnkgbW9udGhzIGFnby4uLikNCg0KVGhhdCdzIGRvZXMgdGVuZCB0byBo
YXBwZW4gd2hlbiBhIGRvY3VtZW50IGlzIHJlc3VibWl0dGVkIHdpdGhvdXQgc3Vic3RhbnRpYWwg
Y2hhbmdlcy4NCg0Kd2hpbGUgSSBzZWUgcG90ZW50aWFsIG9mIHRoaXMgZG9jIHRvIGJlIHVzZWZ1
bCwgaXQgc2VlbXMgdG8gaGF2ZSBtYW55IGlzc3VlcyBpbiBpdHMgY3VycmVudCBmb3JtIHN1Y2gg
YXMgdGVjaG5pY2FsbHkgaW5hY2N1cmF0ZSAodG8gbWUgYXQgbGVhc3QpIHN0YXRlbWVudHMgb3Ig
dGhlIG1peHR1cmUgb2YgcG9zc2libHkgdXNlZnVsIGluZm9ybWF0aW9uIGFuZCB2ZXJ5IG1pbm9y
IGFuZCBvcGVyYXRpb25hbGx5DQp1bnJlYWxpc3RpYy9oeXBvdGhldGljYWwgbml0IHBpY2tpbmcu
ICBJTU8sIHB1Ymxpc2hpbmcgaXQgd2l0aCB0aGVzZSBpc3N1ZXMgd291bGQgcmF0aGVyIGludHJv
ZHVjZSBjb25mdXNpb24gYW5kL29yIG1pc3VuZGVyc3RhbmRpbmcuICBNb3JlIHNwZWNpZmljIGNv
bW1lbnRzIGZvbGxvdy4NCg0KV2hhdCBKaW5tZWkgc2FpZC4NCg0KTW9yZSBjb25jZXJuaW5nbHkg
LSBhcyBKaW5tZWkgcG9pbnRzIG91dCwgdGhlc2UgY29tbWVudHMgd2VyZSBleGFjdGx5IHRoZSBz
YW1lIG9uIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkcmFmdCwgYW5kIG5vdGhpbmcgd2FzIGRv
bmUgdG8gYWRkcmVzcyB0aGVtLiBJIHRoaW5rIHRoaXMgaXMgbm90IHRoZSBmaXJzdCB0aW1lLCBl
aXRoZXIuIEl0J3MgbGlrZSBhIG1lcnJ5LWdvLXJvdW5kOiB0aGUgZHJhZnQgZ2V0cyBzdWJtaXR0
ZWQsIGdhdGhlcnMgdGhlIHNhbWUgc3Vic3RhbnRpYWwgb2JqZWN0aW9ucywgZ29lcyBhd2F5LCBn
ZXRzIHJlc3VibWl0dGVkIHdpdGggbWlub3IgY2hhbmdlcy4gV2hhdCdzIHRoZSBwbGFuIGhlcmU/
IEtlZXAgZG9pbmcgdGhhdCB1bnRpbCBmb2xrcyBnZXQgdGlyZWQgb2Ygb2JqZWN0aW5nPw0KW0Jp
bmddIFdlIHBhaWQgbG90IG9mIGVmZm9ydCBvbiB0aGUgbGFzdCBjb3VwbGUgb2YgcmV2aXNpb25z
LiBXZSBhZGRlZCBtb3JlIHRlc3RzIG9uIEROUyBjb25maWd1cmF0aW9uIChSRkM2MTA2KSBhcyB3
ZWxsIGFzIG1vcmUgT1NlcywgYW5kIG5vdCBhIGZldyBlZGl0b3JpYWwgd29yay4NCkkgYWRtaXQg
dGhlc2UgcmV2aXNpb24gaXNu4oCZdCB3aGF0IHlvdSBleHBlY3RlZCwgYnV0IHNpbmNlIHlvdXIg
c3VnZ2VzdGlvbiB3YXMgYSBodWdlIG1vZGlmaWNhdGlvbiB0byB0aGUgZHJhZnQsIEnigJltIG5v
dCB2ZXJ5IHN1cmUgaXTigJlzIHNhZmUvZ29vZCB0byBkbyB0aGF0IGFzIGEgV0cgZG9jdW1lbnQu
DQoNCkxldCBtZSBxdW90ZSBzb21lIG9mIHN1YnN0YW50aWFsIG9iamVjdGlvbnMgdGhhdCBtYWRl
IGR1cmluZyB0aGUgbGFzdCBXR0xDIG9mIHRoaXMgZHJhZnQgT2N0LiAyMDE0Lg0KIkluIGl0cyBj
dXJyZW50IGZvcm0sIHRoZSBkZXNjcmliZWQgcHJvYmxlbXMgc2VlbSB0byBiZSB0b28gYXJ0aWZp
Y2lhbCwgaHlwb3RoZXRpY2FsLCBvciBtaW5vciB0byBiZSBpbXBvcnRhbnQgdG8gbWUuICBBbmQg
dGhhdCdzIHdoeSBJIGRpZG4ndCByZWdhcmQgdGhpcyBkcmFmdCBhcyB0aGF0IGltcG9ydGFudC4i
DQoiQWN0dWFsbHksIEkgZ3Vlc3MgdGhlcmUgc2hvdWxkIGJlIG1vcmUgcHJhZ21hdGljIGV4YW1w
bGVzIG9mIG9wZXJhdGlvbmFsIGlzc3VlcyBiZWNhdXNlIG9mIHRoZSBkZXNjcmliZWQgZGl2ZXJn
ZW5jZSBhbmQgSSB3b25kZXIgd2hldGhlciB0aGVzZSBtaW5vciBjYXNlcyBhcmUgcmVhbGx5IHRo
ZSBvbmx5IHRoaW5ncyB3ZSBjYW4gaW1hZ2luZSAoYWx0aG91Z2ggSSBkb24ndCBoYXZlIGEgc3Bl
Y2lmaWMgaWRlYSByaWdodCBub3cpLiAgSWYgdGhlc2Ugc2VjdGlvbnMgY2FuIGJlIHJldmlzZWQg
d2l0aCBtb3JlIGNvbnZpbmNpbmcgZXhhbXBsZXMsIEkgd291bGQgYmUgbW9yZSBzdXBwb3J0aXZl
IGFib3V0IHB1Ymxpc2hpbmcgaXQuIiDigJMgYnkgSmlubWVpDQoiR2l2ZW4gdGhhdCwgaXQgd291
bGQgc2VlbSB0byBtYWtlIG1vcmUgc2Vuc2UgZm9yIHRoaXMgZG9jdW1lbnQgdG8gZm9jdXMgb25s
eSBvbiB0aGUgcmVzdWx0cyBvZiB0aGUgaW52ZXN0aWdhdGlvbiAoaS5lLiwgb25seSB0aGUgYXBw
ZW5kaXgpLCBhbmQgYSBjb25jbHVkaW5nIHN0YXRlbWVudCB0aGF0IG5vdGVzIHRoYXQgaW1wbGVt
ZW50YXRpb25zIGRpZmZlciBpbiB0aGVpciBiZWhhdmlvdXIsIGFuZCB0aGF0IHJlbnVtYmVyaW5n
IGJlaGF2aW91ciBpcyBzdWJzdGFudGlhbGx5IGRpZmZlcmVudC4iIOKAkyBieSB5b3UgKExvcmVu
em8pLg0KDQpJbiB0aGlzIFdHTEMsIEppbm1laSBwcm92aWRlZCBtb3JlIHN1Z2dlc3Rpb246DQri
gJxJbiB0aGF0IHNlbnNlIG1vc3Qgb2YgdGhlIHBvaW50cyBkZXNjcmliZWQgaW4gdGhpcyAgZG9j
dW1lbnQgc2VlbSB0byBiZSB0b28gbWlub3IgKHNlZSBzcGVjaWZpYyBkaXNjdXNzaW9ucyBiZWxv
dykuICBJICBzZWUgYXQgbGVhc3QgYSBjb3VwbGUgb2YgcG9pbnRzIHRoYXQgbWF5IGhhdmUgcmVh
bCBvcGVyYXRpb25hbCAgaW1wYWN0LCBzdWNoIGFzIERpdmVyZ2VuY2UgMS0zIGluIFNlY3Rpb24g
NC4xICh3aGljaCB3b3VsZCBtYWtlICBjb2V4aXN0ZW5jZSBvZiBTTEFBQyBhbmQgREhDUHY2LWJh
c2VkIGFkZHJlc3MgYWxsb2NhdGlvbiBpbXBvc3NpYmxlIGZvciBzb21lIGltcGxlbWVudGF0aW9u
cywgYW5kIEkgaGVhcmQgc29tZSBvcGVyYXRvcnMgd2FudCB0aGlzIHR5cGUgb2Ygb3BlcmF0aW9u
KS4gIE15IHBlcnNvbmFsIHN1Z2dlc3Rpb24gaXMgdG8gZm9jdXMgb24gc3VjaCByZWFsIGlzc3Vl
cywgcmVtb3ZpbmcgYWxsIG1pbm9yIHBvaW50cy4gVGhlIHJlc3VsdGluZyBkb2N1bWVudCBtaWdo
dCBiZWNvbWUgdmVyeSB0aGluLCBidXQgY291bGQgYmUgbXVjaCBtb3JlIHVzZWZ1bCBhbmQgcmVh
ZGFibGUu4oCdDQoNClNheSwgaWYgSSByZXZpc2UgYXMgeW91IGFuZCBKaW5tZWkgc3VnZ2VzdGVk
LCBhIHZlcnkgdGhpbiBkb2N1bWVudCwgSSBjb25jZXJuIGEgYml0IG9uIHRoZSBmb2xsb3dpbmcg
dGhpbmdzOg0KDQotICAgICAgICBUaGUgZGl2ZXJnZW5jZSB3ZSBvYnNlcnZlZCBzaG91bGQgYmUg
b25seSBwYXJ0IG9mIHRoZSBwb3RlbnRpYWwgcHJvYmxlbXMuIFNvLCBpZiB3ZSByZW1vdmUgdGhl
IGFtYmlndWl0eSBhbmFseXNpcyBjb250ZW50LCBwZW9wbGUgbWlnaHQgdGhpbmsgdGhlIGRvY3Vt
ZW50ZWQgcHJvYmxlbXMgYXJlIGFsbCB0aGUgcHJvYmxlbXMuDQoNCi0gICAgICAgIEhvdyBjYW4g
d2UganVkZ2UgdGhlIGN1cnJlbnQgcmVwb3J0ZWQgcHJvYmxlbXMgYXMg4oCcbWlub3LigJ0gaW4g
dGhlIGZ1dHVyZT8gTXkgb3JpZ2luYWwgdGhvdWdodCB3YXMsIGp1c3QgcmVwb3J0ZWQgYWxsIHRo
ZSBwcm9ibGVtcyB3ZSBoYXZlIGZvdW5kLCB3ZSBkb27igJl0IHNlbGVjdCB0aGVtIGZvciB0aGUg
cmVhZGVycy4gUmVhZGVycyB3b3VsZCBkZWNpZGUgYnkgdGhlbXNlbHZlcy4NCg0KSeKAmWQgbGlr
ZSB0byBoZWFyIHlvdXIgZnVydGhlciBvcGluaW9ucy4gVGhhbmtzLg0KDQpCaW5nDQoNCkNoZWVy
cywNCkxvcmVuem8NCg==

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BBnkgeml514mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q
bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/m
lofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAu
TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh
cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTQ4NjA4NTQ4Ow0KCW1zby1saXN0LXR5
cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzA3NDgwNjE0IDM1NzMyNDA5NiA2
NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5
ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjkxNDcwODU1
NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg1OTQy
MDAwMCAtMjk5MzYyMDAwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4
NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy
Z2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJ
bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJv
dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
bGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y
ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVwbGllcyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl
aGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVi
cnVhcnkgMjksIDIwMTYgODozMyBBTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNs
YWFjLXByb2JsZW0gV0dMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPk9uIFNhdCwgRmViIDI3LCAyMDE2IGF0IDc6MTggQU0sIDwvc3Bhbj7n
pZ7mmI7pgZTlk4k8c3BhbiBsYW5nPSJFTi1VUyI+ICZsdDs8YSBocmVmPSJtYWlsdG86amlubWVp
QHdpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj5qaW5tZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj4oSSdtIGZlZWxpbmcgZGVqYXZ1IG9mIHJlcGVhdGluZyB0aGUgc2FtZSZuYnNw
O2NvbW1lbnRzIEkgbWFkZSBtYW55IG1vbnRocyBhZ28uLi4pPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhdCdzIGRvZXMgdGVuZCB0byBoYXBwZW4gd2hlbiBhIGRv
Y3VtZW50IGlzIHJlc3VibWl0dGVkIHdpdGhvdXQgc3Vic3RhbnRpYWwgY2hhbmdlcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndoaWxlIEkg
c2VlIHBvdGVudGlhbCBvZiB0aGlzIGRvYyZuYnNwO3RvIGJlIHVzZWZ1bCwgaXQgc2VlbXMgdG8g
aGF2ZSBtYW55IGlzc3VlcyBpbiBpdHMgY3VycmVudCBmb3JtIHN1Y2ggYXMmbmJzcDt0ZWNobmlj
YWxseSBpbmFjY3VyYXRlICh0byBtZSBhdCBsZWFzdCkgc3RhdGVtZW50cyBvciB0aGUgbWl4dHVy
ZSBvZiZuYnNwO3Bvc3NpYmx5IHVzZWZ1bCBpbmZvcm1hdGlvbiBhbmQgdmVyeSBtaW5vcg0KIGFu
ZCBvcGVyYXRpb25hbGx5PGJyPg0KdW5yZWFsaXN0aWMvaHlwb3RoZXRpY2FsIG5pdCBwaWNraW5n
LiZuYnNwOyBJTU8sIHB1Ymxpc2hpbmcgaXQgd2l0aCB0aGVzZSZuYnNwO2lzc3VlcyB3b3VsZCBy
YXRoZXIgaW50cm9kdWNlIGNvbmZ1c2lvbiBhbmQvb3IgbWlzdW5kZXJzdGFuZGluZy4mbmJzcDsg
TW9yZSZuYnNwO3NwZWNpZmljIGNvbW1lbnRzIGZvbGxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IEppbm1laSBzYWlkLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TW9yZSBjb25jZXJu
aW5nbHkgLSBhcyBKaW5tZWkgcG9pbnRzIG91dCwgdGhlc2UgY29tbWVudHMgd2VyZSBleGFjdGx5
IHRoZSBzYW1lIG9uIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkcmFmdCwgYW5kIG5vdGhpbmcg
d2FzIGRvbmUgdG8gYWRkcmVzcyB0aGVtLiBJIHRoaW5rIHRoaXMgaXMgbm90IHRoZSBmaXJzdCB0
aW1lLCBlaXRoZXIuIEl0J3MgbGlrZSBhIG1lcnJ5LWdvLXJvdW5kOg0KIHRoZSBkcmFmdCBnZXRz
IHN1Ym1pdHRlZCwgZ2F0aGVycyB0aGUgc2FtZSBzdWJzdGFudGlhbCBvYmplY3Rpb25zLCBnb2Vz
IGF3YXksIGdldHMgcmVzdWJtaXR0ZWQgd2l0aCBtaW5vciBjaGFuZ2VzLiBXaGF0J3MgdGhlIHBs
YW4gaGVyZT8gS2VlcCBkb2luZyB0aGF0IHVudGlsIGZvbGtzIGdldCB0aXJlZCBvZiBvYmplY3Rp
bmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gV2Ug
cGFpZCBsb3Qgb2YgZWZmb3J0IG9uIHRoZSBsYXN0IGNvdXBsZSBvZiByZXZpc2lvbnMuIFdlIGFk
ZGVkIG1vcmUgdGVzdHMgb24gRE5TIGNvbmZpZ3VyYXRpb24gKFJGQzYxMDYpIGFzIHdlbGwgYXMg
bW9yZSBPU2VzLCBhbmQgbm90DQogYSBmZXcgZWRpdG9yaWFsIHdvcmsuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFkbWl0IHRoZXNlIHJldmlzaW9uIGlzbuKA
mXQgd2hhdCB5b3UgZXhwZWN0ZWQsIGJ1dCBzaW5jZSB5b3VyIHN1Z2dlc3Rpb24gd2FzIGEgaHVn
ZSBtb2RpZmljYXRpb24gdG8gdGhlIGRyYWZ0LCBJ4oCZbSBub3QgdmVyeSBzdXJlIGl04oCZcyBz
YWZlL2dvb2QNCiB0byBkbyB0aGF0IGFzIGEgV0cgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBxdW90ZSBzb21lIG9mIHN1YnN0YW50aWFsIG9iamVj
dGlvbnMgdGhhdCBtYWRlIGR1cmluZyB0aGUgbGFzdCBXR0xDIG9mIHRoaXMgZHJhZnQgT2N0LiAy
MDE0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7SW4g
aXRzIGN1cnJlbnQgZm9ybSwgdGhlIGRlc2NyaWJlZCBwcm9ibGVtcyBzZWVtIHRvIGJlIHRvbyBh
cnRpZmljaWFsLCBoeXBvdGhldGljYWwsIG9yIG1pbm9yIHRvIGJlIGltcG9ydGFudCB0byBtZS4m
bmJzcDsgQW5kIHRoYXQncyB3aHkgSSBkaWRuJ3QNCiByZWdhcmQgdGhpcyBkcmFmdCBhcyB0aGF0
IGltcG9ydGFudC4mcXVvdDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mcXVvdDtBY3R1YWxseSwgSSBndWVzcyB0aGVyZSBzaG91bGQgYmUgbW9yZSBwcmFnbWF0
aWMgZXhhbXBsZXMgb2Ygb3BlcmF0aW9uYWwgaXNzdWVzIGJlY2F1c2Ugb2YgdGhlIGRlc2NyaWJl
ZCBkaXZlcmdlbmNlIGFuZCBJIHdvbmRlciB3aGV0aGVyIHRoZXNlDQogbWlub3IgY2FzZXMgYXJl
IHJlYWxseSB0aGUgb25seSB0aGluZ3Mgd2UgY2FuIGltYWdpbmUgKGFsdGhvdWdoIEkgZG9uJ3Qg
aGF2ZSBhIHNwZWNpZmljIGlkZWEgcmlnaHQgbm93KS4mbmJzcDsgSWYgdGhlc2Ugc2VjdGlvbnMg
Y2FuIGJlIHJldmlzZWQgd2l0aCBtb3JlIGNvbnZpbmNpbmcgZXhhbXBsZXMsIEkgd291bGQgYmUg
bW9yZSBzdXBwb3J0aXZlIGFib3V0IHB1Ymxpc2hpbmcgaXQuJnF1b3Q7IOKAkyBieSBKaW5tZWk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZxdW90O0dpdmVuIHRo
YXQsIGl0IHdvdWxkIHNlZW0gdG8gbWFrZSBtb3JlIHNlbnNlIGZvciB0aGlzIGRvY3VtZW50IHRv
IGZvY3VzIG9ubHkgb24gdGhlIHJlc3VsdHMgb2YgdGhlIGludmVzdGlnYXRpb24gKGkuZS4sIG9u
bHkgdGhlIGFwcGVuZGl4KSwgYW5kDQogYSBjb25jbHVkaW5nIHN0YXRlbWVudCB0aGF0IG5vdGVz
IHRoYXQgaW1wbGVtZW50YXRpb25zIGRpZmZlciBpbiB0aGVpciBiZWhhdmlvdXIsIGFuZCB0aGF0
IHJlbnVtYmVyaW5nIGJlaGF2aW91ciBpcyBzdWJzdGFudGlhbGx5IGRpZmZlcmVudC4mcXVvdDsg
4oCTIGJ5IHlvdSAoTG9yZW56bykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkluIHRoaXMgV0dMQywgSmlubWVpIHByb3ZpZGVkIG1vcmUgc3VnZ2VzdGlvbjo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnEluIHRoYXQgc2Vuc2UgbW9zdCBv
ZiB0aGUgcG9pbnRzIGRlc2NyaWJlZCBpbiB0aGlzJm5ic3A7IGRvY3VtZW50IHNlZW0gdG8gYmUg
dG9vIG1pbm9yIChzZWUgc3BlY2lmaWMgZGlzY3Vzc2lvbnMgYmVsb3cpLiZuYnNwOyBJJm5ic3A7
IHNlZSBhdCBsZWFzdCBhIGNvdXBsZQ0KIG9mIHBvaW50cyB0aGF0IG1heSBoYXZlIHJlYWwgb3Bl
cmF0aW9uYWwmbmJzcDsgaW1wYWN0LCBzdWNoIGFzIERpdmVyZ2VuY2UgMS0zIGluIFNlY3Rpb24g
NC4xICh3aGljaCB3b3VsZCBtYWtlJm5ic3A7IGNvZXhpc3RlbmNlIG9mIFNMQUFDIGFuZCBESENQ
djYtYmFzZWQgYWRkcmVzcyBhbGxvY2F0aW9uIGltcG9zc2libGUgZm9yIHNvbWUgaW1wbGVtZW50
YXRpb25zLCBhbmQgSSBoZWFyZCBzb21lIG9wZXJhdG9ycyB3YW50IHRoaXMgdHlwZSBvZiBvcGVy
YXRpb24pLiZuYnNwOw0KIE15IHBlcnNvbmFsIHN1Z2dlc3Rpb24gaXMgdG8gZm9jdXMgb24gc3Vj
aCByZWFsIGlzc3VlcywgcmVtb3ZpbmcgYWxsIG1pbm9yIHBvaW50cy4gVGhlIHJlc3VsdGluZyBk
b2N1bWVudCBtaWdodCBiZWNvbWUgdmVyeSB0aGluLCBidXQgY291bGQgYmUgbXVjaCBtb3JlIHVz
ZWZ1bCBhbmQgcmVhZGFibGUu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlNheSwgaWYgSSByZXZpc2UgYXMgeW91IGFuZCBKaW5tZWkgc3VnZ2VzdGVkLCBhIHZlcnkgdGhp
biBkb2N1bWVudCwgSSBjb25jZXJuIGEgYml0IG9uIHRoZSBmb2xsb3dpbmcgdGhpbmdzOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t
PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z
cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlRoZSBkaXZlcmdlbmNlIHdlIG9ic2VydmVkIHNob3VsZCBiZSBvbmx5IHBh
cnQgb2YgdGhlIHBvdGVudGlhbCBwcm9ibGVtcy4gU28sIGlmIHdlIHJlbW92ZSB0aGUgYW1iaWd1
aXR5IGFuYWx5c2lzIGNvbnRlbnQsIHBlb3BsZSBtaWdodA0KIHRoaW5rIHRoZSBkb2N1bWVudGVk
IHByb2JsZW1zIGFyZSBhbGwgdGhlIHByb2JsZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQt
aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRM
aXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w
cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvdyBjYW4g
d2UganVkZ2UgdGhlIGN1cnJlbnQgcmVwb3J0ZWQgcHJvYmxlbXMgYXMg4oCcbWlub3LigJ0gaW4g
dGhlIGZ1dHVyZT8gTXkgb3JpZ2luYWwgdGhvdWdodCB3YXMsIGp1c3QgcmVwb3J0ZWQgYWxsIHRo
ZSBwcm9ibGVtcyB3ZSBoYXZlDQogZm91bmQsIHdlIGRvbuKAmXQgc2VsZWN0IHRoZW0gZm9yIHRo
ZSByZWFkZXJzLiBSZWFkZXJzIHdvdWxkIGRlY2lkZSBieSB0aGVtc2VsdmVzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBsaWtlIHRvIGhlYXIgeW91ciBmdXJ0aGVy
IG9waW5pb25zLiBUaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVy
cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TG9yZW56bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BBnkgeml514mbxchi_--


From nobody Mon Feb 29 11:00:40 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2CB1B3A14 for ; Mon, 29 Feb 2016 11:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUD55dPZiTIj for ; Mon, 29 Feb 2016 11:00:35 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 C5C261B3A18 for ; Mon, 29 Feb 2016 11:00:28 -0800 (PST)
Received: by mail-io0-x234.google.com with SMTP id z135so197695771iof.0 for ; Mon, 29 Feb 2016 11:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=sP6KK5AUsB8pgu0UlFHERAMXLG5HJB8pvGPO5/RXscI=; b=Y+Px3DhEGuMnWcjjOKLSt3zBtLTdYbbY4U2ijbaft3SSMxEBeJt9rgbY8xmXLNNpoc H4WddBczDW8Gfphh67l6eYYUx0TOs66yjm4+TGrz8lAdvMJczL/8ynwelkO8aBEjadOJ 7kmqWRZtoA70ICVyqvbZq8oP+mKRdQew1/JZriwgnB7ZLxqIrpqC+Kw4aO5Mvq2X32yL Aejb+TV6Ohocxy4uwsQLKsxgiVNJtp++6BSPlHMxwzp0ewNzNtG0th7WF56KiuMDMUCX cexOlsDwXBbUoU5qkkvTtgvNk7YGP2du+hZbhU3DbBBHQ8ghUutZsmzsyrmHg3JjfZCR cwcg==
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:content-transfer-encoding; bh=sP6KK5AUsB8pgu0UlFHERAMXLG5HJB8pvGPO5/RXscI=; b=FJ6ZcoOjmGALhA0RbIDh04Uivw+qNy6uHlRDU9OI4jf77wv56mXYYm4A9XAfQLwgg4 nVM58fvXgG0CQGIbte99zatGgBqcZntr3oELpTw0m3eiglKSZVLEymL4CXEAoLn8Akt1 tpKDVrPSS01LAuhBNPtWpUOiqxXrXwA78KW0xQ0/Yistlco5VCKwFXG3S66rK3trRSfr IFlxpDS531PUmtsYhRfnrf33cg32R0zl5RfXK+fXECyaEZzWkzIoSS1seFN1YaD0kOwh zwOPaq8tEHHk0eO+2AbbCMqMTpRUPPFSXMZfEgsNJg5LSuuMOzUGxMdXNKDEkqeu6VwZ cmjg==
X-Gm-Message-State: AG10YOR/hsgyrx942DwxL2G4g+ixenjK9Uul824IylZVvYq9/oMTuRum4fFGzsDcjVCvg1Y0V7Evr4zelDyvRQ==
MIME-Version: 1.0
X-Received: by 10.107.137.142 with SMTP id t14mr23667771ioi.172.1456772428161;  Mon, 29 Feb 2016 11:00:28 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Mon, 29 Feb 2016 11:00:28 -0800 (PST)
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BB@nkgeml514-mbx.china.huawei.com>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>   <8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BB@nkgeml514-mbx.china.huawei.com>
Date: Mon, 29 Feb 2016 11:00:28 -0800
X-Google-Sender-Auth: OqILTraC13RDjOO5eYFr-UJv4D4
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: "Liubing (Leo)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 19:00:38 -0000

At Mon, 29 Feb 2016 09:32:16 +0000,
"Liubing (Leo)"  wrote:

> Let me quote some of substantial objections that made during the last WGL=
C of this draft Oct. 2014.

> "In its current form, the described problems seem to be too
> artificial, hypothetical, or minor to be important to me.  And
> that's why I didn't regard this draft as that important."

> "Actually, I guess there should be more pragmatic examples of
> operational issues because of the described divergence and I wonder
> whether these minor cases are really the only things we can imagine
> (although I don't have a specific idea right now).  If these
> sections can be revised with more convincing examples, I would be
> more supportive about publishing it." =E2=80=93 by Jinmei

These two still seem to stand (to me, at least).  The first one is
almost exactly the same as what I said this time.

> In this WGLC, Jinmei provided more suggestion:

> =E2=80=9CIn that sense most of the points described in this  document see=
m
> to be too minor (see specific discussions below).  I  see at least a
> couple of points that may have real operational  impact, such as
> Divergence 1-3 in Section 4.1 (which would make  coexistence of
> SLAAC and DHCPv6-based address allocation impossible for some
> implementations, and I heard some operators want this type of
> operation).  My personal suggestion is to focus on such real issues,
> removing all minor points. The resulting document might become very
> thin, but could be much more useful and readable.=E2=80=9D

This is a kind of text that rephrases the second point in my 2014
comment.  Note that the result may not necessarily be "very thin";
there may be many practical issues than I originally and currently
thought/think.  My general point is that it's not useful very much to
just arbitrarily list spec ambiguity and implementation divergence;
for them to be useful, it should come with explanations why that
matters in a practical sense.

> Say, if I revise as you and Jinmei suggested, a very thin document,
> I concern a bit on the following things:

> -        The divergence we observed should be only part of the potential =
problems. So, if we remove the ambiguity analysis content, people might thi=
nk the documented problems are all the problems.
>
> -        How can we judge the current reported problems as =E2=80=9Cminor=
=E2=80=9D in the future? My original thought was, just reported all the pro=
blems we have found, we don=E2=80=99t select them for the readers. Readers =
would decide by themselves.

You basically seem to argue that arbitrarily listing the ambiguity and
implementation divergence may still be useful for some reason (that I
don't understand).  I simply disagree on that, but that's probably up
to WG decision in the end.

--
JINMEI, Tatuya


From nobody Mon Feb 29 13:27:43 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF141B3C7C for ; Mon, 29 Feb 2016 13:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r17GsOhaHYI for ; Mon, 29 Feb 2016 13:27:41 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 C94A61B3C79 for ; Mon, 29 Feb 2016 13:27:39 -0800 (PST)
Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 5C12015EC29 for ; Mon, 29 Feb 2016 22:27:36 +0100 (CET)
Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 1DBC24B87B5 for ; Mon, 29 Feb 2016 22:27:33 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 7E47B8AB6; Mon, 29 Feb 2016 22:27:35 +0100 (CET)
Date: Mon, 29 Feb 2016 22:27:35 +0100
From: Enno Rey 
To: v6ops@ietf.org
Message-ID: <20160229212735.GB39772@ernw.de>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>   <8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BB@nkgeml514-mbx.china.huawei.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 21:27:43 -0000

Hi,

jumping in as one of the guys who contributed some of the material & analyses.


On Mon, Feb 29, 2016 at 11:00:28AM -0800, Jinmei wrote:
> At Mon, 29 Feb 2016 09:32:16 +0000,
> "Liubing (Leo)"  wrote:
> 
> > Let me quote some of substantial objections that made during the last WGLC of this draft Oct. 2014.
> 
> > "In its current form, the described problems seem to be too
> > artificial, hypothetical, or minor to be important to me.  And
> > that's why I didn't regard this draft as that important."
> 
> > "Actually, I guess there should be more pragmatic examples of
> > operational issues because of the described divergence and I wonder
> > whether these minor cases are really the only things we can imagine

I don't have the impression these cases are "minor". Actually the - from my observations being involved in IPv6 deployments in large organizations for some years - main reason for the lack of IPv6 in enterprise space is this exact spec ambiguity and implementation divergence. If you can't enforce a homogeneous (and at least somewhat predictable) behavior in a sufficiently large scale network with (OS-wise) heterogenous nodes most ops people just won't deploy $PROTOCOL.

Documenting this ambiguity on the base of practical samples seems hence a very valid approach to me, as (this is what we hope) most readers will pretty much immediately understand the (vast) operational ramifications.

best

Enno


From nobody Mon Feb 29 18:04:04 2016
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8171A89E9 for ; Mon, 29 Feb 2016 18:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjBWKrrky_6Z for ; Mon, 29 Feb 2016 18:04:02 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 AA4301A89B9 for ; Mon, 29 Feb 2016 18:04:02 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id l127so207507579iof.3 for ; Mon, 29 Feb 2016 18:04:02 -0800 (PST)
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=0ECBIy9SPsdXK3L54mxkcf+pmQ0WlIFMHnQzIwo3G5k=; b=OxX/gHpWHEVLbLdQWbT1f6ibrZaxejZMQPjoj5Ti9AMRR7iSwiGkA3DR+9Eno2acMm v4oLvhdYZyldC1FA24q/K7PXzrmjrDqmwlr4PElUH3iE3QnxMXoNbRRe/7TA+wbJPjJJ dPvJZbYvX5296rYB25QbAot7WiuU7PLgeGXYTS+2SOfuljdnWweTUGYiynTr7VstAeKY hrPJ13eBT7wQg6GMbl4EIc5HL+SY7q017WdquoHEcgwTXPTP5o/g46P/Nu11T0+VKmxf 6TzMHzOs3On9fCUssfC4rkPG+XtRg3uM2pLM+jZWkMzhxjl7Yy+Zk816xnMz4jl2pm0K K25g==
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=0ECBIy9SPsdXK3L54mxkcf+pmQ0WlIFMHnQzIwo3G5k=; b=UODMTweb0RiJOC7wvphzabZ9kWvczDgByYPI2WQPZCu4pN/y9tbP5WPONi1/XRJ+uc iWaXHLYs0SBW82Lg4NjsEqT3zOmeMIdQwS7vuOtsxWFh1C6GCZ8kvno/NWrWEyJPoy/I FlL2ZINsOy8QZPyQIUy0PC2NwRpUrrKbQgHN8HR99nygWo/mkWrUMgwrnQDftFdXBA02 Y/GreAeJdQgL0YpYSJbmhy7kOuslsg26kq0owndlmUD7qS7sAV8j6gsJVDsOBj3UJyvh PSfjhOolL06b8sRbTLzvLrLLOaFAmC+DOQlt5oduu1q0Nepjw76ZqJKkqBNLZzXqqMCD +Hww==
X-Gm-Message-State: AG10YOQap7Qz51arKg92PeAY14H+36h7UhQ7xiCDmIlRzzQ4hHbLew9hyeLgrAPUzhDI4o2JGHD2+yWdz5VK4g==
MIME-Version: 1.0
X-Received: by 10.107.184.135 with SMTP id i129mr25993498iof.4.1456797842107;  Mon, 29 Feb 2016 18:04:02 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Mon, 29 Feb 2016 18:04:01 -0800 (PST)
In-Reply-To: <20160229212735.GB39772@ernw.de>
References: <201602211900.u1LJ08MV018843@irp-lnx1.cisco.com>   <8AE0F17B87264D4CAC7DE0AA6C406F45C2D478BB@nkgeml514-mbx.china.huawei.com>  <20160229212735.GB39772@ernw.de>
Date: Mon, 29 Feb 2016 18:04:01 -0800
X-Google-Sender-Auth: b5N7olhnj-_5yX9lOjR61GhcdY4
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Enno Rey 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 02:04:04 -0000

At Mon, 29 Feb 2016 22:27:35 +0100,
Enno Rey  wrote:

> > > "In its current form, the described problems seem to be too
> > > artificial, hypothetical, or minor to be important to me.  And
> > > that's why I didn't regard this draft as that important."
> >
> > > "Actually, I guess there should be more pragmatic examples of
> > > operational issues because of the described divergence and I wonder
> > > whether these minor cases are really the only things we can imagine

> I don't have the impression these cases are "minor". Actually the -
> from my observations being involved in IPv6 deployments in large
> organizations for some years - main reason for the lack of IPv6 in
> enterprise space is this exact spec ambiguity and implementation
> divergence. If you can't enforce a homogeneous (and at least
> somewhat predictable) behavior in a sufficiently large scale network
> with (OS-wise) heterogenous nodes most ops people just won't deploy
> $PROTOCOL.

> Documenting this ambiguity on the base of practical samples seems
> hence a very valid approach to me, as (this is what we hope) most
> readers will pretty much immediately understand the (vast)
> operational ramifications.

In a sense I think we are on the same page.  I already stated there's
at least one case where I see the operational point.  For cases I
thought minor I basically tried to leave comments on why I thought
they were minor, unrealistic, or too hypothetical.  If you, the
authors, and someone else can show practical cases to explain why they
matter, I'm happy to see it ship.  That's all what I've been asking
for these periods.

--
JINMEI, Tatuya